La reforma de facturación electrónica en España complica las facturas
Más complejas, no menos

Un país, tres sistemas de facturación electrónica (y no se comunican entre sí)

La mayoría de las empresas no españolas asumen que, al oír que "España está implementando la facturación electrónica", existe un único sistema nacional. No es así. España cuenta con tres marcos regulatorios paralelos que rigen cómo se crean, firman, transmiten y almacenan las facturas, y cada uno sirve a propósitos distintos bajo autoridades legales diferentes:

Estos tres sistemas no son alternativos entre sí. Conviven. Una empresa en Madrid con 5 millones de euros de facturación debe cumplir Verifactu para que su software genere los registros, y Crea y Crece para enviar y recibir facturas B2B. Una empresa en Bilbao debe cumplir TicketBAI en lugar de Verifactu, más Crea y Crece para la transmisión B2B. Una empresa con 10 millones de euros ya en SII está exenta de Verifactu, pero debe cumplir Crea y Crece. El diagrama de Venn no son tres círculos separados: son obligaciones superpuestas que varían según la ubicación, el tamaño de la empresa y el estado de cumplimiento actual.

Verifactu: el estándar nacional que no deja de retrasarse

Verifactu es el componente de la ley antifraude española (Ley 11/2021, que modifica el artículo 29.2.j de la Ley General Tributaria) que regula el software de facturación. El requisito clave: todo sistema informático que genere facturas en España debe producir registros de factura a prueba de manipulaciones, encadenados criptográficamente — una huella digital (hash) que vincula cada factura con la anterior, creando una cadena de auditoría irrompible. Las facturas deben incluir un código QR para su verificación contra la base de datos de la AEAT. Queda prohibido el software que permita eliminar o modificar registros de facturas sin dejar rastro de auditoría.

El plazo se ha retrasado dos veces. Originalmente fijado para el 1 de julio de 2025, primero se aplazó a 2026 y luego, mediante el Real Decreto-Ley 15/2025 del 2 de diciembre de 2025, se trasladó al 1 de enero de 2027 para los contribuyentes empresariales y al 1 de julio de 2027 para los autónomos. Los proveedores de software debían dejar de vender sistemas no conformes a partir del 29 de julio de 2025 — un plazo que venció con una preparación parcial. La AEAT mantiene una lista de software certificado y, a mediados de 2026, plataformas importantes como Holded, Quipu y Billin ya son compatibles con Verifactu, pero miles de herramientas de facturación más pequeñas y módulos ERP personalizados aún no lo son.

Lo que Verifactu supone para el receptor de una factura es un nuevo elemento visual: el código QR. En modo Verifactu (transmisión en tiempo real a la AEAT, opcional pero recomendada), la factura lleva la etiqueta «VeriFactu» o «Factura verificable en la sede electrónica de la AEAT» y un código QR que enlaza al portal de verificación de la AEAT. En modo no Verifactu (almacenamiento local seguro, sin transmisión automática), la factura sigue llevando el código QR y el hash encadenado, pero no tiene la etiqueta «VeriFactu». Desde la perspectiva del receptor, ambos modos generan facturas con un aspecto diferente al de las facturas anteriores a Verifactu, pero los campos de datos subyacentes (NIF, Base Imponible, IVA, IRPF) son los mismos.

TicketBAI: Por qué el País Vasco creó su propio sistema

Las comunidades autónomas con hacienda foral —País Vasco y Navarra— tienen derecho constitucional a gestionar sus propios sistemas tributarios. El País Vasco usó esta facultad para crear TicketBAI, un sistema antifraude de facturación conceptualmente similar a Verifactu, pero operativamente independiente. TicketBAI fue desarrollado por las tres Haciendas Forales (Álava, Gipuzkoa, Bizkaia) en colaboración con el Gobierno Vasco.

TicketBAI exige la transmisión en tiempo real de los datos de la factura en el momento de su emisión —no es opcional, como en Verifactu. Cada provincia lo implementa con ligeras diferencias: Gipuzkoa y Álava requieren transmisión inmediata a sus respectivas Haciendas Forales, mientras que Bizkaia (en el marco Batuz) permite un plazo determinado e integra datos contables adicionales (libros LROE). En 2023, solo Álava procesaba 300.000 facturas TicketBAI al día, según datos de la hacienda foral.

