Sobre el papel suena atractivo: “si quieres, envías las facturas a Hacienda automáticamente; si no quieres, no”. En la práctica, para un desarrollador y para el dueño de un e-commerce, esta simplificación es un billete de ida a un terreno de riesgos legales, cargas probatorias complejas y sanciones de hasta 150.000 euros. En este artículo veremos, desde un punto de vista técnico y jurídico, por que motivo para desarrolladores de software y para propietarios de tiendas online...

el modo no-VeriFactu es una mala apuesta estratégica 

Índice de contenidos 📚

1. ¿Qué es VeriFactu y qué son los sistemas sin envío inmediato?
2. El espejismo de la “libertad”: el riesgo real del hash encadenado
3. El desarrollador de software: de vendedor de módulos a potencial infractor grave
4. El propietario de la tienda online: cuando tener la herramienta ya es sancionable
5. Un divorcio anunciado: responsabilidad civil entre cliente y proveedor
6. El coste oculto del modo no-VeriFactu: dos lógicas, más complejidad y más riesgo
7. El código QR en VeriFactu: factura verificable vs. simple facilitador de comunicación
8. Cambio de paradigma: trazabilidad total y fin de la opacidad “técnicamente fácil”
9. Conclusión: por qué el modo no-VeriFactu es una mala apuesta estratégica

1. ¿Qué es VeriFactu y qué son los sistemas sin envío inmediato? 🧾

El nuevo Reglamento de Requisitos de los Sistemas Informáticos de Facturación (RRSIF), aprobado por el RD 1007/2023 y desarrollado al amparo de la Ley 11/2021, establece dos formas legales de operar para los sistemas de facturación:

1.1. Sistemas VERI*FACTU 💻

Son sistemas de facturación que:

• Cumplen los requisitos de integridad, conservación, accesibilidad, trazabilidad e inalterabilidad de los registros de facturación.
• Envían los registros de facturación a la AEAT de forma automática, en el momento o inmediatamente después de emitir la factura.
• Permiten que el destinatario pueda verificar, mediante un código QR, que esa factura consta como comunicada a la AEAT.

1.2. Sistemas NO-VERI*FACTU (sin envío inmediato) 🗂️

También son sistemas de facturación sujetos al RRSIF. Se caracterizan porque:

• Cumplen exactamente los mismos principios técnicos que un sistema VeriFactu: integridad, trazabilidad, inalterabilidad, etc.
• No remiten los registros de facturación en el mismo momento de la expedición; los almacenan en el propio sistema de facturación.
• Deben estar preparados para remitir esos registros a la AEAT cuando ésta lo requiera y conservarlos durante los plazos legales.

El matiz crucial es este: muchos creen que la segunda opción permite volver al “sistema antiguo” de Excel o bases de datos totalmente editables que funcionen como software de facturación (con numeración, plantillas, automatismos…). Eso es falso.

La ley exige que los sistemas que no envían de forma inmediata cumplan igualmente con:

• Registro inalterable.
• Encadenamiento mediante huellas digitales (hash).
• Trazabilidad de cualquier evento relevante sobre la factura.

Aunque no envíes la factura a Hacienda al instante, tu software debe generar una huella digital encadenada que haga detectable cualquier intento de modificación o borrado posterior. El “modo no-VeriFactu” no es un salvoconducto para la contabilidad B; es simplemente otra modalidad de cumplimiento, pero sin la ventaja de la automatización y verificación inmediata por parte de la AEAT.

2. El espejismo de la “libertad”: el riesgo real del hash encadenado 🧨

Muchos desarrolladores están vendiendo el modo no-VeriFactu como una aparente libertad para el cliente:

“Nuestro software es compatible con VeriFactu, pero si quieres, desactivas el envío y trabajas como antes”.

El peligro de esa frase es evidente. Si “trabajar como antes” se interpreta como:

