VERI*FACTU y el software de facturación a medida: qué exige Hacienda antes del 1 de enero de 2027

Antes del 1 de enero de 2027, toda empresa en España que presente el Impuesto sobre Sociedades y facture con un programa informático tiene que estar usando un sistema informático de facturación (SIF) adaptado al Real Decreto 1007/2023. Cada factura genera un registro con su huella, encadenado al anterior, y lleva un código QR que el cliente puede cotejar con la Agencia Tributaria. El resto de obligados tributarios, en su mayoría autónomos, tiene hasta el 1 de julio de 2027.

Si tus facturas salen de un programa comercial, esto es sobre todo trabajo de tu proveedor. Si salen de un software que alguien escribió para ti, o que escribió tu propio equipo, el trabajo es tuyo. Tú cambias el código, y tú firmas la declaración que dice que cumple.

Las fechas y los dos aplazamientos

Este es el tercer calendario, así que cierto escepticismo está justificado.

• El Real Decreto 1007/2023 daba originalmente a las empresas hasta el 1 de julio de 2025.
• El Real Decreto 254/2025, de 1 de abril, lo trasladó al 1 de enero de 2026 para los contribuyentes del Impuesto sobre Sociedades y al 1 de julio de 2026 para el resto. El motivo era concreto: la orden técnica, la Orden HAC/1177/2024, no se publicó hasta el 28 de octubre de 2024.
• El Real Decreto-ley 15/2025, de 2 de diciembre, retrasó ambas fechas un año. Su texto está en el BOE, y el Congreso lo convalidó ese mismo mes.

La nota informativa de la AEAT sobre la ampliación del plazo, actualizada el 26 de marzo de 2026, no deja lugar a dudas: «las entidades que presenten el Impuesto sobre Sociedades deberán tener adaptados sus SIF antes del 1 de enero de 2027. El resto de obligados tributarios, antes del 1 de julio de 2027.»

¿Puede volver a moverse? A octubre de 2026, nada oficial apunta a ello. El primer retraso tuvo una causa técnica que ya no existe. Los servicios de remisión de la AEAT están en producción desde el 23 de abril de 2025, y desde el 29 de julio de 2025 los fabricantes de software solo pueden comercializar sistemas adaptados. Contar con un tercer aplazamiento es una apuesta, no un plan.

¿Cuál es tu fecha? Una SL o una SA presenta el Impuesto sobre Sociedades, así que una empresa con un ERP propio está casi con toda seguridad en la fecha del 1 de enero de 2027. Faltan menos de tres meses. La fecha de julio es para los autónomos y el resto de obligados tributarios incluidos en el ámbito.

Quién está obligado y quién no

Las preguntas frecuentes de la AEAT sobre el ámbito de aplicación lo reducen a cuatro negaciones. Estás obligado si no facturas exclusivamente a mano, no estás en el SII (ni de forma obligatoria ni voluntaria), no tienes tu domicilio fiscal en el País Vasco o en Navarra y no tienes una resolución que te exima.

Las exclusiones, en la práctica:

• Quienes llevan el SII. El Suministro Inmediato de Información es obligatorio para las empresas con un volumen de operaciones superior a 6 millones de euros, los grupos de IVA y los inscritos en el registro de devolución mensual (REDEME), y el resto puede acogerse voluntariamente. La AEAT lo dice así: «El ámbito subjetivo de ambos proyectos es excluyente.» Si pasas al SII, dejas de remitir registros VERI*FACTU y de imprimir el código QR.
• El País Vasco y Navarra. Las empresas con domicilio fiscal allí dependen de las haciendas forales y de sus propias normas, no del RD 1007/2023.
• La facturación puramente manual. Un talonario de facturas en papel queda fuera. También una hoja de cálculo que solo se usa para escribir, imprimir y guardar facturas; la que además genera tus libros registro de IVA, no.

Las empresas extranjeras están obligadas cuando tienen un establecimiento permanente en España.

Si facturas con un programa comercial (A3, Sage, Holded y similares), el productor es el fabricante y tiene que entregar una versión adaptada con su propia declaración responsable. Actualízalo, comprueba que la declaración está ahí y puedes dejar de leer.

Este artículo es para el resto: un ERP a medida, un programa en Access, Delphi o FileMaker escrito hace quince años, o un módulo de facturación dentro de tu propia plataforma web.

Tu empresa es el productor

El artículo 13.1 del Reglamento atribuye la certificación a quien produce el sistema, mediante una declaración responsable. Las preguntas frecuentes de la AEAT sobre certificación responden directamente al caso del desarrollo propio: «Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo.»

Lo que eso significa en la práctica:

