VERI*FACTU y factura electrónica en España: qué cambia y cómo preparar tus sistemas
VERI*FACTU y la factura electrónica B2B son obligaciones relacionadas, pero distintas. Revisamos los plazos vigentes y cómo preparar un ERP, ecommerce o aplicación propia sin limitarse a añadir un PDF o un código QR.
España está cambiando dos piezas del proceso de facturación al mismo tiempo. Una regula cómo deben funcionar los programas que generan facturas y suele resumirse bajo el nombre VERI*FACTU. La otra obliga progresivamente a intercambiar facturas electrónicas estructuradas entre empresarios y profesionales. Están relacionadas, pero no son la misma norma ni tienen el mismo calendario.
Para una empresa que utiliza un ERP, un ecommerce, una aplicación PHP o un sistema desarrollado a medida, prepararse exige revisar el momento en que nace la factura, sus datos, correcciones, trazabilidad e integración con terceros. Añadir un QR al PDF al final del proceso no convierte por sí solo el sistema en conforme.
Primero: VERI*FACTU no es sinónimo de factura electrónica B2B
El Reglamento de requisitos de los sistemas informáticos de facturación, aprobado por el Real Decreto 1007/2023, se ocupa de los programas utilizados para expedir facturas. Cuando aplica, el sistema debe generar registros de facturación normalizados y proteger su integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad.
La factura electrónica B2B, desarrollada por la Ley 18/2022 y el Real Decreto 238/2026, regula el intercambio de facturas entre empresas y profesionales mediante formatos estructurados y plataformas interoperables. Un PDF enviado por correo puede ser una representación legible, pero no equivale necesariamente a la factura electrónica estructurada prevista por este sistema.
VERI*FACTU regula el registro fiable de la facturación; la factura electrónica B2B regula cómo se emite, recibe e intercambia la factura entre empresas. Un mismo proyecto puede necesitar resolver ambas capas.
Plazos de VERI*FACTU vigentes en agosto de 2026
La AEAT indica que los contribuyentes del Impuesto sobre Sociedades incluidos en el reglamento deben tener adaptados sus sistemas antes del 1 de enero de 2027. Para el resto de obligados tributarios incluidos, entre ellos muchos autónomos con actividad económica, la fecha es el 1 de julio de 2027. El periodo anterior se considera un periodo de pruebas.
El ámbito no se decide únicamente por el tamaño del negocio. La AEAT resume cuatro exclusiones relevantes: facturación exclusivamente manual, adscripción obligatoria o voluntaria al SII, sujeción a normativa foral del País Vasco o Navarra, o una resolución vigente de no aplicación. También existen particularidades por operación y régimen, por lo que cada empresa debe confirmar su situación con su asesor fiscal.
Dos modalidades válidas para el sistema de facturación
En modalidad VERI*FACTU, el sistema remite de forma continuada los registros de facturación a la sede de la AEAT. En modalidad NO VERI*FACTU, no se realiza esa remisión inmediata, pero el propio sistema debe conservar los registros con requisitos adicionales de seguridad, firma y registro de eventos.
Elegir NO VERI*FACTU no significa seguir trabajando como antes. Ambas modalidades deben generar registros de alta y anulación, encadenarlos mediante huella y cumplir las especificaciones aplicables. La modalidad adecuada depende de conectividad, operación, custodia, soporte y complejidad técnica, no solo de una preferencia por enviar o no enviar datos.
Qué ocurre con la factura electrónica entre empresas
El Real Decreto 238/2026 define un sistema formado por plataformas privadas y una solución pública gestionada por la AEAT. Prevé formatos estructurados, interoperabilidad, copia a la solución pública cuando se utilicen determinadas plataformas privadas y comunicación de estados de la factura.
Su aplicación efectiva está vinculada a la orden ministerial que desarrolle la solución pública. Una vez completado ese desarrollo, la Ley 18/2022 establece un plazo de un año para empresas con facturación anual superior a ocho millones de euros y de dos años para el resto. Por tanto, no es prudente anunciar una fecha cerrada para toda pyme hasta que esa orden se publique y comience formalmente el cómputo.
Qué debe revisar un sistema existente
El punto de partida es dibujar el flujo real: quién crea un borrador, cuándo se asignan número y serie, qué acción convierte el documento en factura expedida, cómo se rectifica y qué sistemas reciben el resultado. En muchas aplicaciones esos límites no están claros porque pedido, albarán, cobro y factura comparten estados o tablas.
Después hay que inventariar series, tipos de factura, impuestos, destinatarios, operaciones especiales y datos que hoy se corrigen directamente en base de datos. Un registro ya generado no debe editarse como si nunca hubiera existido: los errores requieren el procedimiento de anulación o rectificación que corresponda, conservando la trazabilidad.
Arquitectura práctica para una integración VERI*FACTU
En un desarrollo propio conviene separar la lógica comercial del adaptador fiscal. La aplicación confirma la expedición; un módulo construye el registro normalizado, calcula y conserva el encadenamiento, genera los datos del QR y guarda un estado inmutable de la operación. Si se utiliza la modalidad VERI*FACTU, una cola de envío comunica el registro con la AEAT y procesa la respuesta.
Factura expedida
→ registro de alta
→ validación y huella encadenada
→ almacenamiento inmutable
→ cola de envío a AEAT, si aplica
→ respuesta, estado y trazabilidad
→ QR y documento entregado al clienteLa cola no debe crear otra factura al reintentar. Necesita identificadores estables, idempotencia, registro de intentos y distinción entre errores temporales y rechazos que requieren corregir datos. También hay que contemplar pérdida de conexión, indisponibilidad temporal, certificados, reloj del sistema, renovación de credenciales y alertas operativas.
Comprar una solución, integrar un proveedor o desarrollar
Un negocio con pocas facturas y un proceso sencillo puede valorar la aplicación gratuita de la AEAT o un producto ya adaptado. Una empresa con ERP, ecommerce, suscripciones, varias series o procesos propios puede necesitar integrar un proveedor mediante API. El desarrollo completo tiene sentido cuando la facturación forma parte de una aplicación propia y existe capacidad real para mantener normativa, versiones y soporte.
La AEAT no publica una homologación individual de cada producto como sustituto del análisis. El productor del sistema debe aportar una declaración responsable visible para el sistema y su versión. Al evaluar una solución conviene pedir esa declaración, alcance funcional, modalidad soportada, política de actualizaciones, exportación de datos y procedimiento ante incidencias.
WordPress y WooCommerce: el pedido no siempre es la factura
WooCommerce gestiona pedidos y puede generar documentos mediante extensiones, pero hay que identificar qué componente expide realmente la factura fiscal. Instalar un plugin de QR en la tienda no resuelve el registro, encadenamiento, anulaciones, declaración responsable ni comunicación con la AEAT.
Si la factura se genera en un ERP externo, la adaptación puede corresponder principalmente a ese ERP y a la integración que recibe el pedido. Si se genera dentro de WordPress, hay que revisar el plugin concreto, su versión, compatibilidad con rectificativas y series, y cómo se recupera ante fallos. Evitar dos emisores reduce numeraciones duplicadas y estados contradictorios.
Pruebas que conviene realizar antes del cambio
La prueba debe incluir algo más que una factura ordinaria. Conviene cubrir factura completa y simplificada cuando aplique, varias series, rectificación, anulación, impuestos diferentes, cliente extranjero, caída de conexión, respuesta rechazada, reintento y recuperación después de reiniciar un proceso.
También debe comprobarse que una persona no pueda borrar o reescribir silenciosamente el historial desde la interfaz o mediante una tarea administrativa. Los backups, logs y exportaciones tienen que permitir recuperar la operación sin romper la cadena ni perder las respuestas recibidas.
Checklist para hablar con tu proveedor o equipo técnico
Pregunta qué aplicación expide la factura, qué modalidad soportará, quién firma la declaración responsable, cómo gestiona altas, anulaciones y rectificativas, qué ocurre sin conexión, cómo evita duplicados, dónde conserva registros y eventos, cómo actualiza certificados y especificaciones, y cómo se exporta la información si cambias de proveedor.
Para la futura factura electrónica B2B, pregunta además qué formatos estructurados admite, cómo se conecta con la solución pública o plataformas privadas, cómo recibe facturas de proveedores, cómo comunica estados y qué cambios necesita contabilidad para conciliar documentos y pagos.
Qué hacer ahora
El paso útil en 2026 es completar el inventario y probar la solución elegida, no esperar al último mes. Identifica sujetos y operaciones con asesoría fiscal, localiza el emisor real, decide modalidad, solicita documentación al proveedor y prepara un entorno de pruebas con casos normales y fallos.
Este artículo ofrece una guía técnica general basada en normativa y documentación oficial disponible el 24 de agosto de 2026. No sustituye el análisis fiscal o jurídico de una actividad concreta; los plazos y especificaciones deben volver a verificarse antes de una implantación.