Sistemas de facturación y VERI*FACTU: qué requisitos y documentos conviene comprobar

Para comprobar un sistema de facturación necesitas conocer la obligación que te afecta, identificar la versión instalada y revisar cómo genera, conserva y comunica sus registros. Un mensaje comercial que diga «adaptado» no sustituye esa comprobación.

VERI*FACTU es una modalidad dentro del régimen de sistemas informáticos de facturación. Entender esa diferencia permite pedir los documentos adecuados y preparar la transición sin confundirla con la factura electrónica obligatoria entre empresas.

Primero comprueba si tu actividad entra en el ámbito

El artículo 3 del Reglamento de sistemas informáticos de facturación incluye determinados contribuyentes del Impuesto sobre Sociedades, personas físicas con actividades económicas, establecimientos permanentes y entidades en atribución de rentas que desarrollen actividades económicas, cuando utilicen esos sistemas.

Existen exclusiones y especialidades. Los contribuyentes que llevan los libros del IVA mediante el Suministro Inmediato de Información quedan fuera de este reglamento. Las entidades total o parcialmente exentas requieren revisar su situación concreta.

También importan el domicilio fiscal y las reglas de los territorios forales. No traslades automáticamente las obligaciones del territorio común a cualquier negocio situado en España.

La revisión debe incluir las operaciones realizadas y el modo de expedir las facturas. Que una herramienta se llame «gestión», «caja» o «plantilla» no determina por sí solo su tratamiento: hay que analizar qué hace realmente.

Qué fechas de adaptación debes tener presentes

Según la disposición final cuarta vigente del Real Decreto 1007/2023, los sujetos del artículo 3.1.a), correspondientes al Impuesto sobre Sociedades dentro del ámbito aplicable, deben tener sus sistemas adaptados antes del 1 de enero de 2027. Para el resto de obligados del artículo 3.1, la fecha es antes del 1 de julio de 2027.

Estas fechas proceden del calendario actualizado; no deben sustituirse por plazos antiguos de folletos o artículos sin revisar. Tampoco son las fechas generales de la factura electrónica entre empresas.

Organiza la preparación con margen: análisis, actualización, migración, pruebas y formación. Tener contratado un servicio no demuestra que la instalación utilizada esté operativa y correctamente configurada.

Qué diferencia hay entre VERI*FACTU y la modalidad sin remisión continua

El reglamento permite sistemas que remiten los registros a la AEAT mediante la modalidad VERI*FACTU y sistemas que no realizan esa remisión continua, sujetos a requisitos específicos de conservación y control.

Aspecto	VERI*FACTU	Sin remisión continua
Registros	Se remiten conforme al procedimiento previsto.	Se conservan con las garantías exigidas.
Controles técnicos	Existen simplificaciones ligadas a la remisión.	Se exigen controles adicionales propios de esta modalidad.
Conservación de facturas	Sigue siendo necesaria.	Sigue siendo necesaria.
Revisión práctica	Envíos, respuestas e incidencias.	Conservación, firma, eventos y exportación.

La modalidad sin remisión continua no equivale a un programa libre de obligaciones. El sistema debe reunir las características exigidas y disponer de capacidad de remisión en los términos normativos.

Antes de activar o cambiar una modalidad, confirma sus condiciones y efectos. No se trata de un interruptor que deba utilizarse de forma improvisada para decidir qué facturas comunicar.

La declaración responsable debe identificar la versión concreta

El productor certifica el cumplimiento mediante una declaración responsable. La AEAT aclara que este mecanismo no requiere una certificación externa ni un registro previo del producto.

Por tanto, una declaración del fabricante no debe presentarse como una homologación concedida por Hacienda. Revisa quién la emite, a qué producto se refiere y si cubre la versión que utilizas.

El artículo 15 de la Orden HAC/1177/2024 concreta el contenido y la ubicación de la declaración. Entre los datos que conviene contrastar están:

• Nombre y código identificador del sistema.
• Identificación completa de la versión.
• Componentes y principales funcionalidades.
• Indicación sobre funcionamiento exclusivo como VERI*FACTU, cuando corresponda.
• Posibilidad de atender a varios obligados tributarios.
• Identificación y contacto del productor.
• Manifestación de cumplimiento, fecha y lugar de suscripción.

La declaración debe estar accesible dentro del sistema y a disposición del cliente. Conserva la correspondiente a cada versión utilizada y registra cuándo se realizó la actualización.

Si existen ampliaciones o componentes de distintos productores, comprueba la documentación que corresponde a cada uno. Una declaración de un componente no describe automáticamente toda la instalación.

Revisa que los errores se corrijan dejando rastro