• Poder borrar una factura errónea y reutilizar el número.
• Modificar fechas o importes a posteriori sin dejar rastro técnico.
• Emitir documentos con apariencia de factura que no entran en la cadena de registros inalterables.

…se está entrando de lleno en el terreno del artículo 29.2.j) de la Ley General Tributaria (LGT) y del artículo 201 bis LGT, que sanciona los sistemas de doble uso.

Para que el “modo no-VeriFactu” sea legal, el software debe:

• Encadenar cada registro con el anterior mediante un algoritmo criptográfico (hash).
• Impedir, a nivel de diseño, que se pueda alterar un registro sin romper esa cadena.
• Registrar cualquier evento relevante (anulación, emisión de rectificativa, error, etc.) dejando constancia.

Si el sistema permite desactivar este encadenamiento o relajarlo con un simple “check” en la configuración, para poder alterar datos sin dejar rastro, es muy fácil que Hacienda lo considere software de “doble uso” a efectos del artículo 201 bis LGT.

En ese punto, el problema deja de ser meramente técnico para convertirse en un problema administrativo sancionador y, en escenarios de fraude probado, incluso penal.

3. El desarrollador de software: de vendedor de módulos a potencial infractor grave 👨‍💻

El artículo 201 bis LGT es especialmente duro con los fabricantes y comercializadores de sistemas informáticos de facturación. No sanciona solo al que ayuda a defraudar de forma consciente, sino a quien diseña o comercializa herramientas que lo permiten.

Las sanciones pueden llegar:

• Hasta 150.000 euros por ejercicio y por cada tipo de sistema o programa afectado.

Se considerará infracción, entre otros supuestos, que el software:

• Permita llevar contabilidades distintas (por ejemplo, una oficial y otra “paralela” u oculta).
• Permita no reflejar total o parcialmente las transacciones realizadas.
• Permita alterar transacciones ya registradas sin dejar rastro, rompiendo la trazabilidad o el encadenamiento de hashes.

En este contexto, ofrecer un “modo no-VeriFactu” que, en la práctica:

• Relaja los controles de integridad e inalterabilidad, o
• Permite borrar o editar facturas sin generar las correspondientes facturas rectificativas y sin dejar evidencias en los registros,

coloca al desarrollador en el foco de la infracción.

Un punto clave: no hace falta que el cliente llegue a defraudar para que el desarrollador sea sancionado. Basta con que el software tenga la capacidad técnica de facilitar esas prácticas prohibidas.

4. El propietario de la tienda online: cuando tener la herramienta ya es sancionable 🏬

Desde el lado del e-commerce, el panorama no es menos preocupante.

La LGT prevé, también en el artículo 201 bis, sanciones para quienes posean o utilicen estos sistemas:

• Multas de hasta 50.000 euros por ejercicio fiscal por la tenencia de sistemas que no cumplan las especificaciones técnicas o, cuando proceda, no estén debidamente certificados.

Esto significa que:

• No basta con alegar “yo no sabía nada, lo instaló mi informático”.
• La mera tenencia y uso de un software irregular o de doble uso es sancionable.
• La responsabilidad del titular del negocio no desaparece porque en el panel de configuración exista un check de “modo no-VeriFactu”.

A esto hay que añadir una realidad operativa:

• En los sistemas VeriFactu, Hacienda recibe la información de forma inmediata y puede cruzarla con otros datos.
• En los sistemas sin envío inmediato, la AEAT no dispone de esa información en tiempo real.

Según numerosos expertos, esto convierte a los negocios que utilizan solo sistemas NO-VeriFactu en candidatos prioritarios para requerimientos de información y actuaciones presenciales, porque es la única forma que tiene la Administración de comprobar:

• Que los registros encadenados (hashes) son coherentes.
• Que no se han producido manipulaciones o borrados sin el debido rastro técnico.

Optar por el “modo no-VeriFactu” es jurídicamente lícito si se cumplen los requisitos del RRSIF, pero supone, en la práctica, decirle a Hacienda:

