Spanish einvoicing mandate with their own AS4 profile

[phax]

More information https://www.agenciatributaria.es/AEAT.desarrolladores/Desarrolladores/_menu_/Reuniones/Ejercicio_2026/Seminario_SPFE/Seminario_SPFE.html and around.

Project base URL: https://www.agenciatributaria.es/AEAT.desarrolladores/Desarrolladores/Desarrolladores.html

Yeah.

[phax]

Updated 2026-09-10 after the AEAT webinar "Actualización sobre la SPFE" of the same day, including the XML message examples shown on the slides. The section on the SPFE transport has changed materially: the SPFE web services use genuine ebMS 3.0 over SOAP 1.2 — the same header model AS4 builds on — which the May seminar did not disclose. Webinar content comes from the live slides, is draft, and is unverified against any published text; values transcribed from screenshots may contain reading errors.

What the Spanish mandate actually says about AS4

I went through the primary sources (BOE text, draft Ministerial Order, all four documents of the AEAT developer seminar of 2026-05-19) plus notes from the 2026-09-10 webinar. Summary up front: there is no Spanish AS4 profile. There is a single normative sentence about AS4, and nothing else.

Real Decreto 238/2026, Art. 13.1 (requirements to operate as a private e-invoice exchange platform):

b) Utilizar protocolos seguros para la transmisión de la información que cumplan con las especificaciones AS2 o AS4.

That is the complete AS4 rule. No version, no conformance profile, no PMode, no MEP, no reliability/receipt rules, no WS-Security algorithms, no transport certificate policy, no addressing or discovery, no payload conventions, no conformance test.

The word "AS4" appears in none of the AEAT seminar material of 2026-05-19 (verified by full-text search over all four files). In the 2026-09-10 webinar it appears exactly once — as a single bullet justifying AEAT's envelope choice for the SPFE's own services, see below. That bullet is also the only occurrence of "Peppol" in that deck.

The SPFE speaks ebMS 3.0 over SOAP 1.2

This corrects what the May seminar suggested (it mentioned only "servicios web" and WSDLs). AEAT devoted a slide ("¿Por qué ebXML?") to the rationale: an OASIS standard like UBL so integrators implement nothing SPFE-exclusive and AEAT avoids "defining a basic envelope of its own"; "Compatible AS4 / Peppol" — a minimalist version without cryptographic signature, improving interoperability in the ViDA context; one envelope for everything; a header carrying parameters at message and invoice level; mutually independent invoices; size control.

The slides show real message examples, and they are ebMS 3.0 rather than a loose interpretation:

<soap:Envelope
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
    xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">
  <soap:Header>
    <eb:Messaging>
      <eb:UserMessage>
        <eb:MessageInfo>
          <eb:Timestamp>2026-09-09T09:00:00.000Z</eb:Timestamp>
          <eb:MessageId>uuid-invoices-123</eb:MessageId>
        </eb:MessageInfo>
        <eb:PartyInfo>
          <eb:From>                              <!-- NIF of the sender's certificate -->
            <eb:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:9920"
              >99999910G</eb:PartyId>
            <eb:Role>ebms:initiator</eb:Role>
          </eb:From>
          <eb:To>                                <!-- NIF of the AEAT (SPFE) -->
            <eb:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:9920"
              >Q2826000H</eb:PartyId>
            <eb:Role>ebms:responder</eb:Role>
          </eb:To>
        </eb:PartyInfo>
        <eb:CollaborationInfo>
          <eb:Service>urn:cen.eu:en16931:cancelinvoice</eb:Service>
          <eb:Action>CANCELINVOICE</eb:Action>
          <eb:ConversationId>c73b7fdc-1ab0-4b1e-b295-ac9e4a35d764</eb:ConversationId>
        </eb:CollaborationInfo>
        <eb:PayloadInfo>
          <eb:PartInfo href="cid:anulacion.xml">
            <eb:PartProperties>
              <eb:Property name="MimeType">application/xml</eb:Property>
            </eb:PartProperties>
          </eb:PartInfo>
        </eb:PayloadInfo>
      </eb:UserMessage>
    </eb:Messaging>
  </soap:Header>
  <soap:Body/>                                   <!-- "Sin contenido" -->
</soap:Envelope>

Confirmed from the examples:

• SOAP 1.2 plus the ebMS 3.0 core namespace http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/ — the exact header model phase4 already implements.
• eBCore party identifiers: urn:oasis:names:tc:ebcore:partyid-type:iso6523:9920 (ICD 9920, Spanish VAT). The sender's PartyId is the NIF in its certificate; the SPFE's is AEAT's own NIF Q2826000H. This answers open question 5 below for the SPFE leg.
• Roles ebms:initiator / ebms:responder.
• Empty SOAP Body — every payload is a MIME part referenced by PartInfo/@href="cid:…" with a MimeType part property, exactly as AS4 does it.
• The response reuses the same UserMessage shape with RefToMessageId pointing at the request's MessageId.
• No WS-Security header at all, consistent with the "minimalist version without cryptographic signature".