La diferencia de formato importa para los equipos de AP que reciben facturas de proveedores vascos. Una factura TicketBAI lleva un código de identificación TBAI y un código QR que redirige al portal de verificación de la Hacienda Foral —no al de la AEAT. La cadena XML usa un mecanismo de firma distinto al de Verifactu. Las etiquetas pueden aparecer en euskera junto al castellano o en su lugar: "Guztira" por Total, "Oinarria" por Base Imponible, "BEZ" por IVA. Ninguna de estas diferencias afecta a los campos de datos esenciales —los importes, los NIF, los tipos impositivos son los mismos. Pero sí afectan a cualquier herramienta que dependa del reconocimiento de etiquetas en castellano para identificar campos.

Crea y Crece: La normativa B2B que añade una capa más

Mientras que Verifactu y TicketBAI regulan cómo el software de facturación genera las facturas, la Ley Crea y Crece regula cómo se transmiten esas facturas entre empresas. El artículo 12 de la ley establece que todas las facturas B2B deben ser electrónicas, en un formato estructurado e intercambiadas a través de un ecosistema de plataformas interoperables. El reglamento de desarrollo, Real Decreto 238/2026, fue aprobado por el Consejo de Ministros el 24 de marzo de 2026 y publicado en el BOE el 31 de marzo de 2026.

El calendario se activa con una próxima Orden Ministerial (previsiblemente en vigor el 1 de octubre de 2026), que inicia la cuenta atrás para el cumplimiento:

• 12 meses tras la Orden (previsto octubre 2027): Empresas con facturación anual superior a 8 millones de euros deben emitir y recibir facturas electrónicas B2B
• 24 meses tras la Orden (previsto octubre 2028): El resto de empresas y profesionales, incluidos autónomos, deben cumplir
• 36 meses tras la Orden (previsto octubre 2029): Entidades más pequeñas también deben reportar datos de estado de pago a la AEAT

Los formatos aceptados son el estándar europeo EN 16931, implementado como FacturaE, UBL 2.1 o CII. Cabe destacar que el borrador de la Orden Ministerial apunta a un cambio de FacturaE a UBL como formato principal para la plataforma pública. Los destinatarios deben reportar el estado de la factura —aceptación, rechazo, pago total o parcial— a la AEAT en un plazo de cuatro días naturales. La plataforma pública (SPFE, Sistema Público de Facturación Electrónica) será operada por la AEAT y estará disponible de forma gratuita, junto con plataformas privadas interoperables.

Para los equipos de AP, Crea y Crece implica dos cosas. Primero, cambiará el formato de las facturas entrantes: los proveedores que antes enviaban PDFs comenzarán a enviar facturas electrónicas estructuradas. Segundo, y más problemático, la transición generará una larga cola de formatos mixtos: algunos proveedores habrán migrado a UBL/CII, otros seguirán con FacturaE, y un número significativo caerá en el olvido y continuará enviando lo que siempre enviaron —sanciones aparte—.

La pesadilla de AP: cuando recibes los tres formatos

Imagina un escenario realista a mediados de 2027. Una distribuidora con sede en Madrid y 4 millones de euros de facturación recibe 80 facturas de proveedores al mes. Entre sus proveedores hay:

• 35 proveedores de Madrid, Barcelona, Valencia: Todos emiten facturas conformes a Verifactu. Algunas en "modo Verifactu" con transmisión en tiempo real a la AEAT y la etiqueta "VeriFactu" en el documento. Otras en modo no Verifactu con código QR pero sin el marcador de tiempo real. El diseño varía según la plataforma de facturación de cada proveedor: Holded, Quipu, Billin, Sage, FacturaDirecta o un módulo ERP propio.
• 12 proveedores del País Vasco (Bilbao, San Sebastián, Vitoria-Gasteiz): Todos emiten facturas TicketBAI con códigos TBAI. Algunas etiquetas en euskera. Los códigos QR redirigen a portales de las Haciendas Forales, no a la AEAT. La cadena XML usa un mecanismo de hash diferente.
• 8 proveedores que son microempresas o empresas antiguas: Siguen emitiendo PDFs no Verifactu ni TicketBAI desde software heredado sin actualizar. Estas facturas son técnicamente no conformes, pero llegan al buzón y deben procesarse igualmente.
• 5 proveedores de la UE: Envían facturas con inversión del sujeto pasivo al 0% de IVA y la nota "Inversión del sujeto pasivo". No siguen ni Verifactu ni TicketBAI.
• 20 proveedores que ya han migrado a Crea y Crece B2B: Envían facturas estructuradas UBL o FacturaE que deben acusarse en un plazo de 4 días.

