De dónde salen los requisitos
De dos normas que hay que leer juntas. El Real Decreto 1007/2023 aprueba el Reglamento y dice qué hay que garantizar; la Orden HAC/1177/2024 baja al detalle y dice cómo: formatos, algoritmos, milímetros. Todo lo que sigue sale de ahí.
1. Los seis adjetivos del artículo 8
El artículo 8 es la columna vertebral. Exige que el sistema garantice la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros de facturación. Suena a declaración de intenciones, pero el apartado 2 lo concreta y ahí es donde muerde:
- 8.2.a) — una vez generados y registrados, los datos no pueden alterarse sin que el sistema lo detecte. Se considera alteración tanto ocultar o eliminar un registro como modificar sus datos. Cualquier corrección se hace con un registro posterior adicional, conservando el original.
- 8.2.b) — los registros deben estar encadenados, de forma que pueda verificarse su rastro siguiendo la secuencia de creación desde el primero hasta el último.
Cómo se comprueba: pide una demostración de qué pasa al intentar corregir una factura ya emitida. Si el programa deja editarla y guardar, no cumple. Debe llevarte a una rectificativa o a una anulación.
2. El registro de alta: cuándo nace y qué lleva
El artículo 9 fija el momento: el registro de facturación de alta se genera de forma simultánea o inmediatamente anterior a la expedición de cada factura. No es un proceso nocturno ni un botón que alguien pulsa al final del mes.
El artículo 10 enumera su contenido: identificación fiscal del emisor y del destinatario, número y serie, fechas, tipo de factura, desglose de bases y cuotas, la huella del registro anterior, la identificación del sistema informático que lo genera y la marca de tiempo, entre otros. Son diecisiete elementos.
Cómo se comprueba: pregunta si el registro se crea dentro de la misma transacción que la factura. Si la factura puede quedar emitida y el registro fallar por separado, tienes un agujero: dos verdades distintas sobre el mismo documento.
3. La huella: SHA-256 y cadena
El artículo 12 del Reglamento exige añadir una huella o hash a los registros de alta y de anulación. La Orden HAC/1177/2024, en su artículo 13, concreta el algoritmo —SHA-256— y qué campos exactos entran en el cálculo según el tipo de registro.
Cada registro incorpora parte de la huella del anterior. Eso construye una cadena: si alguien manipulase un registro intermedio, todas las huellas posteriores dejarían de cuadrar. Es el mecanismo que hace verificable la inalterabilidad del artículo 8.
Cómo se comprueba: pregunta si el sistema tiene una función para verificar la integridad de la cadena completa y qué hace si detecta una rotura. Un programa que calcula huellas pero nunca las revisa te dará la mala noticia el día de la inspección, no antes.
4. El registro de anulación
El artículo 11 regula el registro de facturación de anulación, que se genera cuando se ha emitido erróneamente una factura. Es importante entender lo que no es: no borra nada. Añade un registro que deja constancia de la anulación, y el original permanece.
Cómo se comprueba: mira si el programa distingue entre anular (la factura no debió existir) y rectificar (el importe o los datos eran otros). No son lo mismo y no se resuelven igual.
5. El registro de eventos
Menos conocido y muy citado a medias. El artículo 8.3 exige que el sistema cuente con un registro de eventos que recoja automáticamente determinadas interacciones y operaciones, sin que el usuario pueda intervenir. La idea es dejar rastro de lo que pasa alrededor de los registros de facturación —arranques, cambios de configuración, incidencias—, no solo de las facturas.
Cómo se comprueba: pide ver ese registro. Debe existir como tal dentro del sistema y no ser el log técnico del servidor que el proveedor consulta cuando le apetece.
6. Las dos modalidades: remitir o firmar
El artículo 15 abre la puerta a la remisión voluntaria de los registros y el artículo 16 define qué es un sistema VERI*FACTU: aquel que los remite «de forma continuada, segura, correcta, íntegra, automática, consecutiva, instantánea y fehaciente». La elección tiene consecuencias:
| Modalidad VERI*FACTU | Modalidad no verificable | |
|---|---|---|
| Envío a la AEAT | Automático e inmediato, de cada registro | No se remiten |
| Firma electrónica | No se exige de los registros | Obligatoria |
| Mención en la factura | «VERI*FACTU» | «Factura verificable en la sede electrónica de la AEAT» |
| Carga de conservación | Menor: la AEAT ya tiene los registros | Mayor: conservación y disposición a la Administración |
Para la mayoría de las pymes, VERI*FACTU sale más barato en complejidad: se cambia la carga de firmar y custodiar por la de estar conectado.
7. El QR y la mención en la factura
La Orden llega al milímetro. Su artículo 21 exige un código QR de entre 30 y 40 milímetros de lado, conforme al estándar ISO/IEC 18004, que contiene el NIF del emisor, el número de factura, la fecha y el importe. Y la factura debe llevar la mención que corresponda a la modalidad.
Cómo se comprueba: emite una factura de prueba y escanea el QR con el móvil. Debe llevarte al servicio de verificación de la Agencia Tributaria. Y ojo con un detalle que se escapa: si el sistema está trabajando en el entorno de pruebas, el QR tiene que apuntar al entorno de pruebas, no a la sede real, donde esa factura no existe.
8. La declaración responsable
El artículo 13 del Reglamento obliga al productor del software a emitir una declaración responsable certificando que el sistema cumple lo dispuesto en el artículo 29.2.j) de la Ley General Tributaria y en el propio Reglamento. Tiene que constar por escrito y de modo visible en el propio sistema informático, en cada una de sus versiones, y entregarse a clientes y comercializadores.
Dos consecuencias prácticas que casi nadie menciona:
- Es por versión. Un proveedor con despliegue continuo necesita una política de versionado y conservar la declaración de todas las versiones que haya producido.
- Va dentro del programa. No es un PDF en el cajón comercial: debe poder consultarse desde el propio sistema.
Lo que la norma no dice y se nota en producción
Hasta aquí, la letra. Estos cuatro puntos no salen del BOE, salen de tener el sistema funcionando:
- Reintento de envíos. La sede de la Agencia Tributaria tiene caídas y ventanas de mantenimiento. Si un fallo de red detiene tu facturación, el problema es del diseño, no de la AEAT. El registro ya está generado y encadenado; el envío debe reintentarse solo, con el estado visible de cada uno.
- La modalidad se congela en la factura. Lo que importa es cómo se expidió el documento, no cómo esté configurado el sistema el día que alguien lo reimprime. Si la mención del PDF se calcula al vuelo, una reimpresión futura puede contradecir a la factura original.
- Entorno de pruebas de verdad. Antes de facturar en real hay que poder ensayar contra el entorno de pruebas de la AEAT, con su propia URL de verificación.
- Varias sociedades, varias cadenas. Si emites desde más de una empresa, cada una necesita su numeración, su certificado y su cadena de huellas, sin mezclarse. Lo tratamos en VeriFactu en una empresa de transporte.
Diez preguntas para tu proveedor
- ¿Me enseñas la declaración responsable de la versión que tengo contratada?
- ¿En qué modalidad trabaja el sistema, VERI*FACTU o no verificable?
- ¿El registro de alta se genera en la misma transacción que la factura?
- ¿Puedo verificar la cadena de huellas desde el propio programa?
- ¿Qué ocurre exactamente si intento modificar una factura ya emitida?
- ¿Distingue anulación de rectificativa?
- ¿Dónde veo el registro de eventos?
- ¿Qué pasa si la AEAT no responde? ¿Se reintenta solo? ¿Lo veo?
- Si facturo desde dos sociedades, ¿cada una tiene su serie y su certificado?
- Si el año que viene entro en el SII, ¿qué tengo que cambiar?
Fuentes oficiales
- Real Decreto 1007/2023, de 5 de diciembre — artículos 8 a 16 (BOE-A-2023-24840). boe.es
- Orden HAC/1177/2024, de 17 de octubre — especificaciones técnicas, huella y código QR (BOE-A-2024-22138). boe.es
- Ley 58/2003, General Tributaria — artículos 29.2.j) y 201 bis. boe.es
- Agencia Tributaria — Sistemas Informáticos de Facturación y declaración responsable. sede.agenciatributaria.gob.es