Service/Action values use a CEN namespace, not a Spanish one:

Operation	Service	Action
Submit invoices	urn:cen.eu:en16931:invoice	SUBMITINVOICE
Cancel invoice	urn:cen.eu:en16931:cancelinvoice	CANCELINVOICE
Query by filter	urn:cen.eu:en16931:queryinvoices	QUERYBYFILTER
Status events	urn:cen.eu:en16931:submitstatus	AccountingCustomerParty / AccountingSupplierParty

For the status service the Action says whether the batch carries issuer- or recipient-side statuses; the slide annotates that envelope "ebXML no relevante" because the substance sits in the ApplicationResponse payload. Query-by-filter parameters ride in eb:MessageProperties: Role, InvoiceCompanyID, InvoiceRegistrationName, RegistrationStartDate, RegistrationEndDate.

Services and message shapes:

Operation	Endpoint	Request	Response
Submit invoices	ws/SendInvoiceSOAP	ebXML (SUBMITINVOICE) + N parts (Invoice)	ebXML + 1 part (DocumentStatus)
Cancel invoice	ws/CancelInvoiceSOAP	ebXML (CANCELINVOICE) + 1 part (ApplicationResponse)	ebXML + 1 part (DocumentStatus)
Download invoices	—	ebXML + 1 part (ApplicationResponse with N DocumentReference, ID only)	ebXML + N parts (Invoice)
Query invoices	—	ebXML only (by filter) or + 1 part (ApplicationResponse, by ID)	ebXML + 1 part (DocumentStatus with N AdditionalDocumentResponse)
Recipient status events	ws/CustomerInvoiceEventsSOAP	ebXML + 1 part (ApplicationResponse)	ebXML + 1 part (DocumentStatus)
Issuer status events	ws/SupplierInvoiceEventsSOAP	ebXML + 1 part (ApplicationResponse)	ebXML + 1 part (DocumentStatus)

Limits: 1–100 invoices per batch (configurable); 5,120 KB max per invoice, applied per invoice (configurable); zero binary attachments — cbc:EmbeddedDocumentBinaryObject and cbc:EmbeddedDocument must be empty, while URL references via cac:Attachment/cac:ExternalReference/cbc:URI are allowed; download capped at 100; query capped at 1,000; up to 100 status events per ApplicationResponse, issuer and recipient actions neither mixed nor duplicated for the same invoice. Private platforms must act as a concentrador and must not operate invoice-by-invoice or customer-by-customer.

Where this diverges from AS4

The envelope is ebMS 3.0, but the exchange is not the AS4 profile:

1. Synchronous request/response carrying business payloads. Download returns N Invoice payloads in the HTTP response of the same exchange; every other service returns a DocumentStatus. The OASIS AS4 profile is One-Way/Push with signal messages (Receipt/Error) as the response; a synchronous Two-Way exchange whose reply is a business UserMessage is an ebMS 3.0 Part 2 feature outside the AS4 profile. phase4's client is built around One-Way/Push plus Pull.
2. No message-level signature and no WS-Security header. AS4's default security policy signs the SOAP header and payloads; without it there is no message-level non-repudiation, and the signed-Receipt mechanism cannot apply.
3. No AS4 Receipt. Acknowledgement is business-level — a DocumentStatus payload plus an "acuse de recibo" carrying a Código Seguro de Verificación (CSV).
4. Partial-success semantics. DocumentStatus reports per-invoice outcomes across the batch, with no equivalent in AS4's per-message all-or-nothing model. The response-code slide lists "200 all actions correct", "200 actions partially correct" and "400 all actions failed" — 200 appears twice, so the middle value is probably 206 and needs confirming.
5. Authentication is transport/business level — qualified electronic certificate plus the AEAT representation model (nombre propio / apoderamiento / colaborador social), not WS-Security tokens. From/PartyId is expected to match the NIF in that certificate.
6. Roles do not swap in the response. The reply has From = AEAT carrying ebms:initiator and To = the original sender carrying ebms:responder, i.e. the role stays bound to header position rather than to the party's role in the exchange. Looks like a slide error, but if intentional a strict ebMS implementation must tolerate it.
7. ConversationId is inconsistent across examples — a UUID in the cancel and query messages, empty in the submit response.

Net effect: phase4 cannot talk to the SPFE out of the box, but this is far closer than the May material suggested. phase4's ebMS 3.0 marshalling, PartyInfo / CollaborationInfo / PayloadInfo handling and MIME multipart payload model all apply directly; what is missing is a synchronous Two-Way exchange and a "no security" profile.

