VERI*FACTU, be or not to be

Durante los últimos años se ha ido cocinando uno de los cambios más importantes que han vivido los programas de facturación en España: la adaptación a los nuevos requisitos de los Sistemas Informáticos de Facturación, lo que casi todo el mundo ha acabado conociendo simplemente como VERI*FACTU.

Y aquí conviene hacer ya la primera aclaración.

VERI*FACTU no es exactamente, como a veces se simplifica, «enviar todas las facturas instantáneamente a Hacienda».

Es algo más que eso.

La nueva normativa establece cómo deben funcionar los programas que intervienen en la facturación, con el objetivo de que los registros generados sean íntegros, trazables y no puedan ser alterados sin dejar rastro. Las facturas emitidas mediante estos sistemas deben incorporar, entre otros requisitos, un código QR tributario y generar el correspondiente registro de facturación.

Después veremos que, en realidad, existen dos maneras de cumplir esta normativa: VERI*FACTU y NO VERI*FACTU.

Pero no nos adelantemos.

Una historia que debía empezar en 2026

Desarrolladores de software, empresas, autónomos, asesorías y gestorías llevaban tiempo preparándose para la entrada en funcionamiento de los nuevos requisitos.

Nosotros también.

El calendario situaba 2026 como el año de la adaptación obligatoria.

Y entonces, cuando faltaba aproximadamente un mes para una de las principales fechas de entrada en vigor, llegó la sorpresa:

se aplazó un año más.

El Real Decreto-ley 15/2025, publicado el 3 de diciembre de 2025, modificó nuevamente los plazos.

El calendario vigente, a fecha de este artículo, establece:

• antes del 1 de enero de 2027 para los contribuyentes a los que se refiere el artículo 3.1.a) del reglamento, esencialmente los contribuyentes del Impuesto sobre Sociedades;
• antes del 1 de julio de 2027 para el resto de obligados tributarios incluidos en el artículo 3.1.

Por tanto, primera cosa importante:

no todos los obligados tienen como fecha el 1 de enero de 2027.

¿Por qué se aplazó?

No entraremos a valorar los motivos políticos. No es el objeto de este artículo.

Pero desde el punto de vista técnico sí podemos entender parte del problema.

El parque de aplicaciones de gestión existente en España es enorme.

Hay programas nuevos, programas con veinte o treinta años de historia, desarrollos a medida, aplicaciones verticales y ERPs que han ido creciendo durante décadas.

Y adaptar un ERP a VERI*FACTU no siempre consiste en añadir cuatro campos y un botón de enviar.

Nosotros mismos lo hemos vivido.

Cuando adaptar significaba crear un Frankenstein

La generación anterior de nuestro ERP, Hilvania 33, había ido evolucionando durante muchos años.

Tenía muchísimas funcionalidades incorporadas, automatismos y procesos que habían nacido de las necesidades reales de nuestros clientes.

Pero llegó VERI*FACTU.

Y después de estudiar qué implicaba realmente la adaptación, llegamos a una conclusión:

Hilvania 33 no tenía posibilidades humanas de adaptarse a todo lo que venía sin acabar convirtiéndose en un Frankenstein.

Seguramente habríamos podido hacerlo funcionar.

Pero una cosa es conseguir que una aplicación funcione y otra es construir una buena base para los próximos años.

Así que tomamos una decisión bastante más complicada:

empezar de nuevo.

No diremos que haya sido fácil.

No lo ha sido.

Cuando rehaces un ERP descubres que hay cientos de pequeñas funcionalidades que se han ido incorporando durante años y que los usuarios ya consideran naturales.

Pero hoy estamos contentos de haber tomado aquella decisión.

Y, curiosamente, el aplazamiento nos ha dado algo que no esperábamos:

tiempo.

Tiempo para recuperar funcionalidades del anterior Hilvania.

Tiempo para replantear otras.

Y tiempo para incorporar herramientas nuevas mucho más potentes.

Pero... ¿qué es exactamente VERI*FACTU?

Intentemos explicarlo sin hablar como el BOE.

Cuando una empresa hace una factura con un sistema informático afectado por esta normativa, el programa debe generar un registro de facturación con una estructura y unas garantías determinadas.

El objetivo es que exista trazabilidad sobre aquello que se ha facturado.

Además, las facturas generadas por los SIF afectados deben incorporar el correspondiente QR tributario.

Y aquí aparecen dos posibilidades.

VERI*FACTU

El sistema remite los registros de facturación a la Sede electrónica de la Agencia Tributaria inmediatamente después de generarlos.

La AEAT los conserva y el receptor de la factura puede utilizar el QR para comprobar determinados datos en la Sede electrónica.

NO VERI*FACTU

También es una modalidad prevista por la normativa.

En este caso los registros no se remiten automáticamente a la AEAT, pero el sistema debe asumir requisitos adicionales de seguridad, entre ellos la firma de los registros y la gestión y conservación de un registro de eventos.