El buzón del equipo de AP contiene cuatro regímenes de formato (Verifactu, TicketBAI, heredado, Crea y Crece B2B), dos jurisdicciones tributarias, al menos tres ecosistemas de software que generan diseños visuales distintos, y una mezcla de formatos estructurados (XML/UBL) y no estructurados (PDF). La tarea del equipo no ha cambiado: introducir el NIF, la Base Imponible, el desglose del IVA, la retención de IRPF y el Importe Total en el sistema contable. La fragmentación de formatos simplemente ha dificultado esa labor.

Ninguna plataforma contable española gestiona los cuatro formatos sin problemas. Holded reconoce FacturaE y Verifactu, pero no procesa XML de TicketBAI. Una plataforma vasca certificada para TicketBAI procesa facturas TBAI, pero puede no manejar la variante UBL específica que exige Crea y Crece. Una plataforma empresarial SII procesa datos en tiempo real de la AEAT, pero no fue diseñada para ingerir PDFs de microproveedores. El paso de extracción —obtener los datos del formato que llegue— sigue siendo el cuello de botella universal.

Lo que esto significa para los equipos de AP: fragmentación de formatos y extracción de datos

El problema estructural no es que ninguno de estos sistemas esté mal diseñado. El encadenamiento hash de Verifactu es criptográficamente sólido. La transmisión en tiempo real de TicketBAI ha reducido de forma medible el fraude del IVA en el País Vasco. El informe de estado a 4 días de Crea y Crece aborda el crónico problema de morosidad en España, que ha estado por encima de la media de la UE durante una década.

El problema es que nadie diseñó para el destinatario que los recibe todos. La legislación se redactó desde la perspectiva del emisor: «cuando emitas una factura, así es como la haces conforme». La perspectiva del destinatario —«cuando 80 proveedores te envían facturas en 80 formatos de cumplimiento diferentes, así es como extraes los datos»— quedó como un detalle de implementación que el mercado debía resolver.

Esto no es exclusivo de España. El sistema FatturaPA de Italia, el próximo mandato de facturación electrónica de Francia y la implementación prevista de ViDA en Alemania crean una fragmentación similar en sus fronteras. Lo que hace agudo el caso de España es la simultaneidad: tres grandes reformas convergiendo en una ventana de 12 meses (2027), que afectan a diferentes segmentos de la base de proveedores en distintos momentos, sin una especificación de formato unificada entre los tres sistemas.

La respuesta operativa para los equipos de AP no es esperar a la unificación de formatos —no llegará—. La respuesta es desacoplar el paso de extracción del formato de cumplimiento. Una herramienta que lee la capa visual de una factura no le importa si el código QR se resuelve en la AEAT o en la Hacienda Foral de Gipuzkoa. Lee los campos que importan a AP —NIF, Base Imponible, IVA, IRPF, Total— de la misma manera, independientemente de qué infraestructura de cumplimiento generó el documento.

El problema de la certificación del software: la herramienta de tu proveedor dicta el formato de tus datos

Tanto en Verifactu como en TicketBAI, la obligación de usar software certificado recae en el emisor. El receptor no controla qué software usa su proveedor y, por extensión, tampoco el formato en que llega la factura. Esto crea una asimetría: el proveedor cumple la ley comprando cualquier herramienta de facturación certificada, y el receptor debe asumir el resultado que esa herramienta genere.

