2023
1 enero
obligatoria
máxima
Contexto y por qué existe este Reglamento
Durante años, uno de los principales focos de fraude fiscal en España fue la llamada «caja B» o «software de doble uso»: programas de facturación que permitían emitir tickets o facturas y luego borrarlos o modificarlos para reducir artificialmente los ingresos declarados. Esto suponía una pérdida de miles de millones de euros anuales en recaudación tributaria.
El RD 1007/2023 nace para erradicar técnicamente esta posibilidad. Su enfoque no es punitivo en primera instancia, sino preventivo y técnico: si el propio software hace imposible borrar o alterar un registro de factura, el fraude desaparece desde la raíz.
El decreto desarrolla el mandato de la Ley 11/2021 (Ley de Medidas de Prevención y Lucha contra el Fraude Fiscal), que en su disposición adicional primera ya ordenaba al Gobierno regular los requisitos que deben cumplir los sistemas informáticos de facturación.
¿A quién afecta el RD 1007/2023?
El reglamento tiene un alcance muy amplio. Afecta a:
- Empresarios y profesionales que estén obligados a expedir facturas según el Reglamento de Facturación (RD 1619/2012) y que usen un sistema informático para ello.
- Los fabricantes, desarrolladores y comercializadores de software de facturación (que deben certificar que sus productos cumplen la norma).
- Las empresas que subcontratan la gestión de su facturación a terceros que usan software propio.
¿Quién queda excluido?
- Empresarios que emiten facturas exclusivamente en papel y sin ningún sistema informático.
- Contribuyentes ya incluidos en el SII (Suministro Inmediato de Información), que tienen un régimen propio de envío electrónico de registros.
- Determinadas operaciones exentas con requisitos simplificados de facturación.
Estructura del Reglamento
El RD 1007/2023 consta de 18 artículos agrupados en 4 capítulos, 3 disposiciones adicionales, 1 disposición transitoria y 1 disposición final. La Orden HAC/1177/2024 desarrolla los aspectos técnicos.
Disposiciones generales (Arts. 1–3)
Objeto del Reglamento, definiciones clave (sistema informático de facturación, registro de facturación, huella o hash, bloque de registros…) y ámbito de aplicación subjetivo y objetivo.
Requisitos de los sistemas informáticos de facturación (Arts. 4–10)
El núcleo técnico del Reglamento. Define qué debe hacer el software: generación de registros inalterables, hash encadenado, integridad, conservación, trazabilidad, identificación del sistema y exportación de datos.
Modalidades de remisión de registros a la AEAT (Arts. 11–15)
Define las dos modalidades: Veri*Factu (con envío automático a AEAT) y la modalidad sin envío (con controles más estrictos). Regula el QR tributario, los plazos de envío y la declaración responsable de los fabricantes.
Obligaciones de colaboración y control (Arts. 16–18)
Obligaciones de los fabricantes de certificar su software, del contribuyente de informar a la AEAT del sistema que usa, y facultades de la inspección tributaria para verificar el cumplimiento.
Requisitos técnicos principales
El Capítulo II (Arts. 4 a 10) es el corazón del Reglamento. Establece que cualquier sistema informático de facturación debe garantizar:
1. Integridad e inalterabilidad de los registros
Cada vez que se emite una factura, el sistema debe generar un registro de facturación que quede inmutablemente ligado a esa operación. No se puede modificar, no se puede borrar, no se puede reordenar. Técnicamente esto se consigue mediante un hash criptográfico (SHA-256 o similar) calculado sobre los datos del registro.
2. Encadenamiento de registros (hash chain)
El hash de cada registro incluye en su cálculo el hash del registro inmediatamente anterior. Esto crea una cadena criptográfica: modificar cualquier registro anterior invalida todos los posteriores, lo que hace la manipulación técnicamente detectable.
3. Conservación durante 4 años
Los registros de facturación deben conservarse durante un mínimo de 4 años en el sistema (o en soporte accesible para la inspección), aunque la normativa general contable y fiscal obliga a conservar la documentación durante 5 años. La destrucción anticipada es una infracción.
4. QR tributario en la factura
Toda factura impresa o en PDF que se entregue al cliente debe incluir un código QR que codifica la URL del servicio de verificación de la AEAT y los datos básicos de la factura. Permite a cualquier receptor verificar la factura en la web de la AEAT.
5. Identificación del sistema
El software debe identificarse en cada registro: nombre del fabricante, nombre del producto, versión y número de registro de la declaración responsable. Esto permite a la AEAT conocer qué software generó cada registro.
6. Exportación de datos
El sistema debe ser capaz de exportar todos los registros en un formato estructurado y legible para entregárselos a la inspección fiscal si son requeridos. El formato lo especifica la Orden HAC/1177/2024.
Las dos modalidades: Veri*Factu y No Veri*Factu
Modalidad Veri*Factu (con envío)
El software envía automáticamente a la AEAT, por vía electrónica y en tiempo real (o casi real, con un margen máximo de tiempo), un registro XML por cada factura emitida. La AEAT acusa recibo. El QR de la factura apunta al servicio de verificación de la AEAT, donde el receptor puede comprobar que la factura existe en sus sistemas.
Ventaja: al dejar constancia en los sistemas de la AEAT de cada factura, la norma permite ciertas flexibilidades en los controles internos del software.
Modalidad No Veri*Factu (sin envío)
El software no envía registros a la AEAT, pero los controles internos son más estrictos: la cadena de hashes debe ser impecable, el log de auditoría más detallado y el sistema debe identificar con mayor precisión cualquier evento sobre los registros. El QR de la factura apunta a una verificación local o al propio documento, no a los sistemas de la AEAT.
Plazos de adaptación
Publicación en el BOE
El RD 1007/2023 entra en vigor al día siguiente de su publicación. Los fabricantes de software ya pueden empezar a adaptar sus productos y presentar declaraciones responsables.
Orden HAC/1177/2024
Se publica la Orden Ministerial que desarrolla los aspectos técnicos: formato de los registros XML, estructura del QR, especificaciones del hash, protocolo de envío a la AEAT y formato de exportación.
Fecha inicial (aplazada)
La fecha originalmente prevista para la entrada en vigor para los contribuyentes fue aplazada un año mediante disposición adicional publicada en 2025.
Fecha límite definitiva
A partir de esta fecha, todos los sistemas informáticos de facturación en España deben cumplir íntegramente el RD 1007/2023. El uso de software no conforme constituye infracción tributaria.
Sanciones por incumplimiento
El régimen sancionador está recogido en el artículo 201 bis de la Ley General Tributaria, incorporado por la Ley 11/2021. Las sanciones se aplican tanto a los fabricantes de software no conforme como a los contribuyentes que lo usen.
Sanción por producir, comercializar o tener sistemas informáticos que permitan la doble contabilidad o no cumplan la norma. Por sistema no conforme.
Sanción por cada registro omitido, alterado o que no contenga la huella o hash requerido. Se aplica por registro individual.
Posible pérdida de deducibilidad de gastos en inspección si los registros de facturación son inválidos o no existen.
Obligaciones de los fabricantes de software
El RD introduce un requisito nuevo para los desarrolladores y distribuidores de software de facturación: deben presentar ante la AEAT una declaración responsable acreditando que su producto cumple todos los requisitos del Reglamento, y mantener accesible esta declaración.
La declaración incluye: datos del fabricante, nombre y versión del software, descripción técnica del cumplimiento, y compromisos de mantenimiento. Eventronic Systems, S.R.L. ha presentado esta declaración para Winfac y está disponible en nuestra web.