AS4 — Applicability Statement 4

The SOAP successor to AS2, profiled by OASIS over ebMS 3.0. Adopted in 2020 as the sole transport of the PEPPOL eDelivery network and the European Commission's eDelivery Building Block.

What is AS4?

AS4 is a profile of the OASIS ebXML Messaging Services 3.0 (ebMS3) specification. The ebMS3 Core spec is dense — multi-hop routing, WS-ReliableMessaging, security, fragmentation, full P-Mode policies — and its industrial uptake was hampered by that complexity. AS4 applies the just-enough design principle: pick a coherent subset that covers 95% of real cases, and pin implementation choices (algorithms, MEPs, receipt scheme) so that one vendor's AS4 talks to another's out of the box.

OASIS highlights three contributions of AS4 over ebMS3 Core: (1) better alignment with contemporary WS-* standards, (2) the introduction of pull in addition to push, which opens messaging to clients without a fixed IP (SMBs, mobile access points), and (3) a built-in receipt mechanism that produces a cryptographic proof of non-repudiation (signed receipt).

Why AS4 over AS2?

AS2 and AS4 solve the same problem — moving a signed and encrypted EDI payload between two partners over the internet — with different architectural choices:

AS4 is therefore the right choice when (a) you join the PEPPOL or European eDelivery network, (b) you need pull transport to serve clients without a fixed IP, or (c) you want declarative service descriptions (P-Mode) rather than swapping manual specs with each partner.

Three conformance profiles

AS4 §3 defines three conformance levels corresponding to three industrial roles:

• AS4 ebHandler — full gateway. Bidirectional (send and receive), supports push and pull transport, full security, full P-Mode parameters. This is the profile implemented by PEPPOL Access Points and eDelivery gateways.
• AS4 Light Client — client-only, no inbound HTTP server required. Pushes outbound, pulls inbound from an ebHandler's queue. Ideal for branch offices or clients without a fixed IP.
• AS4 Minimal Client — reduced feature set for low-end constraints. One-Way/Push only, no native receipt or signing support. Shortest implementation path but rarely used in regulated flows.

Anatomy of an AS4 message

An AS4 message is an HTTP POST whose body is a multipart/related typed application/soap+xml. The first part is the SOAP 1.2 envelope carrying:

• An eb:Messaging block in the Header, which carries either a UserMessage or a SignalMessage depending on whether the message is a payload or a receipt.
• An eb:UserMessage describing the context: parties (From, To with iso6523-typed PartyId), business service and action (CollaborationInfo), and the attachment list via PayloadInfo.
• A wsse:Security header carrying the XMLDSig signature and optional XMLEnc encryption.

Subsequent parts of the multipart/related carry the business payloads, referenced by their Content-ID from the PayloadInfo. The SOAP body itself is typically empty — payloads aren't inlined.

POST /msh HTTP/1.1
Host: ap.partner.example
Content-Type: multipart/related; boundary="MIMEBoundary_as4";
  type="application/soap+xml"; start="<soap@ediverse.io>"
SOAPAction: ""

--MIMEBoundary_as4
Content-Type: application/soap+xml; charset=UTF-8
Content-ID: <soap@ediverse.io>

<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
              xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">
  <s12:Header>
    <eb:Messaging s12:mustUnderstand="true">
      <eb:UserMessage>
        <eb:MessageInfo>
          <eb:Timestamp>2026-05-14T09:30:00Z</eb:Timestamp>
          <eb:MessageId>uuid:6b6f9a2c-2a4a-4b6f-a89e-0a4a2e9f1c14@ediverse.io</eb:MessageId>
        </eb:MessageInfo>
        <eb:PartyInfo>
          <eb:From>
            <eb:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088">
              5790000435975
            </eb:PartyId>
            <eb:Role>http://docs.peppol.eu/edn/as4/role/sender</eb:Role>
          </eb:From>
          <eb:To>
            <eb:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:0088">
              5790000123456
            </eb:PartyId>
            <eb:Role>http://docs.peppol.eu/edn/as4/role/receiver</eb:Role>
          </eb:To>
        </eb:PartyInfo>
        <eb:CollaborationInfo>
          <eb:Service type="cenbii-procid-ubl">
            urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
          </eb:Service>
          <eb:Action>
            urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice
          </eb:Action>
          <eb:ConversationId>uuid:e6b7…</eb:ConversationId>
        </eb:CollaborationInfo>
        <eb:PayloadInfo>
          <eb:PartInfo href="cid:invoice@ediverse.io"/>
        </eb:PayloadInfo>
      </eb:UserMessage>
    </eb:Messaging>
    <!-- WSS 1.1: Signature and Timestamp omitted for readability -->
  </s12:Header>
  <s12:Body/>
</s12:Envelope>

--MIMEBoundary_as4
Content-Type: application/xml
Content-ID: <invoice@ediverse.io>
Content-Transfer-Encoding: binary

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  ...
</Invoice>
--MIMEBoundary_as4--

Push / pull sequence and NRR receipt

The One-Way/Push MEP is the default: the sender opens an HTTPS connection to the receiver's MSH URL and pushes the UserMessage. The receiver returns a SignalMessage with a Receipt on the same connection (synchronous response) or via a separate HTTPS callback (asynchronous).

