La prórroga da a las empresas un año más. No cambia nada para quien desarrolla un sistema de facturación, donde la sanción llega a los 150.000 € por producto y año.
La mayor parte de lo que se lee ahora sobre VeriFactu dice lo mismo, en tono tranquilizador: se ha aplazado a 2027, relájese. Eso es cierto para la empresa que emite las facturas. No lo es para quien desarrolló el sistema que las emite.
Lo que ha ocurrido realmente
La normativa procede del Real Decreto 1007/2023. Después se retrasó un año mediante el Real Decreto-ley 15/2025, del 2 de diciembre de 2025 y en vigor dos días después.
Las nuevas fechas para los contribuyentes:
- 1 de enero de 2027 — empresas sujetas al Impuesto sobre Sociedades
- 1 de julio de 2027 — el resto de obligados, incluidos los autónomos que tributan por IRPF
Así que una tienda, una clínica o una inmobiliaria tienen un año más para migrar a un software conforme. Bien.
La parte que no se ha movido
La prórroga cubre a los usuarios de los sistemas de facturación. No cubre a los productores y comercializadores de ese software, cuyo plazo se fijó en nueve meses desde la Orden HAC/1177/2024 —el 29 de julio de 2025— y se ha quedado exactamente donde estaba.
La sanción por un producto no conforme llega hasta 150.000 € al año, por cada tipo de sistema o programa comercializado. No por cliente. Por producto, por año.
Si usted encargó una plataforma a medida que emite facturas, esa responsabilidad recae en quien la desarrolló y la suministra. Ese párrafo casi nadie lo lee, hasta que lo lee una inspección.
Lo que exige realmente la normativa
Cada factura debe generar un registro de facturación en el momento de su emisión, y ese registro debe incluir:
- un hash de su propio contenido,
- datos del registro inmediatamente anterior, de forma que la cadena sea trazable y una factura eliminada se haga visible como un hueco,
- una firma electrónica en los casos que señala la normativa,
- un código QR en la propia factura,
- y bien el envío automático a la AEAT, bien su conservación en un formato que la AEAT pueda exigir.
El encadenamiento es la restricción técnica interesante. Significa que los registros de facturación son un libro de solo adición, no filas que se puedan editar. La mayoría del código de facturación a medida que hemos heredado trata la factura como un registro editable cualquiera, y esa suposición es la que hay que eliminar.
Si usted dirige un negocio aquí
Dos preguntas, y son rápidas.
¿Su software de facturación tiene una declaración VeriFactu por escrito? Los proveedores conformes publican una declaración responsable. Si el suyo no puede mostrarle una, ahí tiene la respuesta.
¿Alguna parte de su facturación es a medida? Un plugin que alguien escribió para su checkout de WooCommerce, un script que envía PDF por correo, un módulo de ERP que un freelance desarrolló en 2019. Eso son sistemas a efectos de la normativa, y las plataformas estándar no los cubren automáticamente.
Si usted desarrolla software para clientes en España
Revise lo que ya ha entregado. Una funcionalidad de facturación escrita antes de mediados de 2025 casi con toda seguridad no es conforme, y la responsabilidad no es teórica.
La postura honesta ante un cliente es esta: el plazo de la plataforma es 2027, el del desarrollador fue el año pasado, y cerrar esa brecha sale más barato ahora que durante una inspección.
Lo que no haríamos
No trataríamos 2027 como una excusa para esperar. El requisito de encadenamiento es arquitectónico —cambia cómo se almacenan las facturas, no el aspecto de un formulario— y los cambios arquitectónicos son los que salen mal cuando se hacen deprisa contra una fecha límite.