Why the platform-to-platform leg is a problem rather than a profile

Arts. 8 and 9 set up a bilateral N×N mesh, not a four-corner network:

• Art. 8.1 — must interconnect with any other platform when one of your own customers asks; must cover all users of both platforms.
• Art. 9.1 — every incoming interconnection request must be accepted.
• Art. 9.3 — max. one month to make it operational, and you must hand over "all the necessary technical specifications", provide a test bed, and staff it.
• Art. 9.4 — parallel requests served strictly first-come.
• Art. 9.6 — free of charge for the requesting platform.
• Art. 9.5 — until the interconnection is live, the sender deposits invoices in the SPFE and the counterparty is obliged to fetch them there.
• Art. 8.2 — the SPFE may also be used permanently as the interconnection medium.
• Art. 7.4 — between two private platforms, syntax and technical specifications are whatever sender and receiver agree; the SPFE specs apply only in the absence of an agreement.

Since no national AS4 usage profile exists and Art. 7.4 delegates the technical specifications to bilateral agreement, each platform pair can define its own PMode, security policy and payload conventions. The realistic outcome is one PMode per counterparty, not one Spanish profile.

There is also no accreditation, no registry and no directory of private platforms in the RD (verified by full-text search) — no SMP/SML equivalent. Art. 2.e lists "direccionamiento" (addressing) as a required capability of a platform, but the mechanism to discover a counterparty's endpoint and certificate is simply not regulated.

Payload issues that land on the AS4 layer