The One-Way/Pull MEP inverts the initiative: the client opens a connection to its ebHandler, sends a SignalMessage of type PullRequest referencing an MPC (Message Partition Channel) that identifies the queue, and receives a UserMessage in response. This is essential for lightweight PEPPOL Access Points or SMBs whose infrastructure cannot expose an HTTP server.

The AS4 receipt is substantially richer than the AS2 MDN. It includes a NonRepudiationInformation block that echoes the ds:Reference elements of the original message's XMLDSig signature, with the DigestValue as received. That digest echo is the cryptographic proof of receipt: if the digests match those the sender computed on the way out, NRR is proven.

<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
              xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">
  <s12:Header>
    <eb:Messaging s12:mustUnderstand="true">
      <eb:SignalMessage>
        <eb:MessageInfo>
          <eb:Timestamp>2026-05-14T09:30:02Z</eb:Timestamp>
          <eb:MessageId>uuid:receipt-9a1e…@ap.partner.example</eb:MessageId>
          <eb:RefToMessageId>uuid:6b6f9a2c-…@ediverse.io</eb:RefToMessageId>
        </eb:MessageInfo>
        <eb:Receipt>
          <ebbp:NonRepudiationInformation
              xmlns:ebbp="http://docs.oasis-open.org/ebxml-bp/ebbp-signals-2.0">
            <ebbp:MessagePartNRInformation>
              <ds:Reference URI="cid:invoice@ediverse.io"
                  xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>F4r0…Base64…SkE=</ds:DigestValue>
              </ds:Reference>
            </ebbp:MessagePartNRInformation>
          </ebbp:NonRepudiationInformation>
        </eb:Receipt>
      </eb:SignalMessage>
    </eb:Messaging>
  </s12:Header>
  <s12:Body/>
</s12:Envelope>

Security — WS-Security and P-Mode

AS4 mandates WS-Security 1.1 for message-level security:

• XMLDSig signature over the Messaging header and each part referenced by PayloadInfo, with default algorithms http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 for signing and http://www.w3.org/2001/10/xml-exc-c14n# for canonicalisation.
• XMLEnc encryption on sensitive parts, with http://www.w3.org/2009/xmlenc11#aes128-gcm or aes256-gcm, and a session key wrapped with RSA-OAEP.
• X.509 token in wsse:BinarySecurityToken carrying the sender certificate, referenced by the signature.
• TLS recommended in addition, for transport confidentiality and mutual authentication of access points.

The P-Mode (Processing Mode) is the keystone of AS4 interoperability. It's a set of declarative parameters (Service, Action, required security, receipt scheme, compression) that an ebHandler binds to each exchange type. Two AS4 gateways sharing the same P-Mode ID are interoperable by construction — no out-of-band negotiation required. In PEPPOL, the P-Mode is mandated by the OpenPEPPOL Authority and identified by a public AgreementRef.

AS4 in PEPPOL and eDelivery

AS4's most visible adoption is its designation as the sole transport of the PEPPOL eDelivery network. Since 1 February 2020, all Access Points (the gateways connecting an organisation to the network) must implement AS4 per the PEPPOL AS4 Specification, which hardens options left open by OASIS (mandatory algorithms, push-only MEP between Access Points, certificates issued by the PEPPOL Authority).

AS4 is also the transport for the European Commission's eDelivery Building Block in Connecting Europe Facility (CEF). That building block is reused in regulated verticals: e-CODEX for cross-border justice, the eHealth Digital Service Infrastructure for healthcare, ENTSO-G/E for gas and electricity grid operators.

Consequence: every European EDI vendor that wants to support clients through the 2026-2028 e-invoicing mandates (France September 2026, Belgium January 2026, Germany 2025, Spain 2026-2027) must have AS4 in its stack. It is today the fastest-growing portfolio item across AS2-historical vendors.

Operational pitfalls

• P-Mode mismatch. Two gateways that believe they're interoperable can diverge on a single detail (signature algorithm, compression enabled, async receipt scheme) and every message fails. Always validate via OpenPEPPOL TIA tests before production.
• Digest reference broken by re-canonicalisation. An intermediate component that re-serialises SOAP (formatting, UTF-8 re-encode) breaks the DigestValue in the ds:Reference. AS4 must receive the XML byte-for-byte as sent — same rule as AS2 S/MIME.
• Pull with misconfigured MPC. A pull client registered on an empty MPC will waste calls. Monitor MPC depth on the ebHandler side.
• AS4 certificate distinct from TLS certificate. The two planes are independent: a WSS certificate for message signing, a TLS certificate for the HTTPS session. Mixing them is a common cause of PEPPOL enrolment incidents.

Official sources

• OASIS — AS4 Profile of ebMS 3.0 v1.0 (23 January 2013) — the canonical specification.
• OASIS — ebXML Messaging Services 3.0 Core (Part 1) — the technical base AS4 profiles.
• PEPPOL AS4 Specification — the PEPPOL profile that hardens AS4 for the eDelivery network.
• CEF Digital Building Block — eDelivery — the EU infrastructure reusing AS4.

Further reading

• AS2 — detailed anatomy for a side-by-side comparison.
• PEPPOL — BIS Billing 3.0 and UBL for the payload AS4 carries across the European network.
• The five EDI transport families compared for the decision context.
• OFTP2 for contrast with the European automotive ecosystem.