Por tanto:

VERI*FACTU no es la única manera prevista de cumplir el reglamento.

Esto es importante porque a menudo se utiliza la palabra VERI*FACTU para referirse a toda la nueva normativa, cuando técnicamente no es exactamente lo mismo.

¿A quién afecta?

Aquí es donde las cosas se complican un poco más.

La normativa establece qué empresarios y profesionales están dentro del ámbito de aplicación y existen excepciones.

Una de las más importantes es el Suministro Inmediato de Información (SII).

Los contribuyentes sometidos al SII están excluidos del RRSIF en lo que respecta a sus propias facturas.

Por eso no nos gusta dar una regla del tipo:

«Si eres autónomo, te afecta.»

o

«Si tienes una sociedad, te afecta.»

La realidad fiscal puede ser más compleja.

Si tienes dudas sobre si la normativa es aplicable concretamente a tu empresa o actividad, consúltalo con tu asesor fiscal o gestor de confianza.

Un programa informático puede ayudarte a cumplir una obligación.

Pero no debe decidir cuáles son tus obligaciones tributarias.

Algo que nos ha sorprendido: VERI*FACTU pone orden

Nosotros hemos estado probando VERI*FACTU en real.

No solo desarrollando contra unas especificaciones o haciendo pruebas teóricas.

Y funciona bastante bien.

Pero hay una consecuencia que, al menos nosotros, no valorábamos especialmente cuando empezamos el proyecto:

pone orden en la facturación.

Cuando cada factura deja un registro, cuando una anulación debe seguir su proceso, cuando existe una cadena y cuando todo debe tener coherencia, inevitablemente desaparecen algunas malas prácticas que los programas antiguos permitían.

Y el orden permite autogestionarse mejor.

Sin ninguna duda.

No queremos convertir esto en una defensa ciega de VERI*FACTU. Habrá cosas mejorables, aparecerán incidencias y seguramente todavía veremos cambios.

Pero después de haberlo implementado y probado, esta es una de las conclusiones que nosotros hemos sacado.

Mi ERP dice que es «compatible con VERI*FACTU». ¿Quién lo certifica?

Esta es una pregunta especialmente interesante.

Podríamos pensar que existe una lista de Hacienda con los programas homologados.

Pero el sistema no funciona exactamente así.

Son los productores o fabricantes del sistema informático quienes deben certificar, mediante una declaración responsable, que el sistema cumple los requisitos establecidos.

Esta declaración debe existir por escrito, ser visible dentro del sistema y corresponder a cada versión.

Es decir:

no basta con poner una pegatina en la web que diga «Compatible con VERI*FACTU».

Detrás hay una responsabilidad del fabricante.

En Hilvania nos parece especialmente importante esta diferencia.

Por este motivo también hemos consultado directamente a la Agencia Tributaria sobre la existencia actual o futura de un registro público de fabricantes o programas y sobre los procedimientos que deberían seguir los desarrolladores.

Actualizaremos este artículo cuando tengamos respuesta.

¿Y qué pasará el 1 de enero de 2027?

Aquí volvemos al título de este artículo.

VERI*FACTU, be or not to be.

A día de hoy, la normativa vigente dice lo que dice.

Para los obligados correspondientes, los sistemas deben estar adaptados antes del 1 de enero de 2027. Para el resto de obligados afectados, antes del 1 de julio de 2027.

Nuestro pensamiento es que esta vez se activará.

Pero eso es exactamente eso: nuestro pensamiento, no una información oficial.

Y como los plazos ya se han aplazado anteriormente, hemos decidido hacer algo más sencillo que especular.

Se lo hemos preguntado a Hacienda.

Hemos presentado una consulta a la Agencia Tributaria preguntando, entre otras cuestiones, si existe actualmente alguna previsión que pueda comportar un nuevo cambio del calendario y hasta qué momento sería jurídicamente posible modificar estas fechas.

Cuando tengamos respuesta, actualizaremos este mismo artículo.

Nosotros tenemos claro qué debemos hacer

Mientras tanto, en Hilvania no trabajaremos pensando si alguien volverá a pulsar el botón de aplazar.

Continuaremos preparando el programa para que cumpla lo que establece la normativa vigente.

Porque si llega el 1 de enero de 2027 y se activa:

estamos preparados.

Y si llega el 1 de enero y finalmente vuelve a cambiar algo:

también estaremos mejor que hace dos años.

Tendremos un ERP más moderno, una facturación más ordenada, una arquitectura mejor preparada y muchas funcionalidades que probablemente no habrían nacido sin habernos visto obligados a replantear muchas cosas.

Y esto nos ha recordado algo que a veces olvidamos cuando trabajamos con tecnología:

A veces, los árboles no nos dejan ver el bosque.

VERI*FACTU era el árbol.

Mejorar Hilvania era el bosque.