• No hay auditoría externa. La AEAT lo llama «auto-certificación» del productor. Nadie aprueba tu sistema de antemano. Firmas tú, y respondes tú.
• Un proveedor externo que te desarrolla una extensión como producto certifica esa extensión. Si la desarrollaste tú, la certificas tú.
• La declaración tiene que estar visible dentro del sistema, en cada versión, y también accesible fuera de él, con independencia del producto.
• Su contenido está tasado por el artículo 15 de la Orden HAC/1177/2024: entre otras cosas, el nombre del sistema, su identificador y su versión, sus componentes, si funciona exclusivamente en modalidad VERI*FACTU, el nombre, el NIF y la dirección del productor, y la fecha y el lugar de la firma.

El caso incómodo es el programa cuyo autor se marchó hace años. Alguien tiene que producir la versión adaptada y firmar por ella. Decide quién, por escrito, antes de empezar el trabajo.

Personalizar un producto comercial certificado solo requiere una declaración aparte si el cambio afecta a cómo se implementan los requisitos del Reglamento. Una modificación hecha fuera del control del productor que pueda alterarlos no cumple.

Lo que está en juego lo fija el artículo 201 bis de la Ley General Tributaria: una multa fija de 150.000 € por cada ejercicio económico y por cada tipo de sistema por producir sistemas que no cumplan los requisitos, y de 50.000 € por cada ejercicio por tener un sistema que debería estar certificado y no lo está, o que ha sido alterado. Cuál de las dos correspondería a un sistema desarrollado internamente es una pregunta para tu asesor fiscal. Ninguna de las dos cifras es pequeña.

Qué tiene que hacer el software

Un registro por cada factura, en el momento de expedirla

El artículo 9.1 exige que el sistema genere un registro de facturación de alta «de forma simultánea o inmediatamente anterior a la expedición de cada factura». Una factura anulada genera un registro de facturación de anulación.

El artículo 10 enumera lo que contiene el registro: el NIF y el nombre del emisor, el destinatario cuando proceda, la serie y el número, las fechas de expedición y de operación, el tipo de factura, los datos de la factura rectificada si la hay, una descripción, el importe total, el régimen de IVA, la base imponible, los tipos y las cuotas, las causas de exención o no sujeción, la identificación del sistema y de su productor, y una marca de tiempo con precisión de segundos.

En los sistemas antiguos, aquí es donde se esconde el trabajo:

• Los desgloses de IVA a menudo se calculan al imprimir y nunca se guardan. Tienen que existir como datos en el momento de la expedición.
• «Expedir» a menudo no es más que imprimir un informe. Tiene que haber un punto explícito en el que un borrador pasa a ser factura, y es entonces cuando se crea el registro.
• Se acabó reutilizar números. Borrar una factura y reutilizar su número, una costumbre en muchos sistemas pequeños, ahora falla: la AEAT rechaza el segundo registro como «Registro de facturación duplicado.» Las facturas de prueba emitidas en producción son facturas reales y hay que anularlas.
• Nadie edita registros. Las preguntas frecuentes de la AEAT dicen que las modificaciones directas en la base de datos de registros emitidos no deben ser una operación permitida. Si hoy alguien corrige facturas con SQL, eso se acaba. Las correcciones se hacen con facturas rectificativas.

La cadena de huellas

Cada registro incluye la serie, el número y la fecha del registro anterior y parte de su huella. El algoritmo es SHA-256, y los campos exactos y su concatenación están en la documentación técnica de la AEAT, junto con los diseños de registro, los esquemas XSD, el WSDL y el catálogo de validaciones y errores.

Antes de generar un registro nuevo, el sistema debe comprobar que el último está correctamente encadenado y que su marca de tiempo no es más de un minuto posterior a la hora actual. Los registros se generan en el orden en que se expiden las facturas.

Eso tiene una consecuencia de arquitectura. Cada instalación necesita un único punto, serializado, donde se crean los registros. Dos servidores web añadiendo registros a la misma cadena sin coordinarse la romperán. La AEAT admite configuraciones mixtas, como terminales de punto de venta que reciben el registro de un sistema central, pero la cadena en sí vive en un solo sitio.

Cada sistema se identifica por el NIF del obligado tributario, un identificador de sistema de dos caracteres y un número de instalación que no puede repetirse nunca, ni siquiera cuando el mismo software se reinstala en la misma máquina.

El código QR en la factura

Cada factura lleva un código QR conforme a la norma ISO/IEC 18004, de entre 30x30 y 40x40 mm, con nivel de corrección de errores M. Codifica una URL con el NIF del emisor, la serie y el número, la fecha de expedición y el importe total, que el cliente puede cotejar con la AEAT. En modalidad VERI*FACTU, la factura incluye además la mención «VERI*FACTU» o «Factura verificable en la sede electrónica de la AEAT».

En un software antiguo, esto supone rehacer la plantilla de factura (un informe de Access, un formato de FileMaker, un generador de PDF) y añadir una biblioteca de QR a un entorno que nunca la tuvo.

Dos modalidades: VERI*FACTU o no