• Four admitted syntaxes (Art. 7.1): CII, UBL, EDIFACT invoice message, Facturae. Every platform must exchange all of them and convert between them while preserving authenticity of origin and integrity (Art. 7.2). EDIFACT is not XML — an AS4 payload profile cannot assume XML.
• Peppol BIS is explicitly accepted between private platforms (RD preamble), because it uses UBL and conforms to EN 16931. That is a statement about syntax, not about Peppol transport.
• Mandatory payload signature (Art. 7.3): every invoice issued through a private platform must carry an advanced electronic signature, by the issuer or by authorised delegated signature. That is a signature inside the payload (XAdES for UBL/CII, Facturae's own, something else for EDIFACT), independent of the AS4/WS-Security message signature — both are needed. Asymmetry worth noting: per the AEAT FAQ, invoices sent through the SPFE need no signature; there integrity/non-repudiation come from AEAT's own procedures (Art. 11.7).
• Status messages ride the same interconnection (Art. 8.3): at minimum invoices plus the Art. 10.1 statuses. On the SPFE these are UBL ApplicationResponse / DocumentStatus, with reported codes PAYMENT / CANCELPAYMENT / REJECTION / CANCELREJECTION (recipient) and SETTLEMENT / CANCELSETTLEMENT / DEFAULT / CANCELDEFAULT (issuer). Over a bilateral AS4 link, nothing defines a Service/Action to tell an invoice from a status message.
• Unique invoice code (Art. 7.5): issuer NIF + invoice series/number + issue date. A natural business-level message identifier, with no defined mapping to ebMS message properties. The SPFE additionally issues an encrypted localizador for high-performance retrieval, recommended over the plain ID.
• Other platform requirements: ISO/IEC 27001 or equivalent (Art. 13.1.a), eIDAS advanced signature and seal capability (Art. 13.1.c), data governance optionally via UNE 0080 maturity level 2 (Art. 13.2).
• Syntax baseline on the SPFE: UBL 2.5, validated XSD → Schematron (EN 16931) → AEAT business rules, referencing UNE-EN 16931-1:2026 and UNE-CEN/TS 16931-3-2:2026.

Open questions for an AS4 implementer

Platform-to-platform leg (the AS2/AS4 obligation)

1. Which AS4 baseline — OASIS AS4 Profile of ebMS 3.0 v1.0 (ebHandler / Light Client), eDelivery AS4, or Peppol AS4? "AS2 or AS4" reads like a generic reference to EDI transport, not a conformance profile.
2. MEP: One-Way/Push only, or is Pull needed for platforms without a public endpoint?
3. Are signed AS4 Receipts with NRI mandatory, and are they the legal proof of delivery between platforms? Retry and duplicate-detection windows?
4. Which certificates and trust anchors at the transport layer? The RD only regulates certificates for invoice signing and for SPFE access. Trust list, or purely bilateral trust?
5. ebMS PartyId construction — NIF based? The SPFE leg answers this for itself (eBCore …:iso6523:9920, above); would platforms reuse the same scheme bilaterally?
6. Which Service/Action values separate invoice, credit note, status message and error? Would platforms reuse the SPFE's urn:cen.eu:en16931:* naming bilaterally?
7. Payload profile: single vs. multiple payloads, compression, and how the syntax (UBL / CII / EDIFACT / Facturae) is signalled.
8. Conformance testing: Art. 9.3 makes every platform run its own test bed for its counterparties. There is no national conformance test comparable to CEF eDelivery or the Peppol test bed.

SPFE leg (the ebXML envelope)

9. What exactly is "compatible with AS4/Peppol"? Answered by the slide examples. What remains open is whether AEAT would also accept genuinely AS4-conformant messages (signed, with Receipts) from clients that send them.
10. Is the exchange a declared ebMS Two-Way/Sync MEP, and are there any ebMS signal messages (Receipt, Error) at all? Every response shown is a business UserMessage, so apparently not — transport-level error handling is undocumented.
11. Are the response Role values intentional or a slide error, and is ConversationId mandatory?
12. What are the exact DocumentStatus response codes — is the second "200" actually 206?
13. Is message-level signing genuinely absent, or only absent in the first release? If later added, which policy?
14. How is the 24-hour-outage rule (submission allowed within the following four business days) expected to interact with client-side retry behaviour?
15. Will AEAT publish the ebXML envelope as a documented profile, or only as WSDLs plus examples?

Timeline (as of 2026-09-10)

Date	Event
2026-03-31	RD 238/2026 published (BOE no. 79)
2026-04-20	RD 238/2026 in force (DF cuarta.1)
2026-04-17	Draft Ministerial Order opened for public consultation
2026-05-19	AEAT developer seminar on the SPFE
2026-09-10	AEAT webinar "Actualización sobre la SPFE"
2026-10-01	Planned entry into force of the Ministerial Order — starts all deadlines; also the reference date for the SPFE test environment
2027-10-01	E-invoicing + payment reporting mandatory, turnover > EUR 8 m (RD: +12 months; also the date private-platform obligations under Arts. 6, 8, 9 and 13 take effect)
2028-10-01	E-invoicing for the rest (RD: +24 months); payment reporting for incorporated SMEs
2029-10-01	Payment reporting for the remaining small taxpayers

The 2027–2029 dates come from the webinar slides; the +12/+24 month structure is the RD's own (DF cuarta). The draft Order is not final, so everything downstream of it can still move.

Suggested position for phase4

• Nothing has to be implemented today for the platform-to-platform leg: Art. 13.1.b) is satisfied by any conformant AS4 implementation, and phase4 is one.
• The SPFE leg is now the more interesting one. Its envelope is genuine ebMS 3.0 over SOAP 1.2 with eBCore party identifiers and CID-referenced MIME payloads — the model phase4 already implements. The divergences above (synchronous business responses, no WS-Security at all, no Receipts, partial-success batches) are what stand in the way. Worth a concrete feasibility check of how far the phase4 ebMS layer reaches once AEAT publishes the WSDLs and message examples, because the answer looks like "most of the way".
• The plausible convergence path for the platform-to-platform leg remains Peppol — the RD already blesses Peppol BIS as a syntax, and Peppol supplies the missing pieces (AS4 profile, SMP/SML discovery, identifier schemes, conformance testing). If the Spanish market converges there, phase4-profile-peppol / phase4-peppol-client cover it with no new code.
• A phase4-profile-spain module only becomes meaningful once a Spanish AS4 usage profile actually exists. As of 2026-09-10 there is none.
• Useful interim deliverable: documentation on running phase4 with per-counterparty PModes, which is what Art. 7.4 + Art. 9 effectively force.

Sources

• Real Decreto 238/2026 — https://www.boe.es/boe/dias/2026/03/31/pdfs/BOE-A-2026-7295.pdf
• Draft Ministerial Order (SPFE) — https://www.hacienda.gob.es/sgt/normativadoctrina/proyectos/16042026-proyecto-pom-factura-electronica.pdf
• AEAT seminar 2026-05-19 — https://www.agenciatributaria.es/AEAT.desarrolladores/Desarrolladores/_menu_/Reuniones/Ejercicio_2026/Seminario_SPFE/Seminario_SPFE.html
• AEAT webinar 2026-09-10 — https://www.agenciatributaria.es/AEAT.desarrolladores/Desarrolladores/_menu_/Reuniones/Ejercicio_2026/Actualizacion_sobre_la_Solucion_Publica_de_Facturacion_Electronica__SPFE_/Actualizacion_sobre_la_Solucion_Publica_de_Facturacion_Electronica__SPFE_.html (slides not published there yet)
• To be published before the test deployment, per AEAT: service catalogue for companies and platforms, submission standards, authentication and representation, limits, error list, WSDLs, XSDs of the Spanish extensions, Schematron files, message examples.
• Technical questions to AEAT: facturaelectronica@correo.aeat.es

Documents plus extracted plain text are stored in docs/spain/, with the detailed analysis in docs/spain/AS4-relevance.md.