The text the Spanish market has been waiting for since 2024 is now law. Ministerial Order HAC/1028/2026, which regulates the technical and functional rules of the SPFE (Solución Pública de Facturación Electrónica, Public Electronic Invoicing Solution), was published in the Official State Gazette on 5 October 2026 and entered into force the following day.
That single date matters more than the Order’s content, because the Royal Decree that created the B2B mandate tied every deadline to it. With the Order in force, the countdown has formally begun, and it now runs on a fixed calendar rather than an expected one.
Key Dates
| Date | Milestone |
| 6 October 2026 | Order in force; all compliance periods begin |
| By early August 2027 | Public platform must be available, at least two months before first application |
| 6 October 2027 | Mandatory for businesses above €8 million turnover; platform operator obligations begin |
| 6 October 2028 | Mandatory for all remaining businesses and professionals |
| 6 October 2029 | Status reporting becomes mandatory for natural persons with turnover up to €8 million |
Three Obligations in One System
Spain does not follow a model seen elsewhere in Europe. It is not a clearance regime in which a state platform approves every invoice, and it is not a simple reporting regime either. It combines three obligations that apply together:
- Exchange: every domestic B2B invoice must be a structured e-invoice based on EN 16931.
- Status reporting: the buyer must report whether it rejected or paid each invoice. This is the core policy aim of the mandate, which was introduced to tackle late payment rather than VAT fraud.
- Central repository: the Spanish Tax Agency must hold a copy of every B2B invoice issued in the country.
The SPFE sits at the centre of all three. It operates as an exchange hub, a universal repository and the point where statuses are reported, and it is free of charge for users.
Two Ways to Operate
Businesses may exchange invoices through the SPFE, through private platforms, or through a combination of both. In practice, this produces two operating routes.
Through the Public Platform
The issuer’s platform submits the invoice to the SPFE in UBL, and the buyer’s platform retrieves it from there. Incoming invoices follow the same path in reverse. Because the tax authority already holds the invoice, no separate copy is required, and a single connection reaches every business and every platform in Spain.
Two operational features stand out. The SPFE does not push anything: private platforms are obliged to retrieve invoices exchanged through it, automating that access and making invoices available to their clients immediately. The SPFE also validates syntax, semantics and specifications before accepting a submission, and returns a response listing accepted items and rejected items with the reason for each rejection. A rejected invoice never reaches the buyer, so validation has to happen on the sender’s side before submission.
Through a Private Network
The issuer’s platform delivers the invoice directly to the buyer’s platform in an agreed format (UBL, CII, EDIFACT or Facturae, the Spanish national XML invoice format) and, at the same moment, sends a copia fiel (faithful copy) of the invoice in UBL to the SPFE, marked through a dedicated copy indicator field.
This route carries heavier obligations. Platforms must agree on formats and status messages with each counterparty, convert between all accepted formats while preserving the invoice’s integrity, sign invoices with an advanced electronic signature, and accept any interconnection request from another Spanish platform within one month and free of charge. Statuses also travel twice: from the buyer to the seller through the private connection, and from the buyer to the SPFE.
Peppol messages are accepted as an invoice format where they use UBL and comply with EN 16931. However, neither the Royal Decree nor the Order designates Peppol as the network for these mandatory interconnections, so its practical role in Spain remains unsettled.
Invoice Statuses
The status messages are defined in the Order’s second annex and expressed in UBL. The table below shows how each status travels on the two routes.
| Status | Sent by | Via the public platform | Via a private network | Required |
| Acceptance | Buyer | Not sent; acceptance is presumed | To the seller | Yes, on the private route |
| Rejection (REJECTION) | Buyer | To the SPFE | To the seller and the SPFE | Yes, if rejected |
| Payment (PAYMENT) | Buyer | To the SPFE | To the seller and the SPFE | Yes |
| Partial payment, partial acceptance, transfer of the invoice | Buyer | Not available | To the seller only | Optional |
| Cancellation of a buyer status (CANCELPAYMENT, CANCELREJECTION) | Buyer | To the SPFE | To the SPFE | Only to correct an error |
| Collection (SETTLEMENT) | Seller | To the SPFE | To the SPFE | Optional |
| Non-payment (DEFAULT) | Seller | To the SPFE | To the SPFE | Optional |
| Cancellation of a seller status (CANCELSETTLEMENT, CANCELDEFAULT) | Seller | To the SPFE | To the SPFE | Only to correct an error |
| Invoice withdrawal (CANCELINVOICE) | Seller | Withdraws the invoice | Withdraws the copy | Only if the transaction never took place |
Buyer statuses must be reported within four days, excluding weekends and national holidays. A payment report must carry both the date of full effective payment and the payment due date, and a collection report from the seller may flag that the seller received early payment through a financing arrangement. In the absence of a rejection or a later corrective invoice, the invoice is presumed accepted.
What the Final Text Settles
Compared with the draft released for consultation in April, the published Order resolves several practical questions:
- A floating start date. The draft fixed entry into force on 1 October 2026. The final text ties it to the day after publication, which moved every compliance date to 6 October.
- A rejected copy does not invalidate the invoice. If a faithful copy fails validation, the original invoice already delivered through a private platform remains valid. The sender must correct the cause and resubmit. Where the error lies in the original invoice itself, a corrected original must be issued and a new copy sent at the same time.
- Invoices paid at issuance. The buyer’s payment reporting obligation is treated as fulfilled where the invoice, or its copy, already shows a payment date on or before the issue date that coincides with the transaction date, unless the buyer reports payment expressly.
- Withdrawal is narrowed. An invoice or copy may be withdrawn only where the transaction never took place, with full traceability preserved.
- Outages are defined. If the SPFE is unavailable for more than 24 hours for reasons attributable to the platform, invoices, copies and statuses may be submitted within four working days after the incident is resolved.
- Third-party issuance. Where the buyer or a third party issues the invoice on the supplier’s behalf, the faithful copy must be sent by that party’s platform.
- Consultation and download. Issuers and recipients may query and download invoices, copies and statuses through web services or the web form.
Acting on Behalf of Clients
A service provider that operates for its clients towards the SPFE needs more than a technical connection. To retrieve incoming invoices, consult statuses or use the web forms on a client’s behalf, the provider must be registered as the client’s representative in the Registro de apoderamientos (Power of Attorney Register) of the Spanish Tax Agency. Without that registration, a provider could submit invoices but could not collect them or read their statuses.
The register identifies representatives by Spanish tax identification number, so foreign providers will need one before they can act for Spanish clients. In practice, the client grants the authorisation through the Tax Agency’s Sede electrónica (electronic office) using its own digital certificate, and the provider then accepts it. Access to the platform otherwise relies on qualified electronic certificates, with Cl@ve (the Spanish government’s electronic identification system) also available for the web forms.
What Remains Open
The Order settles the legal framework, but several operational pieces are still to come. The Tax Agency has not yet published the full technical specifications, volume limits and test environment, all of which the Order leaves to the electronic office. The authorisation codes clients will select when granting representation for SPFE services, and the list of accepted certificates, are also pending. The signature requirement for invoices routed through the SPFE is not fully settled: the Order permits interconnected invoices to carry an electronic signature without explicitly requiring one.
There is also a longer-term question. Every new e-invoice must carry, where applicable, the fiscal QR code of VERI*FACTU (Spain’s verifiable invoicing software regime) or TicketBAI (the Basque Country’s equivalent regime), which formally links the B2B mandate to the invoicing software regime. As VERIFACTU comes into application, the market is increasingly discussing whether SII (Spain’s immediate VAT reporting system), VERIFACTU and B2B e-invoicing might be brought closer together. Nothing has been announced, but such a move would reshape the system considerably.
