VERI*FACTU no es un nuevo tipo de factura ni otra forma de llamar a la factura electrónica. El cambio está en algo menos visible, pero mucho más importante: cómo debe comportarse el software que utilizamos para facturar.
A partir de 2027, los sistemas informáticos afectados deberán generar registros de facturación íntegros, trazables y protegidos frente a modificaciones que no dejen rastro.
Las empresas sujetas al Impuesto sobre Sociedades deberán tener sus sistemas adaptados antes del 1 de enero de 2027. Para el resto de obligados incluidos en el reglamento, entre ellos muchos autónomos con actividad económica, el plazo llega hasta el 1 de julio de 2027. La propia AEAT mantiene actualmente estas dos fechas como entrada obligatoria del RRSIF.
Queda margen, pero no demasiado si la empresa utiliza un ERP con personalizaciones, diferentes series de facturación, varios usuarios o integraciones con otros sistemas.
La adaptación no consiste simplemente en añadir un QR a las facturas.
Detrás de VERI*FACTU está el Reglamento de Requisitos de los Sistemas Informáticos de Facturación, conocido como RRSIF y aprobado mediante el Real Decreto 1007/2023.
La norma regula principalmente las condiciones que debe cumplir el software utilizado para facturar.
El sistema debe garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros de facturación.
Cada vez que se expide una factura, el programa debe generar automáticamente su correspondiente registro de facturación de alta.
Ese registro no es la factura que recibe el cliente. Es información estructurada generada por el propio sistema y sometida a controles destinados a detectar alteraciones. La AEAT distingue expresamente el registro de facturación de la factura y exige además el encadenamiento de registros mediante huella o hash.
Desde el punto de vista de un ERP, este es uno de los cambios fundamentales.
Durante años, muchos programas de gestión han permitido corregir documentos ya emitidos con demasiada libertad.
Cambiar una fecha, modificar un importe o alterar determinados datos podía convertirse en una simple edición dentro de la base de datos.
El nuevo marco busca precisamente impedir que eso ocurra sin dejar rastro.
Los registros de facturación se encadenan mediante mecanismos de huella o hash. Parte de la información del registro anterior interviene en la generación del siguiente, creando una secuencia que permite detectar modificaciones posteriores.
Si hay que corregir una operación, el sistema debe hacerlo mediante los procedimientos correspondientes. El registro original no se reescribe silenciosamente como si nunca hubiera existido.
Para cualquier ERP, esto obliga a distinguir con claridad entre:
borrador → documento pendiente → factura expedida → rectificación o anulación posterior
La pantalla que utiliza el usuario puede seguir siendo sencilla. Lo que cambia es el control que existe por debajo.
Una de las confusiones más habituales es pensar que todas las empresas estarán obligadas a enviar automáticamente cada factura a la Agencia Tributaria.
El reglamento contempla dos modalidades válidas.
El sistema remite los registros de facturación electrónicamente a la Agencia Tributaria inmediatamente después de generarlos.
Esa remisión aporta las garantías de conservación e inalterabilidad previstas por la normativa y permite posteriormente el cotejo de las facturas verificables mediante el QR incorporado a la factura.
Los registros no se envían de forma continuada a la AEAT.
En este caso, el propio sistema debe asumir requisitos adicionales de seguridad. Entre ellos están la firma electrónica de los registros de facturación y de eventos y la generación y conservación de un registro de eventos del sistema.
Las dos modalidades forman parte del marco regulado.
Por tanto, antes de implantar una solución conviene decidir cuál encaja mejor con la operativa de la empresa en lugar de asumir que todos los negocios deberán funcionar necesariamente del mismo modo.
Las facturas expedidas mediante los sistemas afectados incorporarán el código QR tributario previsto en la normativa.
En las facturas VERI*FACTU, ese QR permite acceder al mecanismo correspondiente para cotejar la información remitida a la Agencia Tributaria.
Las facturas generadas mediante un sistema NO VERI*FACTU también incorporan QR, aunque en ese caso su función no es acreditar que exista un registro previamente remitido a la AEAT.
Pero adaptar un programa a VERI*FACTU no consiste en colocar un QR en el PDF.
Eso es sólo la parte visible.
El trabajo importante está detrás: generación del registro, encadenamiento, trazabilidad, tratamiento de rectificaciones y anulaciones, conservación de la información y, cuando proceda, comunicación con la Administración.
El calendario actualmente vigente queda así:
Estas fechas no deberían utilizarse como punto de partida de una migración.
Actualizar un programa estándar puede ser relativamente sencillo. Cambiar un ERP completo, migrar históricos, revisar desarrollos propios y probar integraciones es otra cosa.
Con carácter general, el RRSIF afecta a empresarios y profesionales que utilicen sistemas informáticos de facturación y se encuentren dentro de su ámbito de aplicación.
Entre ellos están los contribuyentes del Impuesto sobre Sociedades, profesionales y empresarios que desarrollan actividades económicas sujetas a IRPF y determinados establecimientos permanentes.
Existen excepciones y particularidades.
Por ejemplo, los contribuyentes que llevan sus libros registro mediante el Suministro Inmediato de Información (SII) quedan fuera del RRSIF respecto de las operaciones correspondientes.
También hay que tener en cuenta los regímenes tributarios forales del País Vasco y Navarra.
Antes de configurar un ERP, por tanto, hay una pregunta previa que conviene responder: qué normativa afecta realmente a esa empresa y a sus operaciones.
Esta diferencia es especialmente importante.
VERI*FACTU y el RRSIF regulan principalmente cómo debe funcionar el sistema informático con el que se factura y qué registros debe generar.
La factura electrónica entre empresas y profesionales regula cómo se expiden, transmiten y reciben electrónicamente las facturas B2B.
Ambos marcos forman parte del proceso de digitalización de la facturación, pero resuelven problemas distintos y sus calendarios tampoco son los mismos.
En marzo de 2026 se publicó el Real Decreto 238/2026, que desarrolla el sistema de factura electrónica obligatoria entre empresarios y profesionales.
Su aplicación efectiva no comienza automáticamente en 2027. La norma establece que el cómputo arrancará cuando entre en vigor la orden ministerial que desarrolle la solución pública de facturación electrónica. A partir de ese momento habrá 12 meses para empresarios y profesionales cuyo volumen de operaciones supere los 8 millones de euros y 24 meses para el resto.
Por eso:
cumplir VERI*FACTU no significa haber resuelto automáticamente la factura electrónica B2B.
Un ERP tendrá que ser capaz de convivir con ambos escenarios.
Más allá de mensajes comerciales como “compatible con VERI*FACTU”, merece la pena comprobar algunos puntos concretos:
Este punto merece una explicación específica porque ambos conceptos pueden confundirse.
En la implantación prevista por Aress para QuantumERP, cada cliente utilizará su propio certificado electrónico cualificado.
Aress no utilizará un certificado propio para firmar o autenticar fiscalmente los registros de sus clientes.
En modalidad VERIFACTU, los registros se remiten a la Agencia Tributaria mediante una comunicación autenticada con certificado electrónico cualificado. Como esa comunicación ya incorpora autenticación y se realiza mediante medios seguros, los registros VERIFACTU no están obligados a llevar una firma electrónica explícita adicional.
En modalidad NO VERI*FACTU sí existe una exigencia adicional: los registros de facturación y de eventos deben quedar firmados electrónicamente por el sistema conforme a las especificaciones previstas.
La declaración responsable del sistema informático de facturación pertenece a otro plano.
No determina quién firma o remite los registros fiscales del cliente. Es el instrumento mediante el que el productor declara que un determinado sistema o componente de facturación, en una versión concreta, cumple los requisitos establecidos por el RRSIF.
Por tanto, en QuantumERP pueden coexistir perfectamente ambas cosas:
La AEAT admite también que la remisión VERI*FACTU se efectúe mediante certificados de terceros que actúen como representantes, apoderados o colaboradores sociales, pero ése no es el modelo de funcionamiento planteado para QuantumERP.
Aquí aparece una diferencia importante respecto a un programa de facturación cerrado.
QuantumERP está pensado para adaptarse a procesos empresariales donde antes de una factura pueden existir presupuestos, pedidos, albaranes, órdenes de trabajo, partes, proyectos o certificaciones.
Después pueden intervenir cobros, contabilidad, documentación, almacén o integraciones con otros sistemas.
La empresa no trabaja sólo con la factura.
Y precisamente por eso una adaptación a VERI*FACTU no debería limitarse a colocar un módulo nuevo encima de la operativa existente.
Hay que revisar el proceso completo.
¿Quién puede emitir una factura?
¿Cuándo deja de ser un borrador?
¿Qué series utiliza cada actividad?
¿Cómo se corrige un error?
¿Qué ocurre con una factura rectificativa?
¿Qué información procede de otros módulos?
¿Qué integraciones se ejecutan cuando la factura queda expedida?
Cuanto más personalizado sea el ERP, más importante resulta tener estas respuestas claras.
VERI*FACTU no impide personalizar un ERP.
QuantumERP puede seguir adaptándose a la operativa de cada empresa: formularios, permisos, órdenes de trabajo, proyectos, almacén, gestión documental, procesos sectoriales o integraciones pueden evolucionar sin que cada modificación implique necesariamente una nueva declaración responsable del sistema de facturación.
La diferencia está en si la personalización altera o no la implementación de los requisitos exigidos por el RRSIF.
La Agencia Tributaria ha aclarado específicamente este punto para los desarrolladores: si una personalización no cambia la implementación de los requisitos del RRSIF, puede seguir siendo válida la declaración responsable del producto estándar. Si modifica cómo se implementan esos requisitos, entonces sí debe tratarse como una alteración del componente de facturación y requiere su correspondiente declaración responsable.
Un ejemplo sencillo: modificar dónde aparece visualmente el QR dentro de los límites permitidos puede ser una personalización legítima. Permitir que el usuario suprima un QR obligatorio alteraría, en cambio, el cumplimiento del sistema.
Esto permite conservar una de las ventajas de un ERP personalizable sin perder el control sobre la parte fiscal: evolucionar la gestión empresarial manteniendo claramente delimitado el componente encargado de la facturación regulada.
En una implantación real, un orden razonable sería:
Para algunas empresas será una actualización relativamente pequeña.
Para otras, especialmente cuando existen años de personalizaciones o varios programas conectados entre sí, puede convertirse en un buen momento para revisar el ERP completo.
No necesariamente.
Si el sistema actual está mantenido, se adapta correctamente y sigue cubriendo las necesidades de la empresa, VERI*FACTU no es por sí solo un motivo para sustituirlo.
El escenario es diferente cuando la facturación depende de aplicaciones antiguas, hojas de cálculo, procesos manuales, duplicidades o desarrollos que cada vez resulta más difícil mantener.
En ese caso, invertir otra vez en adaptar la arquitectura existente puede significar aplazar un problema que ya estaba ahí.
VERI*FACTU puede convertirse entonces en un punto de corte razonable para revisar el sistema completo.
No porque Hacienda obligue a cambiar de ERP.
Porque, si hay que intervenir de todas formas, puede ser el momento adecuado para evitar hacer el trabajo dos veces.
QuantumERP tiene sentido cuando la facturación forma parte de una operativa más amplia: diferentes perfiles de usuario, procesos sectoriales, gestión documental, integraciones, migraciones o desarrollos específicos.
Si una actividad sólo necesita emitir unas pocas facturas y prácticamente no tiene procesos adicionales, probablemente no necesite un ERP personalizado.
El objetivo no es instalar más software.
Es conseguir que el sistema se adapte suficientemente bien a la empresa y pueda evolucionar sin que cada cambio normativo obligue a reconstruir la operativa.
En Aress podemos revisar el circuito actual de facturación, identificar qué partes merece la pena conservar y determinar qué tendría sentido adaptar o migrar a QuantumERP.
La obligación llega en 2027. La decisión sobre cómo llegar conviene tomarla antes.