Para colmo, el proceso de certificación aún está en marcha. La lista de software certificado Verifactu de la AEAT crece, pero está incompleta. Algunos grandes proveedores de ERP obtuvieron la certificación a principios de 2026; herramientas más pequeñas y específicas para ciertos sectores aún están pendientes. Durante este vacío, los proveedores pueden usar herramientas que se autodenominan «preparadas para Verifactu» pero que generan resultados que se desvían de la especificación final. El receptor recibe un documento que parece conforme, pero que no supera la validación según el estándar vigente.

La estructura de sanciones refuerza esta asimetría. En Verifactu, una empresa que use software no conforme puede ser multada hasta con 50.000 € por año fiscal. El proveedor de software puede ser multado hasta con 150.000 € al año por producto no conforme. No hay sanción por recibir una factura no conforme, solo por emitirla. La carga del cumplimiento recae íntegramente en el lado de la oferta, pero la carga operativa de procesar lo que llegue recae íntegramente en el lado de la demanda.

Un camino práctico durante la transición (2026–2028)

Para los equipos de Cuentas a Pagar que procesan facturas de proveedores españoles, los próximos dos años requieren una estrategia que asuma diversidad de formatos en lugar de esperar una convergencia. Los pasos prácticos:

1. Acepta que tu bandeja de entrada contendrá formatos mixtos al menos hasta 2029. El despliegue de Crea y Crece, incluso con la Orden Ministerial publicada a tiempo, da a los pequeños proveedores hasta finales de 2028 para cumplir, y la aplicación efectiva irá por detrás del plazo legal. Una parte de los proveedores seguirá enviando PDFs anteriores a la reforma mucho después de la fecha límite.

2. Construye tu flujo de Cuentas a Pagar en torno a la extracción de datos independiente del formato. El denominador común entre Verifactu, TicketBAI, Crea y Crece y los formatos heredados son los datos visuales: NIF, importes, tipos de IVA, retenciones de IRPF, fechas. Una herramienta que extraiga estos campos del documento renderizado (en lugar de analizar XML o buscar plantillas) funciona igual en todos los formatos. Esto elimina la necesidad de mantener rutas de procesamiento separadas para distintos tipos de factura. Para más detalles sobre cómo configurar este flujo, consulta cómo extraer datos de facturas españolas a Excel para facturas individuales y procesamiento por lotes de facturas de proveedores españoles para flujos con múltiples proveedores.

3. Separa la capa de cumplimiento normativo de la capa de datos. El código QR en una factura Verifactu o TicketBAI es útil para la verificación fiscal y la defensa en auditorías. No es útil para la entrada de datos. No mezcles estas dos funciones. Conserva el archivo de factura original (con el código QR y la firma digital intactos) para el archivo de cumplimiento: la ley española exige 4 años de retención a efectos fiscales y 6 años según el Código de Comercio. Extrae los datos por separado en tu sistema contable. Las dos salidas tienen propósitos distintos y no deben condicionarse mutuamente.

4. Planifica por separado para los proveedores del País Vasco. Si tu volumen de Cuentas a Pagar incluye facturas TicketBAI significativas, confirma que tu herramienta de extracción reconozca las etiquetas en euskera y no dependa de buscar cadenas de texto en español. «Guztira» debe reconocerse como el importe total. «BEZ» debe reconocerse como IVA. Es un problema de adaptación lingüística, no de formato.

5. Supervisa el requisito de reporte de estado de Crea y Crece. La obligación de reportar aceptación, rechazo o pago de facturas en 4 días aplica primero a grandes empresas (previsto para octubre de 2027) y luego se extiende a entidades más pequeñas. Es una tarea operativa nueva que antes no existía. Empieza a construir el proceso para rastrear fechas de recepción de facturas y generar reportes de estado en paralelo con tu flujo de extracción de datos. La plataforma pública (SPFE) proporcionará la interfaz de reporte, pero necesitas sistemas internos que la alimenten.

Para un análisis más amplio de cómo funciona la extracción de documentos en los mercados de habla hispana y qué herramientas están disponibles en diferentes rangos de precio, consulta herramientas de extracción asequibles para mercados hispanohablantes. Para una comparación entre mercados de la UE, consulta extracción de facturas económica para TPE francesas.

Preguntas frecuentes

¿Verifactu es lo mismo que la facturación electrónica obligatoria?

