Spain's Mandatory B2B E-Invoicing from October 2027: What Custom and Legacy Systems Have to Change

From 6 October 2027, every business in Spain whose volumen de operaciones exceeded €8 million in the previous calendar year must issue, send and receive its invoices to other Spanish businesses as structured electronic invoices. From the same day, as a buyer, it must tell the tax agency when each supplier invoice was paid in full, or that it was rejected. Everyone else follows on 6 October 2028. The clock started on 6 October 2026.
The PDF your system emails today stops being the invoice. But the part that catches projects out sits on the other side of the ledger: accounts payable has to report the payment date and the due date of every supplier invoice it pays, within four days, not counting weekends and national holidays.
If your invoices and supplier payments run on a maintained commercial ERP, most of the issuing work is your vendor's. Ask what it ships for payment reporting too, since that depends on how your treasury records payments.
This article is for companies whose invoicing or accounts payable runs on something nobody sells an update for: an AS/400 application, an old Navision installation customised past the point of upgrade, a billing engine your own team wrote. Everything below is as of 16 October 2026.
The Dates
The mandate is article 2 bis of Ley 56/2007, as rewritten by article 12 of Ley 18/2022, the "Crea y Crece" law. The detail is in Real Decreto 238/2026, whose fourth final provision sets two phases, counted from the entry into force of the ministerial order on the public solution:
"a) Doce meses después, para los empresarios y profesionales cuyo volumen de operaciones, calculado conforme al artículo 121 de la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido, haya excedido de 8 millones de euros durante el año natural inmediato anterior. b) Veinticuatro meses después, para el resto de los empresarios y profesionales."
That order is Orden HAC/1028/2026, published in the BOE on 5 October 2026 and in force since 6 October. AEAT's implementation calendar turns it into dates:
| Who | Issue, send and receive e-invoices | Report invoice status and payments |
|---|---|---|
| Volumen de operaciones above €8 million | 6 October 2027 | 6 October 2027 |
| Everyone else: companies and other legal entities | 6 October 2028 | 6 October 2028 |
| Everyone else: individuals and entidades en régimen de atribución de rentas | 6 October 2028 | 6 October 2029 |
Private exchange platforms carry obligations of their own from 6 October 2027, whoever their customers are. AEAT's public solution must be available at least two months before the first date, so by early August 2027 at the latest.
Two details matter for planning. The threshold is measured as for VAT, over "el año natural inmediato anterior": read literally, 2026 for the October 2027 date, which your tax adviser should confirm. And for twelve months, a business above €8 million must send a PDF with each e-invoice "que asegure su legibilidad", unless the customer "acepte voluntaria y expresamente recibirlas en su formato original". The PDF never goes to AEAT.
Who Is In Scope, and Who Is Not
The obligation falls on any business or professional, as defined for VAT, that has to issue an invoice, when the customer is a business with its seat, a permanent establishment or its residence in Spain. AEAT's scope page adds that it covers operations subject to VAT, IGIC and IPSI, so the Canary Islands, Ceuta and Melilla are in.
Out of scope, according to the same page:
- Simplified invoices, except the qualified ones under article 7.2 of the invoicing regulation.
- Sales to consumers, and sales to businesses not established in Spain, intra-EU ones included.
- Operations the Ministry of Economy excludes by order, and certain regulated activities of the electricity and gas market operators and the IATA clearing houses.
Three things that are not exclusions:
- SII filers. Neither the decree nor AEAT's list mentions the Suministro Inmediato de Información. SII is compulsory for monthly VAT filers, and article 71.3 of the VAT regulation puts a business on monthly filing when its volumen de operaciones, computed the same way, exceeded €6,010,121.04 the year before. So every company in the October 2027 wave that files its VAT with AEAT is already in SII. That keeps them out of VERI*FACTU. It does not keep them out of this.
- The Basque Country and Navarra. VERI*FACTU stops at the foral border; this does not. The decree says the public solution will serve foral taxpayers through agreements between their tax authorities and AEAT.
- Self-billing and third-party invoicing. When the customer or a third party issues the invoice for you, the obligations stay yours.
How the System Works
There are two routes, and you can combine them: private exchange platforms, and a free public solution run by AEAT. Private platforms must connect to one another free of charge when a customer asks, so nobody is forced onto a customer's platform. A business that has not agreed with a supplier to receive through a private platform is treated as having chosen the public solution.
The invoice is a structured message on the EN 16931 semantic model, in one of four syntaxes: CII, UBL, EDIFACT or Facturae (article 7.1). The decree's preamble adds that Peppol BIS is valid on private platforms. The public solution accepts UBL only.
Whatever the route, AEAT ends up with every invoice. A system that does not issue through the public solution must send it "simultáneamente a su emisión una copia electrónica fiel de cada factura en la sintaxis UBL" (article 6.2). Under the order, the copy is flagged in the CopyIndicator field, carries no embedded files, and is refused if one with the same unique code exists; a rejected copy is fixed and resent, and the original stays valid. The unique code is the issuer's NIF, the series and number, and the issue date. Invoices issued through private platforms carry an advanced electronic signature, and web-service access to the public solution needs an electronic certificate.
The market is not starting from zero: the Ministry of Economy says "hoy se intercambian ya más de 550 millones de facturas electrónicas al año en España". What is new is that everyone has to, and that AEAT sees every invoice and every payment.
What a Custom System Has to Do
Issuing
- Invoices as data, not as a print layout. Each invoice has to exist as a structured record before it is sent. In older systems the VAT breakdown is often calculated by the report that prints the invoice and never stored.
- Clean master data. The public solution admits an invoice only when the issuer's and the recipient's NIF are correctly filled in. Free-text addresses, units and payment terms need mapping to codes.
- The Spanish extensions. The order's annex adds fields EN 16931 lacks: income tax withholding (retenciones), invoices issued by a third party, the location of a rented property, the type of national tax, and codes for the type and method of a rectifying invoice.
- A delivery route per customer: a private platform (and which), or the public solution.
- The UBL copy, at the moment of issue, unless you issue through the public solution. A platform may send it for you; if you connect directly, you build it.
- Corrections. The order lets you withdraw an invoice ("dar de baja") when the operation never existed. Other errors follow the ordinary invoicing rules, which in practice means rectifying invoices.
- The transitional PDF for twelve months, if you are above €8 million.
Receiving and paying: the larger half
This is where custom systems get hurt, because it reaches into purchasing, approvals and treasury rather than one invoice template.
- Receive structured invoices, from a platform or from the public solution, where a recipient can retrieve them at any time, directly or through automated access.
- Report to the supplier. Article 10 requires the customer to tell the issuer whether it accepted or rejected the invoice and when, and when it paid it in full, "en un plazo máximo de cuatro días naturales, excluyendo sábados, domingos y festivos nacionales". When the invoice travels through the public solution, article 12 alone governs.
- Report to AEAT. Article 12 requires the customer to report to the public solution the full effective payment of each invoice received and not rejected, with its date, "en un plazo máximo de 4 días naturales desde dicha fecha efectiva del pago, excluyendo sábados, domingos y festivos nacionales", and the payment due date. Rejections are reported too; if nothing is reported, the invoice is presumed accepted. This applies whichever route the invoice took.
- The format. Under articles 7 and 8 of the order these are UBL ApplicationResponse messages (PAYMENT and REJECTION, each with a cancellation), sent by web service using the invoice's unique code, or one at a time through a web form. Your platform can report for you if you authorise it. If the public solution is down for more than 24 hours on AEAT's side, you get four working days after the fix.
- The right payment date. The decree's preamble defines it as the day the supplier is actually paid: the cash payment, the debit to the payer's account for a transfer, or the agreed set-off. "La mera puesta a disposición del proveedor de un mecanismo financiero para adelantar el cobro de la factura no computará". With confirming, the day the bank offers your supplier an advance is not the date you report.
- One exception. When the invoice itself carries a payment date on or before its issue date, matching the date of the operation, the payment report counts as made.
For a legacy accounts payable module this means new data: a link from each bank debit back to the unique codes of the invoices it settled, a paid-in-full flag, a stored due date, and a queue that sends the messages and retries them inside the window. One transfer that settles thirty invoices becomes thirty payment messages.
The data has a use beyond tax. Every first quarter, AEAT sends the Observatorio Estatal de la Morosidad Privada the information for its list of companies that broke the payment terms of Ley 3/2004 the year before. The dates your system reports are the evidence.
Where VERI*FACTU fits
They are separate regimes. VERI*FACTU, under Real Decreto 1007/2023, sets anti-fraud requirements for invoicing software: a hashed record per invoice and a QR code. B2B e-invoicing sets the format invoices travel in between businesses, and the reporting of their payment. In the Ministry of Economy's words, "se trata de dos medidas diferentes". The decree links them once: a mandatory e-invoice must come from systems adapted to article 29.2.j of the General Tax Law, the provision VERI*FACTU develops.
For a company above €8 million in the common tax territory, SII settles it: VERI*FACTU does not apply, and October 2027 does. For a smaller company, both projects now point at the same month. On 5 October 2026 the Ministry of Finance announced that the pending VERI*FACTU obligations will move "hasta octubre de 2028", to coincide with e-invoicing for businesses up to €8 million. As of 16 October 2026 no norm making that change has appeared in the BOE, so the 2027 VERI*FACTU dates still bind. Our VERI*FACTU guide covers that side.
A Plan to 6 October 2027
From mid-October 2026, a company in the first wave has just under twelve months. That is enough for a custom system if the work starts this quarter.
- October to November 2026: inventory. Every system that issues invoices to Spanish businesses, and every system that receives, approves and pays supplier invoices. Confirm your wave with your adviser.
- November 2026 to January 2027: choose the route. A private platform, a direct connection to the public solution, or both. Ask a platform which syntaxes it accepts, whether it sends the UBL copy and the payment reports for you, how status messages come back, and whether it has a test environment.
- December 2026 to March 2027: data. NIF validation, structured addresses, payment terms as data, stored VAT breakdowns, the Spanish extensions, the mapping to EN 16931.
- January to May 2027: accounts payable. Inbound processing, rejections, payment dates from bank movements, the reporting queue.
- As soon as AEAT opens the public solution, and by August 2027: test end to end. The order leaves the technical specifications to what AEAT publishes on its Sede electrónica, so keep the mapping in one module and expect revisions.
- September 2027: go live early with a few customers and suppliers, PDF alongside.
- 6 October 2027: mandatory. Someone owns the reporting queue from the first day.
For the October 2028 wave the same steps apply a year later. Your larger suppliers will start issuing e-invoices to you in October 2027, with the PDF that the decree's preamble says guarantees legibility for everyone else. Use that year to learn to receive them.
What Could Still Move
- The schedule has slipped before. In March 2026 the Ministry of Economy expected the order "antes del 1 de julio de 2026". It came in October. Now the dates come from the decree itself, and moving them would take a new norm.
- The EU condition. Ley 18/2022 made its article 12 conditional on an EU exception to articles 218 and 232 of the VAT Directive. Directive (EU) 2025/516, part of the ViDA package, amended both articles from its entry into force to let member states require domestic e-invoices without the recipient's acceptance, and the decree's preamble cites it. Whether that meets the condition is a question for lawyers; the government has gone ahead, and we plan to its dates.
- The specifications. The public solution's syntax can be changed by joint order of the two ministries, and more syntaxes can be admitted.
- Sector exclusions. The Ministry of Economy can exclude operations by order, as a rule temporarily.
- Penalties. Neither the decree nor the order sets fines of its own. The fine of up to €10,000 in article 2 bis.9 of Ley 56/2007 is for failing to offer e-invoices to consumers, not for B2B invoicing. What a B2B failure would cost is a question for your tax adviser.
Where to Get Help
We build the parts of this that land in your own code: the EN 16931 mapping and UBL output, the copy to the public solution, master data changes, inbound processing into accounts payable, payment-date capture and the reporting queue with its retries. Our e-invoicing integration service describes how that work runs. If the mandate arrives in the middle of a system replacement, see ERP modernization, and when nobody left knows how the old program works, legacy system maintenance is where it starts.
If your invoices or supplier payments run on a system nobody sells a connector for, write to office@c9group.dev. We are engineers, not lawyers or tax advisers: scope and liability questions belong with yours, and we build to their answer.
Tax & Finance Systems
New guides and rule changes by email
When a rule changes, a deadline moves or we publish a new guide, we send it by email.