Modalidad VERI*FACTU. El sistema remite cada registro a la AEAT de forma automática, en el momento en que se genera. A cambio, los registros necesitan huella pero no firma electrónica, la AEAT los conserva, y un sistema que solo funciona en esta modalidad no necesita registro de eventos. Necesitas un cliente SOAP contra los servicios publicados por la AEAT, un certificado electrónico cualificado y una cola para cuando falle la conexión. Las preguntas frecuentes para desarrolladores de la AEAT tratan una caída como una incidencia: los registros esperan en la cola y se reintentan, y la facturación continúa.

Modalidad no VERI*FACTU. Los registros se quedan contigo, y cada uno debe firmarse (XAdES Enveloped, ETSI EN 319 132) con un certificado cualificado. El sistema también debe llevar un registro de eventos firmado que cubra el inicio y la parada en esta modalidad, las comprobaciones de anomalías y lo que detectan, las restauraciones de copias de seguridad y las exportaciones, con un evento resumen al menos cada seis horas de funcionamiento, y debe entregar los registros cuando la AEAT los requiera.

Para un sistema a medida, la modalidad exclusivamente VERI*FACTU suele ser el desarrollo más pequeño. Sin infraestructura de firma, sin registro de eventos, sin herramientas de detección de anomalías. Un sistema que ofrezca las dos modalidades tiene que implementarlo todo.

Un plan que cabe antes del 1 de enero de 2027

Desde principios de octubre, un contribuyente del Impuesto sobre Sociedades tiene unas trece semanas. Este es el orden que funciona.

1. Semana 1: inventario. Haz una lista de todos los SIF que emiten facturas: el ERP, el módulo de facturación de la tienda online, el script de suscripciones, el TPV del mostrador. Confirma que no estás en el SII ni sujeto a normativa foral.
2. Semanas 1 y 2: decidir quién firma y qué modalidad. Nombra al productor de cada sistema. Elige la modalidad exclusivamente VERI*FACTU salvo que tengas un motivo para no hacerlo. Asegúrate de que el certificado cualificado de la empresa existe y de que alguien se responsabiliza de él, porque las preguntas frecuentes para desarrolladores de la AEAT advierten que el sistema no puede funcionar sin él.
3. Semanas 2 a 4: análisis de carencias en los datos. Compara lo que guarda tu sistema con el artículo 10 y con el diseño de registro de la AEAT. Aquí aparecen los desgloses de IVA que faltan, los códigos de tipo de factura y las referencias de rectificación.
4. Semanas 3 a 8: desarrollo. La generación del registro en la expedición, la cadena y sus comprobaciones, el almacenamiento inalterable, la anulación, el QR en cada plantilla y el cliente de remisión con su cola de reintentos. Elimina las ediciones directas de los registros emitidos.
5. Semanas 6 a 10: pruebas. Empieza en el entorno de pruebas de la AEAT y después remite registros reales. La AEAT considera el tiempo anterior a tu fecha límite como periodo de pruebas, durante el cual puedes dejar de remitir y volver a otro sistema. Lee las preguntas frecuentes para desarrolladores antes de escribir los flujos de anulación y rectificación: cubren la mayoría de los casos límite.
6. Semanas 9 a 12: declarar y formar. Redacta la declaración responsable, muéstrala dentro de la aplicación y fuera de ella, y registra la versión. Explica a administración que los números no se reutilizan nunca y que los errores se corrigen con facturas rectificativas.
7. Mediados de diciembre: puesta en producción. Un plazo que dice «antes del 1 de enero» no es una fecha de arranque. Arranca quince días antes, para que los primeros problemas salgan cuando todavía hay margen.

Para la fecha del 1 de julio de 2027 vale el mismo plan, con más holgura. Empieza en enero, no en mayo.

Hay dos alternativas a rehacer el sistema que merece la pena valorar con honestidad. La AEAT admite arquitecturas mixtas, así que tu ERP puede seguir preparando los datos de factura mientras un componente aparte, comprado o desarrollado, genera los registros, el QR y la remisión, siempre que las declaraciones responsables cubran cómo encajan las piezas. Y si el programa antiguo emite un puñado de facturas al mes, la aplicación de facturación gratuita de la AEAT para pequeñas empresas, o un programa estándar, puede salir más barato que adaptarlo.

Dónde conseguir ayuda

Modificamos el código de facturación que las empresas ya tienen en marcha, incluidos los entornos más antiguos: la generación de registros, la cadena de huellas, el QR en tus plantillas y el cliente de remisión a la AEAT, dejando pruebas automatizadas. Nuestro servicio de integración de facturación electrónica cubre el desarrollo, y el mantenimiento de sistemas heredados es por donde se empieza cuando ya no queda nadie que sepa cómo funciona el programa antiguo.

Si tienes la fecha del 1 de enero de 2027 y un sistema a medida, escribe a office@c9group.dev. Somos ingenieros, no asesores fiscales: las cuestiones de alcance y de responsabilidad le corresponden al tuyo, y nosotros desarrollamos según la respuesta que dé.