Spain's E-Invoicing Reform Is Making Invoices
More Complex — Not Less

One Country, Three E-Invoicing Systems — and They Don't Talk to Each Other

The assumption most non-Spanish businesses make when they hear "Spain is implementing e-invoicing" is that there is a single national system. There is not. Spain has three parallel regulatory frameworks governing how invoices are created, signed, transmitted, and stored, and they serve different purposes under different legal authorities:

These three systems are not alternatives to each other. They coexist. A company in Madrid with €5 million in turnover must comply with Verifactu for how its invoicing software generates records, and Crea y Crece for how it sends and receives B2B invoices. A company in Bilbao must comply with TicketBAI instead of Verifactu, plus Crea y Crece for B2B transmission. A company with €10 million in turnover already on SII is exempt from Verifactu but must comply with Crea y Crece. The Venn diagram is not three separate circles — it is overlapping obligations that vary by location, company size, and existing compliance status.

Verifactu: The National Standard That Keeps Getting Delayed

Verifactu is the component of Spain's anti-fraud legislation (Ley 11/2021, amending Artículo 29.2.j of the Ley General Tributaria) that regulates invoicing software. The core requirement: every computer system that generates invoices in Spain must produce tamper-proof, cryptographically chained invoice records — a digital fingerprint (hash) that links each invoice to the previous one, creating an unbreakable audit chain. Invoices must carry a QR code for verification against the AEAT's database. Software that allows deletion or modification of invoice records without leaving an audit trail is banned.

The deadline has slid twice. Originally set for July 1, 2025, it was first postponed to 2026 and then, via Real Decreto-Ley 15/2025 of December 2, 2025, pushed to January 1, 2027 for corporate taxpayers and July 1, 2027 for autónomos. Software vendors were required to stop selling non-compliant systems as of July 29, 2025 — a deadline that passed with partial readiness. The AEAT maintains a list of certified software, and as of mid-2026, major platforms like Holded, Quipu, and Billin are Verifactu-ready, but thousands of smaller billing tools and custom ERP modules are not.

What Verifactu means for the recipient of an invoice is a new visual element: the QR code. Under Verifactu mode (real-time transmission to AEAT, optional but encouraged), the invoice carries the label "VeriFactu" or "Factura verificable en la sede electrónica de la AEAT" and a QR code that links to the AEAT's verification portal. Under non-Verifactu mode (secure local storage, no automatic transmission), the invoice still carries the QR code and the chained hash but does not have the "VeriFactu" label. From the recipient's perspective, both modes produce invoices that look different from pre-Verifactu invoices — but the underlying data fields (NIF, Base Imponible, IVA, IRPF) are the same.

TicketBAI: Why the Basque Country Built Its Own System

Spain's autonomous communities with foral tax authority — the Basque Country and Navarre — have the constitutional right to administer their own tax systems. The Basque Country used this authority to create TicketBAI, an anti-fraud invoicing system that is conceptually similar to Verifactu but operationally separate. TicketBAI was developed by the three Foral Treasuries (Álava, Gipuzkoa, Bizkaia) in collaboration with the Basque Government.

TicketBAI requires real-time transmission of invoice data at the moment of issuance — not optional, as it is under Verifactu. Each province implements it slightly differently: Gipuzkoa and Álava require immediate transmission to their respective Foral Tax Authorities, while Bizkaia (under the Batuz framework) allows transmission within a specified timeframe and integrates additional accounting data (LROE books). By 2023, Álava alone was processing 300,000 TicketBAI invoices per day, according to data from the provincial tax authority.

The format difference matters for AP teams that receive invoices from Basque Country suppliers. A TicketBAI invoice carries a TBAI identification code and a QR code that resolves to the Foral Tax Authority's verification portal — not the AEAT's. The XML chain uses a different signature mechanism than Verifactu. Labels on the invoice may appear in Euskara (Basque language) alongside or instead of Spanish: "Guztira" for Total, "Oinarria" for Taxable Base, "BEZ" for IVA. None of these differences affect the core data fields — the amounts, the tax IDs, the rates are the same. But they do affect any tool that relies on matching Spanish-language labels to identify fields.