“No te envío mis datos ahora; ven a buscarlos tú cuando consideres oportuno”.

Y cuando vayan, el sistema debe ser técnicamente impecable.

5. Un divorcio anunciado: responsabilidad civil entre cliente y proveedor ⚖️

La escena es fácil de anticipar:

1. La AEAT realiza una comprobación sobre los registros de facturación de una tienda online.
2. Detecta inconsistencias, rotura en la cadena de hashes, ausencia de determinados registros o imposibilidad de reconstruir la trazabilidad.
3. Propone sanción al titular del e-commerce (por ejemplo, 50.000 euros por ejercicio afectado).

El siguiente movimiento es casi automático:

• El titular del negocio se dirige a su proveedor de software y le plantea:
  • “Tú me vendiste este sistema como ‘compatible con la ley’”.
  • “Tú me hablaste de un modo no-VeriFactu que era seguro”.
  • “Tú diseñaste este módulo que permite borrar/alterar facturas sin rastro”.

Los disclaimers tipo “el uso del software es responsabilidad exclusiva del cliente” tienen un recorrido limitado cuando:

• La norma fija requisitos objetivos de diseño (integridad, trazabilidad, hash encadenado…).
• El defecto reside en el propio producto (el software permite prácticas prohibidas).

En ese escenario, el desarrollador no solo se enfrenta a:

• La posible sanción administrativa de la AEAT,

sino también a:

• Reclamaciones de responsabilidad civil por daños y perjuicios.
• Pérdida de reputación y de cartera de clientes, en un momento en que el mercado de software de facturación estará especialmente vigilado.

6. El coste oculto del modo no-VeriFactu: dos lógicas, más complejidad y más riesgo 🧩

Más allá del riesgo jurídico, mantener un “modo no-VeriFactu” en serio (es decir, conforme al RRSIF) introduce una complejidad técnica considerable:

• Hay que gestionar el almacenamiento y custodia de los registros inalterables en local:
  • Copias de seguridad.
  • Protección frente a borrados accidentales.
  • Garantía de acceso durante los plazos de prescripción.
• Se duplican las rutas de negocio y testing:
  • Código para modo VeriFactu (con envío inmediato).
  • Código para modo no-VeriFactu (sin envío inmediato, pero con las mismas garantías técnicas).
• Aumenta el riesgo de errores en el algoritmo de encadenamiento de hashes:
  • Inconsistencias entre bases de datos.
  • Registros que no se encadenan correctamente en determinadas casuísticas (rectificativas, anulaciones, cambios de TPV, etc.).

Cualquier fallo en el mecanismo de huella digital en un sistema local es responsabilidad del desarrollador y del usuario. En cambio:

• En un sistema VeriFactu, cada registro que supera las validaciones de la AEAT aporta una capa adicional de seguridad técnica y jurídica:
  • Se confirma que el formato y la estructura del registro son correctos.
  • Se genera una evidencia en poder de la propia Administración.

Esto no significa que la AEAT “bendiga” la contabilidad por el mero hecho de recibir los registros, pero sí que:

• La empresa puede demostrar que ha enviado todos los registros exigidos.
• El sistema se comporta conforme a las especificaciones técnicas validadas.

7. El código QR en VeriFactu: factura verificable vs. simple facilitador de comunicación 🔍

El Reglamento exige incluir un código QR en las facturas emitidas por sistemas que cumplen el RRSIF, pero su función no es exactamente la misma en cada modalidad.

7.1. QR en sistemas VeriFactu ✅

• El QR permite al cliente escanear y verificar en la web o servicios de la AEAT que esa factura ya ha sido comunicada por el emisor.
• De cara al destinatario, esto supone:
  • Un plus de confianza y transparencia.
  • Una señal clara de que el negocio funciona con un sistema de facturación alineado con el modelo de trazabilidad que impulsa la Administración.

7.2. QR en sistemas no-VeriFactu 📲