No. Verifactu regula cómo el software de facturación genera y almacena registros de facturas — es una medida antifraude sobre la integridad del software. Crea y Crece regula cómo se transmiten las facturas B2B entre empresas en formato electrónico estructurado — es un mandato de facturación electrónica sobre el intercambio de datos. Son instrumentos legales separados con plazos distintos, aunque ambos entraron en vigor en la ventana 2025-2028. Las facturas generadas en la plataforma pública de Crea y Crece cumplirán automáticamente con Verifactu, unificando ambas obligaciones para los usuarios de la solución pública.

¿Necesito validar el código QR en cada factura Verifactu que recibo?

No estás legalmente obligado a verificar el código QR en las facturas recibidas. Sin embargo, el código QR es tu única defensa si la AEAT cuestiona la validez de una factura de proveedor durante una auditoría. Escanear el código confirma que la factura se registró correctamente en el sistema de la AEAT y no ha sido alterada. Para facturas de alto valor o nuevas relaciones con proveedores, se recomienda la verificación del QR como salvaguarda de cumplimiento. Para facturas rutinarias de proveedores establecidos, el código QR puede archivarse con el documento original sin verificación en tiempo real.

¿Qué ocurre si recibo una factura Verifactu de un proveedor que debería estar en TicketBAI?

Un proveedor con residencia fiscal en el País Vasco debe emitir facturas TicketBAI, no Verifactu. Si emite una factura Verifactu, el incumplimiento es suyo: está violando su obligación TicketBAI, y la Hacienda Foral puede sancionarlo. Como receptor, usted no es responsable del incumplimiento del proveedor. Puede procesar la factura con normalidad; los campos de datos subyacentes son estructuralmente iguales. Sin embargo, notifique al proveedor: su incumplimiento podría detectarse en un cruce entre las bases de datos de Verifactu y TicketBAI, retrasando potencialmente su deducción de IVA.

¿Afectará la transición a UBL con Crea y Crece a mi flujo de extracción de AP?

No, si su herramienta de extracción lee la capa visual en lugar de analizar el XML. El cambio de FacturaE a UBL modifica el esquema XML subyacente, pero no la apariencia visual de la factura al renderizarse en un visor PDF. Los campos que extrae (NIF, Base Imponible, IVA, IRPF, Total) siguen siendo los mismos, independientemente de si el XML fuente es FacturaE, UBL 2.1 o CII. Si su flujo depende del análisis XML (p. ej., un script que extrae datos directamente de etiquetas FacturaE), deberá actualizar su analizador para UBL. Si extrae datos del documento visual, el cambio de formato es irrelevante.

¿Cómo gestiono la retención de IRPF en facturas Verifactu y TicketBAI?

La retención de IRPF es un elemento a nivel de campo en la factura, no un elemento de formato. Tanto si la factura la generó un software certificado Verifactu en Madrid como uno certificado TicketBAI en San Sebastián, la línea de IRPF tiene el mismo aspecto: un porcentaje (15% o 7%), un importe en euros y un signo negativo. Extráigalo como una columna separada. Para la agregación por lotes y el contraste con el Modelo 111, el origen del formato de la factura es irrelevante; solo importa el importe del IRPF.

La paradoja de la reforma

La reforma de facturación electrónica en España no es una reforma única. Son tres reformas, con plazos superpuestos, objetivos políticos distintos (antifraude, reducción de morosidad, transparencia fiscal), administradas por diferentes autoridades (AEAT para Verifactu y Crea y Crece, Haciendas Forales para TicketBAI), y que generan documentos que convergen en un único punto: la bandeja de entrada del PS. Las reformas fueron diseñadas para poner orden en el ecosistema de facturación español, sustituyendo un caos de papel, PDF y formatos no estructurados por un sistema estructurado y trazable. Lo que han producido, en el período de transición que se extiende al menos hasta 2029, es lo contrario: más formatos, más vectores de cumplimiento y más formas de que los datos lleguen en una estructura que su software contable no puede procesar de forma nativa. La paradoja se resuelve solo cuando se separa la extracción del formato. Lea lo que está en la página, no lo que generó la página. El resto viene después.