Crea y Crece: The B2B Mandate That Adds Another Layer

While Verifactu and TicketBAI regulate how invoicing software generates invoices, Ley Crea y Crece governs how those invoices are transmitted between businesses. Article 12 of the law mandates that all B2B invoices must be electronic, in a structured format, and exchanged through an interoperable platform ecosystem. The implementing regulation, Real Decreto 238/2026, was approved by the Council of Ministers on March 24, 2026, and published in the BOE on March 31, 2026.

The timeline is triggered by a forthcoming Ministerial Order (expected to enter into force on October 1, 2026), which starts the compliance countdown:

• 12 months after the Order (expected October 2027): Businesses with annual turnover above €8 million must issue and receive B2B e-invoices
• 24 months after the Order (expected October 2028): All remaining businesses and professionals, including autónomos, must comply
• 36 months after the Order (expected October 2029): Smaller entities must also report payment status data to the AEAT

The accepted formats are the European standard EN 16931, implemented as FacturaE, UBL 2.1, or CII. Notably, the draft Ministerial Order signals a shift from FacturaE to UBL as the primary format for the public platform. Recipients must report invoice status — acceptance, rejection, full or partial payment — to the AEAT within four calendar days. The public platform (SPFE, Sistema Público de Facturación Electrónica) will be operated by the AEAT and made available for free, alongside interoperable private platforms.

For AP teams, Crea y Crece means two things. First, the format of incoming invoices will change: suppliers who previously sent PDFs will begin sending structured electronic invoices. Second, and more problematic, the transition will produce a long tail of mixed formats: some suppliers will have switched to UBL/CII, others will still be on FacturaE, and a significant number will fall through the cracks entirely and continue sending whatever they sent before — penalties notwithstanding.

The AP Nightmare Scenario: When You Receive All Three Formats

Take a realistic scenario from mid-2027. A Madrid-based distribution company with €4 million in turnover receives 80 supplier invoices per month. Its suppliers include:

• 35 suppliers from Madrid, Barcelona, Valencia: All issuing Verifactu-compliant invoices. Some in "Verifactu mode" with real-time AEAT transmission and the "VeriFactu" label on the document. Others in non-Verifactu mode with the QR code but no real-time flag. The invoice layout varies by supplier's billing platform — Holded, Quipu, Billin, Sage, FacturaDirecta, or a custom ERP module.
• 12 suppliers from the Basque Country (Bilbao, San Sebastián, Vitoria-Gasteiz): All issuing TicketBAI invoices with TBAI codes. Some labels in Euskara. QR codes that resolve to Foral Tax Authority portals, not the AEAT. The XML chain uses a different hashing mechanism.
• 8 suppliers who are micro-businesses or older companies: Still issuing non-Verifactu, non-TicketBAI PDFs from legacy software that hasn't been updated. These invoices are technically non-compliant, but they arrive in the inbox and must be processed nonetheless.
• 5 EU-based suppliers: Sending invoices under the reverse-charge mechanism with 0% IVA and the "Inversión del sujeto pasivo" note. These follow neither Verifactu nor TicketBAI.
• 20 suppliers who have already switched to Crea y Crece B2B: Sending UBL or FacturaE structured invoices that need to be acknowledged within 4 days.

The AP team's inbox contains four format regimes (Verifactu, TicketBAI, legacy, Crea y Crece B2B), two tax authority jurisdictions, at least three software ecosystems generating different visual layouts, and a mix of structured (XML/UBL) and unstructured (PDF) formats. The team's job has not changed: get the NIF, Base Imponible, IVA breakdown, IRPF retention, and Importe Total into the accounting system. The format fragmentation has simply made that job harder.

No single Spanish accounting platform handles all four formats seamlessly. Holded recognizes FacturaE and Verifactu but does not process TicketBAI XML. A TicketBAI-certified Basque platform processes TBAI invoices but may not handle the specific UBL variant that Crea y Crece requires. An enterprise SII platform processes real-time AEAT data but was not built to ingest PDFs from micro-suppliers. The extraction step — getting the data out of whatever format arrives — remains the universal bottleneck.

What This Means for AP Teams: Format Fragmentation and Data Extraction

