The Spanish tax agency has just put two new documents on the table, and together they tell the rest of the e-invoicing industry exactly how the country’s public rail will work. Following Royal Decree 238/2026 (BOE, 31 March 2026) and the draft Ministerial Order opened to public consultation on 17 April 2026, the AEAT has now released a pair of explanatory publications covering the Solución Pública de Facturación Electrónica (SPFE) from two angles: how it works in business terms, and how it works in technical terms.
For organizations building Spain into their compliance roadmaps, these two documents are the most concrete view we have had so far of what the public solution will actually do, how it will validate invoices, what it will demand from private platforms, and when the obligations bite.
Context: RD 238/2026 and the Draft Ministerial Order
The legal backbone of the mandate is already in place. The “Crea y Crece” Law (Ley 18/2022) created the B2B e-invoicing obligation but tied its effective application to the future technical regulation. RD 238/2026 developed the system at the regulatory level, set the rules on scope (Article 3), system composition (Article 5), interoperability (Article 7.1), the unique invoice code (Article 7.5), and assigned the public solution to the AEAT (Article 11.1). The Royal Decree then delegated the technical and operational detail to a Ministerial Order under its third final provision.
That Order is the draft text published on 17 April 2026 for public consultation. It is not yet final. But it is now the document that defines what the SPFE will be, and the two new AEAT publications are its plain-language and technical companions.
What AEAT Just Published
The two documents are structured to address two different audiences without overlapping.
The first, titled the Ministerial Order Project for the Public Electronic Invoicing Solution, is the functional and legal explainer. It covers the business rules of the SPFE: who must use it, how the invoice lifecycle works, how the public solution interacts with private platforms, and how the payment status reporting layer is structured.
The second, the Public Electronic Invoicing Solution (SPFE) document, is the IT and infrastructure brief. It focuses on the syntax (UBL), the validation engines (XSD and Schematron), the access channels (web services and forms), the authentication and representation rules, and the testing environment.
Read together, they give a complete picture: the first answers “what does the SPFE do,” and the second answers “how do I connect to it.”
Document One: The Ministerial Order Project for the SPFE
Implementation Timeline
The most quoted part of the document is the calendar, because it confirms the staggered rollout that the industry has been planning against. All dates are tied to the Order’s entry into force, currently set at 1 October 2026 in the draft text:
- 1 October 2027: e-invoicing becomes mandatory for businesses with turnover above 8 million euros (12 months after the Order takes effect).
- 1 October 2028: e-invoicing becomes mandatory for everyone else, including smaller businesses and independent professionals (24 months after).
- 1 October 2029: self-employed individuals with turnover below 8 million euros begin reporting mandatory invoice statuses, after the specific relief period that the document confirms.
The structural logic is consistent: issuance obligations come first by size, payment-status reporting follows on a later track, and the smallest taxpayers get the longest runway.
Governance and the SPFE’s Role
The document is explicit that Spain has built a mixed model. Companies can use either a private platform or the SPFE for transmitting and receiving e-invoices, or a combination of both. The SPFE itself plays four distinct roles: universal repository of faithful copies, interconnection hub between parties and platforms, free billing application for small businesses, and engine for the payment status lifecycle.
The AEAT pushes back hard on misreadings of what the SPFE is for. It is not an ERP module, not a backup for a private platform, and not free cloud storage for invoices. It is a regulated public utility with defined entry points and a defined purpose.
Invoice Lifecycle and Status Management
The invoice lifecycle is split between mandatory and optional statuses, and between the issuer and the recipient.
The recipient must report whether it rejects the invoice (silence counts as acceptance), the actual full payment date, and the payment due date. Optionally, where the late-payment law (Ley 3/2004, Article 4) makes it relevant, the recipient may also report goods receipt date, service performance date, and invoice receipt date.
The issuer’s reporting is optional but operationally useful: actual collection, non-payment, and discrepancies relative to what the recipient reported.
Two design points sit underneath this. First, each invoice carries a codigo unico under Article 7.5 of RD 238/2026, built from the issuer’s NIF plus invoice series-number plus issue date, which makes deduplication and traceability automatic. Second, when an invoice travels over a private platform rather than the SPFE, a faithful copy (copia fiel) must be deposited in the SPFE simultaneously with issuance, flagged with the CopyIndicator field. Strict rejection rules apply: the system blocks duplicate submissions for the same unique code, and any correction requires de-registering (dar de baja) the existing entry first.
Transmission and Access Methods
The document defines two channels into the SPFE: a web form aimed at small structures issuing one invoice at a time, and automated flows for larger volumes. Issuance through the form will be individual and verifiable. Bulk traffic moves through web services.
It also introduces a centralized business directory (Directorio de empresas), which is what will ensure invoices reach the right recipient inside the system, regardless of whether the recipient is on a private platform or accessing the SPFE directly.
Interoperability Within the Hybrid Model
This is the section that matters most for platform operators. The document sets out how the SPFE will exchange both e-invoices and their statuses with private platforms, and it imposes operating rules that read like an explicit anti-pattern list.
Private platforms must aggregate traffic in both directions. They must not operate invoice-by-invoice or client-by-client against the SPFE. They must be enabled (apoderadas) by each business they represent. And when invoices are exchanged through the SPFE, the platform is obliged to retrieve them automatically and make them immediately available to its client. A platform behaving as a thin pass-through is, by design, non-compliant.
Document Two: The Technical Aspects of the SPFE
UBL Only, Aligned to EN 16931:2026
The first design choice the technical document drives home is that the SPFE works exclusively in UBL (Universal Business Language, ISO/IEC 19845). The wider Spanish system tolerates both UBL and UN/CEFACT CII at the EN 16931 semantic layer, but the public solution narrows to UBL for operational simplicity.
The document also confirms the alignment with the revised EN 16931-1:2026, which was rebuilt to support B2B complexity and ViDA-era reporting. Crucially, the SPFE will use the UBL 2.5 syntax binding of the updated standard, which is the version that natively supports the Spanish-specific requirements (corrective invoices under Article 15 of RD 1619/2012, retenciones, suplidos, minoraciones, recargo de equivalencia, advanced large-enterprise regime) without bolt-on extensions. The UBL 2.5 binding itself is being finalized at CEN level for official publication.
Where Spanish requirements still need to be carried outside the European core model, the SPFE uses UBL’s extension points, with every customization documented in Annex I of the Order.
Two Layer Validation (XSD and Schematron)
Validation in the SPFE happens at two distinct levels, and the document explains both.
The first is syntactic. OASIS publishes XSD schemas for each UBL component (Invoice, ApplicationResponse, and so on), so any sender knows the exact structural shape the SPFE expects. Structurally malformed documents are rejected on intake.
The second is semantic. EN 16931 business rules (for example, that the amount due equals invoice total with VAT minus paid amount plus rounding) are enforced through Schematron, a declarative validation model published in public repositories and updated to the 2026 version of the standard.
Two operational notes are worth flagging. Because Schematron does not scale natively to the volumes the AEAT will process (billions of invoices per year), the agency will run its own high-performance validation engine derived from the Schematron rules. And because senders are expected to validate locally before transmitting, the AEAT will not publish a public online validation service in production. Validation tooling has to live inside the sender’s stack.
Web Services, Authentication, and Representation
The SPFE exposes a set of synchronous web services for invoice submission, status updates, and retrieval, with WSDLs to be published on the AEAT developer portal. All access requires authentication with an electronic certificate; the cl@ve identification system is additionally available for the web forms where applicable.
Representation rules introduce a deliberate asymmetry. For sending invoices, copies, and status changes, the user can act in their own name, through apoderamiento, or as a social collaborator. For consulting or retrieving received invoices and statuses, only apoderamiento is valid, whether the access is manual or automated. A platform or social collaborator cannot pull a client’s invoices without an explicit power of representation registered in the AEAT.
The Testing Environment
A sandbox environment (entorno de pruebas) will be available for developers to test and validate their integration before go-live. The document is careful about timing: the environment will be made available with sufficient lead time, but not before the Ministerial Order is published in the BOE, currently expected on 1 October 2026.
Access to the test environment requires certificate authentication and a sufficient power of representation over the entity being acted for. Test invoices must use real NIFs or those specifically issued for testing purposes.
What’s Coming Next: The Developer Portal Documentation
Both documents point to a broader set of materials that will land on the AEAT’s Software Developers Portal (Portal de Entidades Desarrolladoras) before the SPFE is deployed. The expected list includes:
- Service catalogue for companies and platforms
- Submission standards
- Authentication and representation guidelines
- Applicable limitations
- Error list
- WSDLs for accessing the services
- XSD schemas for custom extensions and references to OASIS UBL
- Schematron validation documents
- Illustrative message examples (e-invoice, faithful copy, payment confirmation, rejection, cancellation)
For integration teams, this developer documentation is, in practice, the most important deliverable on the AEAT side, because it is the only source against which production-grade implementations can be built.
What This Means for Platforms and Finance Teams
The two new documents do not change the direction of Spain’s mandate, but they remove most of the remaining ambiguity. Three takeaways carry the operational weight.
First, the technical baseline is now firm: UBL 2.5 on top of EN 16931-1:2026, two-layer validation done at the sender’s edge, synchronous web services with certificate-based authentication. There is no clearance API to outsource to a third party here, and no online validator to lean on. Validation logic has to be embedded.
Second, the platform operating model is being explicitly engineered against thin-relay behaviors. Aggregation, mandated apoderamiento, and automated retrieval with immediate downstream delivery are non-negotiable expectations of any platform exchanging invoices through the SPFE. SaaS providers planning to plug Spain into an existing multi-country stack should map these requirements against current onboarding and AR/AP flows now, not in 2027.
Third, the payment status layer is the most underestimated change. Acceptance becomes the default when the recipient is silent, payment and due dates become reportable tax data, and the policy intent (controlling private-sector late payment, morosidad) tells you how seriously enforcement will be approached. AR and AP processes that were designed around private commercial communication need a tax-reporting overlay.
The path from here is now narrow and visible: final publication of the Order in the BOE, the developer portal documentation drop, sandbox availability around 1 October 2026, then the rolling obligations through 2027 to 2029.
