AEAT's Two New SPFE Documents: Spain's Public E-Invoicing Solution Explained

The two AEAT SPFE documents on Spain e-invoicing are the clearest map yet of how the country's public invoicing rail will work. Published on 1 June 2026, they explain the business rules and the technical build behind the Solución Pública de Facturación Electrónica. Read together, they answer what it does and how you connect.

Key takeaways

• The SPFE is the AEAT-run public platform that sits beside private platforms in a hybrid model. You can use one, the other, or both.
• Two documents landed on 1 June 2026: a functional explainer and a technical brief.
• Large firms with turnover above €8 million hit the first deadline for e-invoicing and payment status reporting from 1 October 2027. Everyone else follows from 1 October 2028. 
• The Spain public e-invoicing solution SPFE runs on UBL 2.5, aligned to EN 16931:2026.
• Thin pass-through platforms are finished. You must aggregate, retrieve and validate.

What Are the Two AEAT SPFE Documents?

The first is the Ministerial Order Project for the SPFE. It is the plain-language, legal explainer: who must join, how the invoice lifecycle works, and how the public solution talks to private platforms.

The second is the technical document. It covers syntax, validation engines, access channels and the test environment.

The legal chain behind them runs Crea y Crece (Ley 18/2022), then Royal Decree 238/2026, then the draft order opened for consultation on 17 April 2026. One caveat worth holding onto: the SPFE Ministerial Order Spain text is still a draft. Details can move before they land in the BOE.

How Does the SPFE Work?

Spain has built a mixed model on purpose. The SPFE itself plays four roles: universal repository for faithful copies, interconnection hub between parties, free billing app for small businesses, and engine for payment status reporting.

AEAT is blunt about what it is not. Not an ERP module. Not a backup for your private platform. Not free cloud storage. It is a regulated public utility, nothing more. The technical document specifies that the obligation applies to B2B transactions where the recipient has their registered office (sede de actividad económica), permanent establishment, domicile, or habitual residence in Spain. Furthermore, it mentions that invoices and certified copies may not include embedded or integrated files. It means teams cannot attach a PDF, supporting document, or any file inside the UBL XML.

Even when an invoice travels over a private platform, a faithful copy (copia fiel) must reach the SPFE at the same moment, flagged with the CopyIndicator field.

SPFE Compliance Timeline

Every date below counts from the order's entry into force, set at 1 October 2026 in the draft.

Issuance comes first by size. Payment-status reporting follows. The smallest taxpayers get the longest runway.

What Invoice Format Does the SPFE Require?

UBL, and only UBL. The wider Spanish system tolerates CII as well at the EN 16931 layer, but the public solution narrows to one syntax for simplicity.

Specifically, the Spain SPFE UBL 2.5 EN 16931 binding. EN 16931-1:2026 was rebuilt to handle B2B complexity and ViDA-era reporting, and the 2.5 binding natively supports Spanish quirks like corrective invoices, retenciones and recargo de equivalencia without bolt-on extensions. Anything still outside the European core sits in UBL extension points, documented in Annex I.

How Does SPFE Invoice Validation Work?

Two layers, and you should know both.

Step 1: Syntactic. OASIS publishes XSD schemas for each UBL component. Structurally broken documents get rejected on intake.

Step 2: Semantic. EN 16931 business rules run through Schematron, updated to the 2026 version.

Here is the part teams miss. AEAT will not publish a live online validator, but it will publish Schematron files, XSD schemas, and sample invoices at agenciatributaria.es/AEAT.desarrolladores/ before the test environment launches. 

Build validation in-house using those materials. You validate inside your own stack before you transmit, or you find out the hard way after rejection. Do not plan to lean on a checker that will not exist.

How Are Invoice Statuses Managed in the SPFE?

The recipient carries most of the load. The SPFE functional document defines four formal statuses:

• Recipient side: PAID / REJECTED
• Issuer side: COLLECTED / UNCOLLECTED

 Finance teams building AP/AR workflows need to know these status names and add them. The recipient must report whether they reject the invoice, the actual payment date, and the due date. Silence counts as acceptance, so doing nothing is a decision.

The SPFE technical document confirms the issuer may optionally report the effective collection of the invoice, non-payment of the invoice and recipient-reported date discrepancies, all relevant to AR teams. On the other hand, the recipient also optionally can report dates of goods receipt, rendering of services and invoice receipt.

Each invoice carries a unique code (NIF, plus series-number, plus issue date), which makes deduplication automatic. The system blocks a second submission of the same code outright. To correct anything, you de-register the original first since there is no overwrite allowed. So, whether it is an original or a certified invoice copy, de-register that document first before resubmitting.

When the SPFE accepts a submission of any invoice, a certified copy, or a payment status communication, it returns an acknowledgement containing a Secure Verification Code (CSV).

How Do Businesses Connect to the SPFE?

Two channels. A web form for small structures issuing one invoice at a time, and automated web services for volume.

All access needs an electronic certificate. The cl@ve system is available for the web forms. Representation has a deliberate catch: to send invoices, you can act in your own name, but to retrieve received invoices, you need registered apoderamiento. A platform cannot pull a client's invoices without an explicit power of representation. 

There is also a third access category allowed by the AEAT SPFE documents Spain e-invoicing. It is social collaborators who are accountants, tax advisors, and similar professionals. They can submit invoices and copies on behalf of clients, but cannot retrieve received invoices or statuses without registered apoderamiento.

The sandbox will arrive with enough lead time to test, but not before the order is published in the BOE, expected around 1 October 2026. The SPFE functional document states that to access the test environment, finance teams need-

• An electronic certificate (same as production)
• Sufficient representation capacity registered for the entity being tested
• Invoices must use real NIFs or NIFs specifically designated for testing

What Businesses and Platforms Must Do Next for Spain e-Invoicing

Step 1: Confirm where you sit on the timeline. Above €8 million means 2027, and that is closer than it reads.

Step 2: Map your AR and AP flows against the new status layer. Payment dates and due dates are now tax data, not private commercial chatter.

Step 3: If you run a platform, kill any pass-through behaviour now. Aggregation, apoderamiento and automatic retrieval with immediate delivery are non-negotiable under Spain mandatory B2B e-invoicing AEAT rules. Private platforms must not operate with SPFE on an invoice-by-invoice or client-by-client basis. They must aggregate for submission, and SPFE will aggregate what it returns to them.

Step 4: Build validation at your edge and prepare UBL 2.5 output. Do not wait for the developer portal docs to start.

Conclusion

The two documents do not change Spain's direction, but they remove most of the guesswork about the SPFE. The firms that treat 2027 as a build deadline now, not a 2027 problem, are the ones who will not be scrambling later.