The structural problem is not that any one of these systems is poorly designed. Verifactu's hash-chaining is cryptographically sound. TicketBAI's real-time transmission has measurably reduced VAT fraud in the Basque Country. Crea y Crece's 4-day status reporting addresses Spain's chronic late-payment problem, which has been above the EU average for a decade.

The problem is that nobody designed for the recipient who receives all of them. The legislation was written from the issuer's perspective: "when you issue an invoice, here is how to make it compliant." The recipient's perspective — "when 80 suppliers send you invoices in 80 different compliance formats, here is how to extract the data" — was left as an implementation detail for the market to solve.

This is not unique to Spain. Italy's FatturaPA system, France's upcoming e-invoicing mandate, and Germany's planned ViDA implementation all create similar fragmentation at their borders. What makes Spain's case acute is the simultaneity: three major reforms converging in a 12-month window (2027), affecting different segments of the supplier base at different times, with no unified format specification across the three systems.

The operational response for AP teams is not to wait for format unification — it will not come. The response is to decouple the extraction step from the compliance format. A tool that reads the visual layer of an invoice does not care whether the QR code resolves to the AEAT or the Foral Tax Authority of Gipuzkoa. It reads the fields that matter to AP — NIF, Base Imponible, IVA, IRPF, Total — the same way regardless of which compliance infrastructure generated the document.

The Software Certification Problem: Your Supplier's Tool Dictates Your Data Format

Under both Verifactu and TicketBAI, the obligation to use certified software falls on the issuer. The recipient has no control over what software the supplier uses and, by extension, no control over the format the invoice arrives in. This creates an asymmetry: the supplier can comply with the law by purchasing any certified billing tool, and the recipient must absorb whatever output that tool produces.

Worse, the certification process itself is still in progress. The AEAT's list of Verifactu-certified software is growing but incomplete. Some major ERP vendors received certification in early 2026; smaller niche tools for specific industries are still pending. During this gap, suppliers may use tools that claim to be "Verifactu-ready" but produce output that diverges from the final specification. The recipient receives a document that looks compliant but fails validation against the current standard.

The penalty structure reinforces the asymmetry. Under Verifactu, a business using non-compliant software can be fined up to €50,000 per fiscal year. The software vendor can be fined up to €150,000 per year per non-compliant product. There is no penalty for receiving a non-compliant invoice — only for issuing one. The compliance burden falls entirely on the supply side, but the operational burden of processing whatever comes in falls entirely on the demand side.

A Practical Path Through the Transition (2026–2028)

For AP teams processing Spanish supplier invoices, the next two years require a strategy that assumes format diversity rather than hoping for convergence. The practical steps:

1. Accept that your inbox will contain mixed formats through at least 2029. The Crea y Crece rollout, even with the Ministerial Order published on schedule, gives small suppliers until late 2028 to comply — and enforcement will lag the legal deadline. A portion of suppliers will continue sending pre-reform PDFs well past the cutoff.

2. Build your AP workflow around format-agnostic data extraction. The common denominator across Verifactu, TicketBAI, Crea y Crece, and legacy formats is the visual data: NIF, amounts, IVA rates, IRPF retention, dates. A tool that extracts these fields from the rendered document (rather than parsing XML or matching templates) works identically on all formats. This eliminates the need to maintain separate processing paths for different invoice types. For details on setting up this workflow, see extracting Spanish invoice data to Excel for single invoices and batch processing Spanish supplier invoices for multi-supplier workflows.

3. Isolate the compliance layer from the data layer. The QR code on a Verifactu or TicketBAI invoice is useful for tax verification and audit defense. It is not useful for data entry. Do not mix these two functions. Store the original invoice file (with QR code and digital signature intact) for compliance archiving — Spanish law requires 4-year retention for tax purposes and 6 years under the Commercial Code. Extract the data separately into your accounting system. The two outputs serve different purposes and should not constrain each other.

4. Plan for Basque Country suppliers separately. If your AP volume includes significant TicketBAI invoices, confirm that your extraction tool handles Euskara labels and does not depend on matching Spanish text strings. "Guztira" should be recognized as the total amount. "BEZ" should be recognized as IVA. This is a language adaptation issue, not a format issue.