• El QR también está presente, pero no permite comprobar que la factura ya está registrada en la AEAT, porque esa comunicación aún no se ha producido.
• Su función principal es:
  • Contener los datos esenciales de la factura.
  • Facilitar que el destinatario pueda enviar esa información a la AEAT (por ejemplo, desde una app oficial) si lo estima oportuno.
• De este modo, el QR actúa como facilitador de futuros contrastes:
  • El destinatario puede remitir la información.
  • La AEAT puede usar esos datos para cruzarlos con la información que, en su momento, aporte el emisor.

Desde la óptica de imagen de marca, una tienda online que emite facturas verificables en origen (VeriFactu) transmite una sensación de transparencia superior a la que solo ofrece un QR “informativo” o orientado a la digitalización posterior.

8. Cambio de paradigma: trazabilidad total y fin de la opacidad “técnicamente fácil” 🔐

VeriFactu no es un parche técnico ni un simple nuevo formato de fichero. Es un cambio de paradigma en la forma de entender la facturación en España:

• Desaparece el espacio cómodo para:
  • Facturas emitidas “a lápiz” y luego cambiadas.
  • Borrados discretos de documentos.
  • Sistemas que permiten “jugar” con la numeración o con las fechas.
• Se impone la trazabilidad total, tanto si se envía de forma inmediata (VeriFactu) como si se opta por sistemas sin envío inmediato, pero siempre con:
  • Registro inalterable.
  • Hash encadenado.
  • Logs de eventos.

Seguir apostando por comercializar o usar un “modo no-VeriFactu” con la esperanza de mantener cierta opacidad o “flexibilidad” es, hoy, un error de cálculo:

• Para el desarrollador:
  • Es exponerse a sanciones que pueden comprometer seriamente la viabilidad de la empresa.
  • Es asumir que un inspector, un perito o un juez podrían revisar el código y el diseño del sistema con criterios muy exigentes.
• Para el e-commerce:
  • Es atraer más inspecciones y requerimientos.
  • Es cargar con la responsabilidad de custodiar y demostrar la integridad de unos registros criptográficos que, mal gestionados, pueden convertirse en un punto débil.

9. Conclusión: por qué el modo no-VeriFactu es una mala apuesta estratégica 🚫

En términos puramente legales, el modo NO-VeriFactu:

• Es una modalidad válida solo si el sistema cumple escrupulosamente con el RRSIF.
• No autoriza, en ningún caso, volver a la lógica de “facturo como antes”.

En términos estratégicos y de riesgo:

• Para el desarrollador, implica:
  • Multiplicar la complejidad del producto.
  • Asumir un riesgo sancionador elevado si el sistema puede calificarse como de doble uso.
  • Abrir la puerta a reclamaciones civiles por parte de sus propios clientes.
• Para el propietario de la tienda online, implica:
  • Asumir la responsabilidad por la tenencia y uso de un sistema potencialmente sancionable.
  • Aceptar más probabilidades de inspección y de requerimientos presenciales para comprobar la integridad de sus registros.
  • Renunciar al valor probatorio y de transparencia que ofrece un sistema VeriFactu plenamente operativo.

La alternativa sensata, desde una óptica de seguridad jurídica y de negocio, es apostar claramente por:

• Un software de facturación diseñado desde el inicio para cumplir el RRSIF.
• Una modalidad VeriFactu con envío automático de registros:
  • Que simplifique la gestión.
  • Que aporte evidencias en poder de la AEAT.
  • Que proyecte hacia clientes, socios y auditores una imagen clara de transparencia y cumplimiento.

Nota final
Este artículo tiene carácter divulgativo y técnico. No constituye asesoramiento jurídico individualizado. Ante decisiones concretas sobre la adaptación de su software o de su negocio al RRSIF y a VeriFactu, resulta imprescindible consultar con un asesor fiscal o jurídico especializado en sistemas informáticos de facturación.