Inside Spain's SPFE: UBL 2.5, Sender-Side Validation and the Hybrid Model Explained

What AEAT published, and why it matters

On 1 June 2026, the Spanish tax agency (AEAT) published two decks from its developer seminar of 19 May 2026 on its developer portal. The first is a functional overview of the draft Ministerial Order that regulates the public e-invoicing platform, the Solución Pública de Facturación Electrónica (SPFE). The second covers the technical aspects of the SPFE: syntax, standards, validation and connectivity.

Until now, anyone building for the Spanish mandate was working from the legal framework: Royal Decree 238/2026, in force since 20 April 2026, and the draft Ministerial Order that went through public consultation in April and May. Those texts establish who must invoice electronically and when. The seminar documents answer the questions that actually block an integration project: which syntax, which version of the European standard, where validation happens, how you authenticate, and what a private platform is expected to do.

This post walks through the architecture those documents describe. For the regulatory background, see our Spain e-invoicing guide; for the news story of the Royal Decree itself, see our March article.

The hybrid model: private platforms plus one public repository

Spain is not building a clearance system where the tax agency approves every invoice before it can be issued. Nor is it a pure post-audit model. The Spanish system is mixed: businesses exchange invoices through interconnected private platforms, through the SPFE, or both, and the SPFE additionally acts as the universal repository.

The functional document assigns the SPFE four roles: a free issuing and receiving solution for businesses and professionals, a universal repository of faithful copies, an interconnection function between platforms, and the register of invoice payment statuses.

The repository role is the one with the biggest integration consequence. When an invoice is issued and exchanged outside the SPFE, a faithful copy (copia fiel) must be deposited in the SPFE simultaneously with issuance. The copy is marked with the UBL CopyIndicator field set to true; originals carry false. Every invoice also embeds a unique code built by concatenating the issuer NIF, the invoice series and number, and the issue date. No two invoices may share that code, and the SPFE rejection rules automatically refuse a second original or a second faithful copy of the same invoice.

Why UBL 2.5 on EN 16931:2026

The SPFE will work exclusively with UBL syntax (ISO/IEC 19845), and invoices may not incorporate embedded files. That is a narrower choice than the European standard allows, since EN 16931 has historically supported two syntax bindings, UBL and UN/CEFACT CII. The technical deck is unambiguous on this point.

The version question matters just as much as the syntax. The 2019 version of EN 16931 cannot express several cases Spanish invoicing rules require: the requirements for rectifying invoices under Article 15 of the invoicing regulation, withholdings, amounts paid on behalf of a client (suplidos), reductions (minoraciones), the equivalence surcharge, and the special regime for large companies. The March 2026 revision of EN 16931-1, with its syntax binding based on UBL 2.5, supports these national cases, which is why AEAT anchored the SPFE to it. Custom fields are documented in Annex I of the Ministerial Order, using UBL extension points without breaking the European semantics.

Two-layer validation lives at the sender

Validation is split into two layers. XSD schemas, published by OASIS for each UBL component including Invoice and ApplicationResponse, verify the structure. Schematron, the declarative rule language available in public repositories and due to be updated to the EN 16931 2026 version, verifies the business rules.

The operational decision that shapes every integration: both layers must run at the sender. AEAT will implement its own high-performance validation internally, because Schematron interpretation does not scale to the volumes the agency expects, in the order of thousands of millions of invoices a year. But it will not publish a production validation service. Senders are expected to validate with the XSD and the Schematron before submitting, minimising rejections in the same way the agency already expects for other systems.

Invoice statuses: silence means acceptance

The SPFE tracks what happens to an invoice after it is delivered, and the obligations are asymmetric between the two parties. The recipient must report a rejection where applicable, the date of full effective payment, and the payment due date. If the recipient reports nothing, the invoice is presumed accepted in the SPFE. The recipient may additionally report the date goods were received, services were provided, or the invoice itself was received.

The issuer's side is optional: it may report that the invoice was collected, that it went unpaid, or differences against the dates the recipient communicated. Status communications travel as UBL ApplicationResponse and DocumentStatus messages, through the web form (invoice by invoice) or web services, and admitted communications return an acknowledgement with a secure verification code, just like invoice submissions.

The functional document is explicit about why this layer exists: the objective is monitoring payment periods as the basis for controlling late payment in the private sector. Spain's late-payment problem was the political driver of the Crea y Crece Law from the start.

Certificates, apoderamiento and what platforms must do

Connectivity is through synchronous web services, authenticated with an electronic certificate. The web forms additionally accept the cl@ve system where applicable. For sending, a business can act in its own name, through an attorney-in-fact registered in AEAT's power of attorney registry (apoderamiento), or through a social collaborator. Retrieval is stricter: consulting or downloading invoices and statuses requires a registered apoderamiento, whether the access is direct or automated. A social collaborator or platform without one cannot pull a client's invoices.

For private platforms, the technical deck sets out an operating model, not just an interface. Platforms handling many clients must aggregate information for submission to the SPFE rather than operating invoice by invoice or client by client, and the SPFE will group what it returns to them the same way. Platforms that exchange invoices through the SPFE are obliged to retrieve the exchanged invoices, the retrieval must be automated, and it must make the invoices immediately available to their clients. Each client has to enable its platform to retrieve invoices and statuses on its behalf.

Taken together, these rules close off the thin pass-through model where a platform simply forwards whatever its client gives it and never looks back. A compliant platform aggregates, holds registered representation per client, and operates a retrieval loop.

The reference calendar

The functional document closes with the calendar. The Ministerial Order enters into force on 1 October 2026, and the staged obligations of Royal Decree 238/2026 count from there. The dates below remain subject to the final Order being published in the BOE, but they are AEAT's own reference, not a vendor's estimate.

Before anything goes live, AEAT will publish the developer material on its developer portal: service catalogues for businesses and platforms, submission standards, authentication and representation rules, applicable limits, error lists, WSDLs, XSD schemas for the Spanish extensions, Schematron validation documents, and worked examples of each message. An integration test environment opens once the Order is published in the BOE, accessible with certificate authentication and sufficient representation, using real NIFs or ones designed for testing.

What implementation teams should do now

October 2027 is a comfortable deadline for teams that start in October 2026 and a tight one for teams that start in mid-2027. The technical picture is now defined enough to sequence the work.

First, establish UBL 2.5 readiness. Check whether your ERP, middleware or e-invoicing provider can produce and consume the EN 16931:2026 model on UBL 2.5, including the Spanish cases (withholdings, suplidos, equivalence surcharge) that forced the version choice in the first place. Second, plan for embedded validation: the XSD and Schematron layers belong in your outbound pipeline, not in a manual pre-check, because there is no production validator to fall back on. Third, design the apoderamiento onboarding early. If a platform retrieves invoices for hundreds of clients, each of those clients needs a registered power of attorney, and that is an administrative process with its own lead time, not a configuration flag.

Finally, watch the developer portal. The WSDLs, schemas, Schematron files and message examples land there before the test environment opens, and the test environment itself is gated on the Order's BOE publication, expected on 1 October 2026.