Software conforme con Veri*Factu: qué cambia en el desarrollo

Veri*Factu no es una plantilla de factura nueva ni una casilla en el menú de contabilidad. Es un conjunto de requisitos técnicos, incluidos en la ley antifraude española (Ley 11/2021), que dictan cómo debe registrar, encadenar y, según la modalidad elegida, comunicar cada factura que emita cualquier sistema informático de facturación. Si estás definiendo un TPV, un CRM o un ERP a medida para un negocio que opera en España, esto ya es una restricción de arquitectura, no una función que se añade después del lanzamiento.

Qué exige realmente Veri*Factu a nivel de software

En esencia, Veri*Factu exige que cada factura que genera un sistema quede vinculada criptográficamente a la anterior, formando una cadena ininterrumpida. Cada registro lleva un código QR que permite a cualquiera, incluido un inspector de Hacienda, verificar la factura contra la cadena. El sistema debe conservar estos registros durante un mínimo de cuatro años y tiene que estar construido de modo que nadie, ni el dueño del negocio, ni un empleado, ni un desarrollador con acceso a la base de datos, pueda editar o borrar en silencio una factura pasada sin romper la cadena visible.

Este último punto es el que más se subestima. Una cadena demostrablemente intacta desde la primera factura es un problema de ingeniería muy distinto de «guardar las facturas en una base de datos y no borrar filas». Significa que la lógica de facturación tiene que generar el enlace hash en el momento de la creación, almacenarlo de forma inmutable y exponerlo en un formato verificable desde el primer día. Adaptar esto a un sistema que ya lleva dos años emitiendo facturas es, en el mejor de los casos, incómodo: o la cadena empieza a mitad de camino (algo que un auditor notará) o hay que reconstruir los datos históricos, lo que anula el sentido de la protección contra manipulaciones.

Dos modalidades, la misma mecánica de fondo

La normativa permite dos modos de funcionamiento. En la modalidad Veri*Factu, el sistema envía los registros de factura a la AEAT casi en tiempo real, a medida que se emiten. En la modalidad no Veri*Factu, el sistema conserva en local los mismos registros encadenados y a prueba de manipulaciones, y los pone a disposición de la Agencia Tributaria cuando los solicita, en lugar de transmitirlos automáticamente. Ambos modos necesitan la misma lógica de encadenamiento, generación de QR y conservación; la diferencia es solo dónde acaban los datos y cuándo. Un sistema bien diseñado desde el principio suele poder admitir cualquiera de los dos modos con un cambio de configuración, sin reconstruirlo.

Sin certificación oficial, pero con una declaración responsable real

Un detalle que confunde a mucha gente: la Agencia Tributaria no certifica ni aprueba formalmente el software de facturación. No hay un sello de aprobación que buscar en una caja o en una página de precios. Lo que exige la ley es una declaración responsable, un documento firmado (por el proveedor del software o, si lo ha desarrollado el propio negocio, por este) que confirma que el sistema cumple los requisitos técnicos. Eso cambia la conversación sobre la responsabilidad. Si un sistema no se comporta de forma conforme en la práctica, la declaración no protege a nadie, y las sanciones del artículo 201 bis de la Ley 11/2021 pueden aplicarse al negocio que usa el software y, según las circunstancias, al proveedor que lo suministró.

Por qué las plataformas estándar e importadas se quedan cortas sin que se note

Muchas plataformas de TPV y de facturación vendidas a nivel internacional se diseñaron para mercados sin un requisito equivalente, y el cumplimiento de Veri*Factu se añade como módulo regional, a veces mucho después de que la arquitectura central de la plataforma ya estuviera cerrada. El resultado suele ser una capa de cumplimiento montada sobre un motor de facturación que no se diseñó pensando en el encadenamiento inmutable, y eso se nota en fallos con pedidos editados, tiques anulados o cuentas divididas, justo los escenarios con los que un restaurante o un comercio lidia cada día. En un restaurante, donde la cuenta de una mesa puede modificarse, fusionarse o devolverse parcialmente varias veces antes de cerrarse, es donde un módulo de cumplimiento añadido a posteriori tiende a fallar. Ya hemos escrito por separado, en general, sobre software de restaurante estándar frente a software a medida; Veri*Factu es ahora un motivo concreto por el que esa comparación importa.

