e-Invoicing mandates and updates: Spain

October 2026: The clock is running. Large companies have until October 6, 2027.

On October 5, 2026, Spain published Order HAC/1028/2026 in the Official State Gazette (BOE). It entered into force the next day, and with it, the countdown to mandatory B2B e-invoicing in Spain officially started.

For four years, Spain’s B2B mandate had a law behind it but no start date. The Crea y Crece law (Law 18/2022) created the obligation back in 2022. Royal Decree 238/2026 filled in the rules this March. But the deadlines could only start counting once the ministerial order for the Spanish Tax Agency’s (AEAT) public e-invoicing solution was in force. As of October 6, it is.

Here’s what that means in practice. If your Spanish entity had a volume of operations above €8 million last year, you must issue and receive structured e-invoices from October 6, 2027. Everyone else follows on October 6, 2028. If you were waiting for a firm date before starting your Spain project, you now have one, and it’s less than a year away.

The dates that matter

Spain B2B e-invoicing and VERI*FACTU milestones, 2026 to 2029

Every e-invoicing date counts from October 6, 2026, the day the order took effect. The AEAT must open its public solution at least two months before the first wave goes live.

How the Spanish model works

Spain has chosen a mixed model. Businesses can exchange invoices through the AEAT’s public e-invoicing solution, which is free to use, through a private e-invoicing platform, or through a combination of both.

The important detail is what happens on the private route. Every invoice exchanged through a private platform must also be sent, at the same moment, to the AEAT as a faithful copy (copia fiel) in UBL. Whichever route an invoice takes, the tax agency sees it.

Formats. Invoices sent through the public solution use UBL on the EN 16931 semantic model. Private platforms can also use UN/CEFACT CII, EDIFACT or Facturae, but the copy that goes to the AEAT is always UBL. In other words, your platform has to map whatever your trading partners exchange into a valid UBL copy, with no embedded attachments.

Peppol. Peppol can carry invoices between private platforms, but Spain has not made it the national network. A Peppol connection on its own won’t make you compliant: you still need the faithful copy, the Spanish validation rules and the status reporting described below.

Scope. The obligation applies when a business or professional invoices another business or professional established in Spain, and the transaction is directed to that Spanish establishment. A Spanish VAT registration alone doesn’t settle the question, so foreign companies selling into Spain should check where their customers are established and which establishment each transaction goes to.

It’s not just the invoice: Status and payment reporting

This is where Spain goes further than a pure exchange model, and it comes from the law’s original purpose: tackling late payment. The buyer must report to the AEAT when it rejects an invoice, the payment due date, and the date the invoice is paid in full. If an invoice isn’t rejected, it’s presumed accepted. Suppliers can also report collection or non-payment, but that part is voluntary.

That puts a reporting obligation on accounts payable and treasury, not just on whoever sends the invoices. Payment dates have to flow from your ERP or treasury system to your e-invoicing platform. If your project plan only covers invoice issuing, it’s missing this piece.

Two transition rules are worth knowing:

• A PDF alongside the invoice, for one year. From October 6, 2027 to October 5, 2028, large companies must send a readable PDF with each structured invoice unless the customer agrees to receive the structured invoice only. The PDF goes to the customer and must never be embedded in, or sent to, the AEAT’s solution.
• Later status reporting for the smallest players. Individuals and income-attribution entities with a volume of operations up to €8 million don’t have to report statuses until October 6, 2029.

Three regimes, one invoice: Crea y Crece, VERI*FACTU and SII

Spain runs several regimes that all touch the invoice. They are legally separate, and the new order doesn’t replace any of them.

A word of caution on VERI*FACTU. On October 5, the Ministry of Finance announced it would move the pending VERI*FACTU obligations to October 2028, so they line up with the second e-invoicing wave. At the time of writing, that change hasn’t been published in the BOE. Until it is, January 1, 2027 remains the legal date for corporate income tax payers, and that’s about nine weeks away. Plan against the date in the BOE, not the press release.

And ViDA. Spain built its model on EN 16931, the same standard behind the EU’s VAT in the Digital Age (ViDA) package, whose cross-border e-invoicing and digital reporting rules apply from July 1, 2030. That’s a good foundation, but being compliant in Spain won’t automatically make you ViDA-ready.

What you should be doing right now

If you have entities in Spain, here’s the checklist:

• Work out your wave, entity by entity. The €8 million threshold is the volume of operations under Article 121 of the Spanish VAT law for the previous calendar year. It’s assessed per Spanish entity, not on group revenue.
• Get ready to receive, even if you issue later. Your large suppliers start sending structured invoices on October 6, 2027. Your accounts payable process needs to handle them, whatever your own issuing date.
• Choose your route. The public solution is free to use. A private platform lets you keep the formats your trading partners already use, but it must produce the faithful UBL copy for every invoice. Many enterprises will end up using both.
• Bring AP and treasury into the project. Rejections, due dates and payment dates all have to be reported. That data lives in your ERP and treasury systems, not in your invoicing tool.
• Don’t solve Spain on its own. VERI*FACTU, SII and FACe all sit next to the new mandate. And for most multinationals, Spain is one deadline among many: France went live in September, Belgium and Poland earlier this year, and Germany’s next phase starts in January 2027.

How OpenText can help

OpenText™ Trading Grid™ e-Invoicing is delivered as a managed service. It connects your ERP and finance systems, inbound and outbound, direct and indirect, to the networks and government platforms your trading partners and tax authorities use, and our team keeps you compliant as the rules change. One platform covers Spain alongside the other country mandates on your map, so you don’t add another vendor for every new deadline.

For Spain, OpenText Trading Grid e-Invoicing will connect to the AEAT’s public e-invoicing solution, send the faithful UBL copy of every invoice, and support invoice status and payment reporting. It will handle all four exchange formats: UBL, CII, EDIFACT and Facturae. OpenText will support the Spanish mandate requirements in advance of the regulatory deadlines, so customers have enough time to test, validate and prepare for compliance.

Our e-Invoicing mandate readiness check service can also assess whether the output from your ERP, finance and accounting systems meets the new requirements.

Eleven months goes quickly when the project touches AR, AP, treasury and IT at the same time. Reach out to your OpenText account representative or contact us here to talk through your Spain readiness.

Sources

Disclaimer: This blog is intended to reflect the direction the industry is moving and does not reflect a commitment for the OpenText Trading Grid e-Invoicing product development roadmap to meet any particular stated regulations.

Legal disclaimer: The information contained in this blog is for general guidance on matters of interest only. The authors are not herein rendering legal, accounting, tax or other professional advice and the content should not be used as a substitute for consultation with professional accounting, tax, legal or other competent advisers. While we make every attempt to ensure the accuracy of the information contained within is from reliable sources, OpenText is not responsible for any errors or omissions, or for any result.