5. Monitor the Crea y Crece status reporting requirement. The 4-day invoice acceptance/rejection/payment status reporting obligation takes effect for large businesses first (expected October 2027) and cascades to smaller entities. This is a new operational task that did not exist before. Start building the process for tracking invoice receipt dates and generating status reports in parallel with your data extraction workflow. The public platform (SPFE) will provide the reporting interface, but you need internal systems to feed it.

For a broader analysis of how document extraction works across Spanish-speaking markets and what tools are available at different price points, see affordable extraction tools for Spanish-speaking markets. For a comparison across EU markets, see budget invoice extraction for French TPEs.

FAQ

Is Verifactu the same as mandatory e-invoicing?

No. Verifactu governs how invoicing software generates and stores invoice records — it is an anti-fraud measure about software integrity. Crea y Crece governs how B2B invoices are transmitted between businesses in structured electronic format — it is an e-invoicing mandate about data exchange. They are separate legal instruments with separate deadlines, although both took effect in the 2025-2028 window. Invoices generated on the Crea y Crece public platform will automatically be Verifactu-compliant, unifying the two obligations for users of the public solution.

Do I need to validate the QR code on every Verifactu invoice I receive?

You are not legally required to verify the QR code on received invoices. However, the QR code is your only defense if the AEAT questions the validity of a supplier invoice during an audit. Scanning the code confirms that the invoice was properly registered in the AEAT's system and has not been altered. For high-value invoices or new supplier relationships, QR verification is recommended as a compliance safeguard. For routine invoices from established suppliers, the QR code can be archived with the original document without real-time verification.

What happens if I receive a Verifactu invoice from a supplier who should be on TicketBAI?

A supplier with fiscal residency in the Basque Country should issue TicketBAI invoices, not Verifactu invoices. If they issue a Verifactu-compliant invoice instead, the non-compliance is on their side — they are violating their TicketBAI obligation, and the Foral Tax Authority can penalize them. As the recipient, you are not liable for the supplier's compliance failure. You can process the invoice normally; the underlying data fields are structurally the same. However, flag it with the supplier: their non-compliance could surface during a cross-reference between Verifactu and TicketBAI databases, potentially delaying your IVA deduction.

Will the transition to UBL under Crea y Crece affect my AP extraction workflow?

Not if your extraction tool reads the visual layer rather than parsing XML. The shift from FacturaE to UBL changes the underlying XML schema but not the visual appearance of the invoice as rendered in a PDF viewer. The fields you extract — NIF, Base Imponible, IVA, IRPF, Total — remain the same regardless of whether the source XML is FacturaE, UBL 2.1, or CII. If your workflow depends on XML parsing (e.g., a script that extracts data directly from FacturaE XML tags), you will need to update your parser for UBL. If you extract data from the visual document, the format change is irrelevant.

How do I handle IRPF retention on Verifactu and TicketBAI invoices?

IRPF retention is a field-level element on the invoice, not a format-level element. Whether the invoice was generated by Verifactu-certified software in Madrid or TicketBAI-certified software in San Sebastián, the IRPF line looks the same: a percentage (15% or 7%), a euro amount, and a negative sign. Extract it as a separate column. For batch aggregation and cross-checking against Modelo 111, the format origin of the invoice is irrelevant — only the IRPF amount matters.

The Reform Paradox

Spain's e-invoicing reform is not a single reform. It is three reforms, running on overlapping timelines, serving different policy goals (anti-fraud, late-payment reduction, tax transparency), administered by different authorities (AEAT for Verifactu and Crea y Crece, Foral Treasuries for TicketBAI), and producing documents that converge on a single point: the AP inbox. The reforms were designed to bring order to Spain's invoicing ecosystem by replacing a free-for-all of paper, PDF, and unstructured formats with a structured, traceable system. What they have produced, in the transition window that runs through at least 2029, is the opposite: more formats, more compliance vectors, and more ways for the data to arrive in a structure that your accounting software cannot natively ingest. The paradox resolves only when the extraction step is separated from the format. Read what is on the page, not what generated the page. The rest follows.