Qué significa esto si estás definiendo un sistema ahora

Si estás construyendo o sustituyendo un sistema de TPV, de facturación o un ERP para un negocio que opera en España, Veri*Factu tiene que ser un requisito desde la primera conversación sobre arquitectura, no una partida añadida durante las pruebas. Eso implica decidir pronto si el negocio necesita la modalidad Veri*Factu (envío a la AEAT en tiempo real) o la modalidad no Veri*Factu (registros locales a prueba de manipulaciones), diseñar la cadena de facturas y la generación del QR dentro del modelo de datos desde la primera factura que emita el sistema, y planificar el requisito de conservación de cuatro años en cómo se almacenan y se respaldan los registros. Es exactamente el tipo de decisión que pertenece a una fase de definición de software a medida, donde se mapea el flujo de trabajo, incluido cómo se crean, editan y cierran las facturas en el uso diario, antes de diseñar una sola pantalla. En el caso de los restaurantes, también forma parte de cómo planteamos los desarrollos de Restaurant Management System, porque la facturación por mesa es donde más se pone a prueba el encadenamiento de facturas.

Lista de comprobación para el desarrollo

• Decide pronto si el negocio necesita la modalidad Veri*Factu (envío a la AEAT en tiempo real) o la modalidad no Veri*Factu (registros locales a prueba de manipulaciones).
• Diseña la cadena de facturas y la generación del QR dentro del modelo de datos desde la primera factura que emita el sistema.
• Planifica el requisito de conservación de cuatro años en cómo se almacenan y se respaldan los registros.

Por qué un estudio cercano suele detectarlo antes

No se trata tanto de la proximidad en sí como de lo que un estudio vigila día a día. Un equipo que construye y mantiene software para negocios españoles se topa con Veri*Factu como parte rutinaria de definir cualquier sistema relacionado con la facturación, porque los clientes preguntan por ello, los plazos se comentan en los círculos contables y jurídicos locales, y el requisito aparece en proyectos reales antes de aparecer en un titular. Un proveedor remoto generalista, sobre todo uno con sede fuera de España que trabaja a partir de una lista genérica de funciones, normalmente no tiene motivo para saber que esta normativa existe hasta que un cliente llama después de no superar una inspección. Ya lo hemos señalado al hablar de qué cambia cuando un estudio de software es realmente local en la región, y Veri*Factu es un ejemplo concreto de para qué sirve esa cercanía: no para reuniones más rápidas, sino para menos sorpresas en una inspección.

Una nota sobre los plazos

Según el Real Decreto-ley 15/2025, las empresas sujetas al Impuesto sobre Sociedades deben tener sistemas de facturación conformes antes del 1 de enero de 2027, y el resto de obligados tributarios, incluidos los autónomos, antes del 1 de julio de 2027. El 5 de octubre de 2026 el Ministerio de Hacienda anunció un aplazamiento previsto hasta octubre de 2028, alineado con la factura electrónica obligatoria, pero todavía no está aprobado formalmente.

En lugar de anclar un plan de desarrollo a una fecha concreta que puede volver a moverse, lo más fiable es diseñar el sistema como si el requisito ya estuviera en vigor: registros encadenados, códigos QR y conservación adecuada desde la primera factura. Si el plazo vuelve a moverse, un sistema bien construido no necesita cambiar. Si no se mueve, no hay carreras de última hora. Para los negocios que además facturan entre España y Gibraltar, esto convive con las cuestiones de IVA y de divisa que tratamos en cómo construir software para negocios que operan entre España y Gibraltar, porque ambas son realidades regionales que condicionan cómo debe construirse un sistema de facturación, no solo qué tiene que mostrar.