El artículo 8 del reglamento exige integridad, trazabilidad e inalterabilidad de los registros. Las correcciones o anulaciones deben reflejarse mediante registros posteriores, conservando la información originalmente registrada.

Eso debe traducirse en un procedimiento comprensible para quien factura. Diferencia editar un borrador de corregir una factura expedida y distingue la rectificación del documento de la subsanación técnica de un registro.

Por ejemplo, si se ha aplicado un tipo impositivo incorrecto, no basta con cambiar una cifra en una pantalla histórica. Hay que determinar la rectificación que procede y su reflejo en los registros y obligaciones correspondientes.

Solicita una demostración con un caso controlado. Comprueba qué puede ver el usuario antes y después, qué referencias se conservan y cómo se evita ocultar el documento inicial.

Comprueba los envíos, las respuestas y las incidencias

En VERI*FACTU, verifica quién realiza la remisión y con qué identificación o representación. El responsable de facturación debe poder distinguir un registro pendiente, aceptado, rechazado o con resultado por revisar según las respuestas del servicio.

No confundas «enviado» con «aceptado». Si se produce un fallo de comunicación, debe existir un procedimiento que gestione el reintento sin perder información ni duplicar actuaciones.

Pregunta cómo se detecta una cola bloqueada y quién recibe el aviso. Una incidencia que solo aparece en un registro técnico inaccesible para el negocio puede permanecer sin resolver.

Comprueba también la entrega al cliente: la remisión tributaria no acredita por sí sola que el destinatario haya recibido la factura. Son procesos que pueden compartir una herramienta, pero necesitan controles distintos.

El QR no sustituye el resto de comprobaciones

El código QR previsto por la normativa facilita actuaciones de consulta o remisión de información. En los sistemas verificables permite comprobar, en los términos establecidos, la información remitida a la AEAT.

No certifica que la operación exista, que el IVA sea correcto o que el cliente haya pagado. Tampoco convierte un presupuesto o un documento con contenido insuficiente en una factura válida.

Al probar la salida del sistema, revisa número y serie, fechas, datos identificativos, concepto, bases, impuestos y menciones exigibles. Comprueba la legibilidad del documento y el funcionamiento del QR o del contenido que proceda en su formato.

Documentos que conviene guardar antes de empezar

Prepara una carpeta de implantación con evidencias concretas. Su finalidad es que otra persona pueda entender qué se instaló, qué se comprobó y cómo actuar ante un problema.

• Declaración responsable de la versión y de los componentes correspondientes.
• Descripción del modo de funcionamiento y su configuración.
• Contrato, mantenimiento y condiciones de actualización.
• Procedimiento de rectificación, anulación y subsanación.
• Instrucciones para incidencias y recuperación del servicio.
• Procedimiento de exportación, conservación y acceso posterior.
• Resultados de las pruebas y responsables de resolver diferencias.
• Relación de usuarios, permisos y autorizaciones necesarias.

Estos documentos no sustituyen el cumplimiento real. Una instalación puede tener documentación completa y estar mal configurada; por eso debe comprobarse también el comportamiento efectivo.

Pruebas mínimas antes de utilizarlo con operaciones reales

Utiliza un entorno de prueba adecuado y casos representativos del negocio. Evita generar facturas reales ficticias para aprender: una operación de prueba dentro de un sistema operativo puede producir documentos y registros efectivos.

1. Prepara una factura ordinaria con importes calculados previamente.

2. Comprueba series, fechas y datos del destinatario.

3. Ensaya una rectificación y verifica la relación con el documento inicial.

4. Simula un rechazo o fallo de comunicación de forma controlada.

5. Revisa los permisos de una persona que solo debe consultar.

6. Exporta documentación y comprueba que puede leerse y relacionarse.

7. Registra incidencias y repite únicamente los casos corregidos.

Si una prueba no tiene un resultado esperado definido, es difícil saber si ha pasado. Antes de ejecutarla, escribe qué documento debe existir, qué estado debe mostrar y qué actuación debe quedar bloqueada.

No confundas esta adaptación con la factura electrónica B2B

El Real Decreto 238/2026 regula el sistema de factura electrónica obligatoria entre empresarios y profesionales, con requisitos de intercambio estructurado y un calendario propio de aplicación efectiva.

Un sistema puede necesitar atender ambos regímenes. Pide que la documentación explique cada capacidad por separado: registros tributarios, factura estructurada, entrega, estados y conservación.

La decisión práctica consiste en verificar todo el circuito que necesita tu actividad. Una única etiqueta comercial no explica qué funciones están disponibles ni cuáles requieren configuración o adaptación adicional.