Peppol AS4 Explained: The Transport Layer Behind Europe's E-Invoicing Mandates

Peppol AS4 is the secure transport layer that enables electronic invoices and other business documents to move between organizations through the Peppol network. While Peppol BIS Billing 3.0 defines the structure and business rules of an e-invoice, AS4 handles secure, reliable delivery between Peppol Access Points.

Using the Four-Corner Model, a sender’s Access Point discovers the recipient’s Access Point through SML and SMP services, packages the business document using the Peppol Business Message Envelope, and transmits it using AS4. Message-level encryption, digital signatures, and reliable messaging help protect the document throughout the exchange.

For enterprises, understanding the difference between BIS Billing 3.0, AS4, SML/SMP, SBDH, and the Peppol Access Point is essential when preparing for European e-invoicing requirements or evaluating Peppol-compatible software.

What Is Peppol AS4?

E-invoicing has transitioned from a localized business efficiency tool into a highly regulated global compliance standard. Governments across Europe and around the world are implementing mandatory electronic reporting frameworks to bridge tax gaps, eliminate administrative inefficiencies, and combat VAT fraud. The Pan-European Public Procurement Online (Peppol) framework is one of the primary drivers of this evolution. Governed by OpenPeppol, this network establishes common business processes and technical specifications to ensure that public and private entities can exchange electronic documents seamlessly across borders.

Historically, business-to-business (B2B) document transmission relied heavily on point-to-point connections, secure email attachments, or legacy value-added networks. These older paradigms suffered from high integration costs, rigid configurations, and limited scalability. To overcome these issues, OpenPeppol implemented a standardized transport infrastructure. In February 2019, OpenPeppol passed a resolution that made the Applicability Statement 4 (AS4) profile mandatory for all certified Access Points in its e-Delivery network, with full enforcement beginning on February 1, 2020. This mandate forced all legacy Peppol connections to transition from the older AS2 standard to the more secure and flexible AS4 protocol.

The mandate to run the Peppol network on AS4 is not accidental. AS4 is an open, web-services-based messaging standard developed by OASIS and built on the Electronic Business Messaging Service (ebMS) 3.0 specification. It combines the robust reliability of traditional electronic data interchange (EDI) with the accessibility and flexibility of modern web services.

Why Peppol Uses AS4 for E-Invoicing

Several key structural advantages make AS4 the ideal transport protocol for nationwide e-invoicing initiatives:

Message-Level Security

AS4 implements WS-Security 1.1 standards. Unlike transport-layer security (TLS), which only protects data during transmission through an active tunnel, message-level security encrypts and signs the payload itself. This ensures the document remains secure even when stored on intermediary servers or routed through multi-hop networks.

Asynchronous Message Exchange

AS4 natively supports asynchronous communication. The sender and receiver do not need to be online at the exact same moment; messages can be securely queued and delivered when the receiving system becomes available.

Payload Agnosticism

The protocol is entirely payload-agnostic. It acts as a secure, neutral envelope that can transport any data format, including XML, JSON, binary files, or traditional EDIFACT structures.

Dynamic and Scale-Friendly Routing

AS4 supports dynamic sender and receiver configurations. Rather than requiring manual, point-to-point setup for every trading partner, AS4 utilizes decentralized directory and lookup registries to route messages dynamically.

How the Peppol Four-Corner Model Works

The Peppol network operates on a decentralized architectural topology known as the Four-Corner Model. This model decouples the end-users (the sender and receiver) from the underlying technical routing and transport protocols. It enables any business to exchange structured documents with any other partner on the network without establishing direct point-to-point integrations.

The Roles of the Four Corners

Corner 1 (The Sender / Buyer)

The business or public administration that originates the document. The sender generates the business transaction within their internal Enterprise Resource Planning (ERP) or accounting system.

Corner 2 (The Sending Access Point)

The certified service provider that manages the technical connection for the sender. Corner 2 validates the incoming business message, wraps it in the mandatory cryptographic and transport envelopes, and transmits it via AS4 to Corner 3.

Corner 3 (The Receiving Access Point)

The certified service provider representing the recipient. Corner 3 receives the encrypted AS4 message, validates the signature and integrity, decrypts the payload, and makes it available to the recipient.

Corner 4 (The Receiver / Seller)

The final business or public agency that imports the parsed, validated structured document directly into their back-end financial software.

In specific regulatory environments, such as those implementing real-time invoice reporting to tax authorities, this architecture is extended into a “Five-Corner Model”. In this framework, the sender’s Access Point automatically routes the validated e-invoice directly to the national tax portal for real-time clearance alongside standard delivery to the recipient.

How Peppol Dynamic Discovery Works

The core technical achievement of the Peppol network is its ability to route documents dynamically without pre-configured, partner-specific endpoints. When Corner 2 receives an invoice from Corner 1, it must dynamically discover where Corner 3 is located, what document types Corner 4 supports, and which encryption keys to use. This is achieved using a two-tier lookup chain involving the Service Metadata Locator (SML) and the Service Metadata Publisher (SMP).

The lookup process consists of the following algorithmic steps:

1. Identifier Input

Corner 2 extracts the recipient’s unique Participant Identifier (PPID) from the invoice header.

2. Hashing and Domain Generation

To query the decentralized Domain Name System (DNS) securely, the sending Access Point normalizes the identifier value to lowercase, computes its SHA-256 hash, encodes the hash using base32, and strips any trailing padding characters.

3. DNS Lookup (U-NAPTR)

The AP constructs a fully qualified domain name (FQDN) by appending the identifier schema (iso6523-actorid-upis) and the target SML zone.

E.g.:

B-<hash>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu

A standard DNS lookup on this returns the hostname of the SMP that the receiver’s Access Point provider operates on.

4. SMP Metadata Retrieval

Corner 2 queries the discovered SMP URL. The SMP responds with the recipient’s technical metadata. This metadata includes the receiving Access Point’s physical HTTPS endpoint URL, the supported document formats (such as BIS Billing 3.0), and the public X.509 certificate required for encrypting/signing the payload.

5. Validate Trust

Corner 2 checks that the SMP’s response is signed by a certificate chaining up to the PEPPOL Root CA, and that the receiver AP’s certificate is also PEPPOL-issued and not revoked.

What Is the Peppol Business Message Envelope (SBDH)?

Before transmitting the payload over the AS4 channel, the sending Access Point must wrap the actual business document (e.g., the UBL XML invoice) inside a Standard Business Document Header (SBDH) envelope. Defined by UN/CEFACT, the SBDH serves as a standardized cover sheet that remains cryptographically bound to the business payload throughout its journey.

The primary structural purpose of the SBDH is to prevent the loss of critical sender, receiver, and document metadata when a file is routed through multi-hop environments or processed by internal intermediate legacy systems.

Below is a structural example of a Peppol-compliant SBDH XML envelope wrapping a business payload:

<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
    <StandardBusinessDocumentHeader>
        <HeaderVersion>1.0</HeaderVersion>
        <!-- Corner 1 Sender Information -->
        <Sender>
            <Identifier Authority="iso6523-actorid-upis">9915:sender_org_id</Identifier>
        </Sender>
        <!-- Corner 4 Receiver Information -->
        <Receiver>
            <Identifier Authority="iso6523-actorid-upis">9915:receiver_org_id</Identifier>
        </Receiver>
        <!-- Document Formatting & Type Scope Metadata -->
        <DocumentIdentification>
            <Standard>urn:oasis:names:specification:ubl:schema:xsd:Invoice-2</Standard>
            <TypeVersion>2.1</TypeVersion>
            <InstanceIdentifier>uuid:9a8b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d</InstanceIdentifier>
            <Type>Invoice</Type>
            <MultipleType>false</MultipleType>
            <CreationDateAndTime>2026-03-31T09:30:00Z</CreationDateAndTime>
        </DocumentIdentification>
        <BusinessScope>
            <!-- Process Identifier (e.g., Peppol BIS Profile) -->
            <Scope>
                <Type>PROCESSID</Type>
                <InstanceIdentifier>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</InstanceIdentifier>
            </Scope>
            <!-- Document Type Identifier -->
            <Scope>
                <Type>DOCUMENTID</Type>
                <InstanceIdentifier>urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1</InstanceIdentifier>
            </Scope>
        </BusinessScope>
    </StandardBusinessDocumentHeader>
    <!-- The Semantic Invoice Payload Starts Here -->
    <Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
        <!-- UBL XML Invoice fields go here -->
    </Invoice>
</StandardBusinessDocument>

Corner 2 (sender’s access point) now builds an AS4 message with the above XML attached as the payload. This message is signed and encrypted using the certificates involved and POSTed directly to the receiver AP’s (corner 3) AS4 endpoint.

The receiver’s AP validates the signature, decrypts the payload, and returns a Non-Repudiation of Receipt (NRR) - an AS4-level signed receipt confirming successful, tamper-evident delivery. The sender’s AP now has proof the message arrived intact.

AS4 vs AS2: What Changes?

Many enterprise IT teams already run and maintain Applicability Statement 2 (AS2) infrastructures to facilitate secure B2B data exchanges. Standardized in 2002, AS2 has been the backbone of electronic data interchange for decades, particularly in the retail, logistics, and healthcare sectors. However, AS2 was designed for a simpler, point-to-point internet ecosystem.

AS4 represents a major advancement in transport technology. It incorporates modern web services technologies (SOAP, XML, and WS-Security) to address the operational and scaling limitations of AS2.

The following table contrasts the architectural, security, and operational paradigms of the two protocols:

Peppol BIS Billing 3.0 vs AS4

A common point of confusion for business teams and system administrators during compliance evaluations is the distinction between the format of an electronic document and the transport protocol used to deliver it. E-invoicing vendors and compliance blogs frequently focus on standards like EN 16931 or Peppol BIS Billing 3.0, leading many to believe that upgrading to BIS Billing 3.0 is the only requirement for compliance.

In reality, an electronic invoice requires both a structured semantic format (the language) and a secure transport layer (the vehicle) to reach its destination safely.

The Semantic Layer: BIS Billing 3.0

The Peppol Business Interoperability Specification (BIS) Billing 3.0 is a semantic data standard. It is compliant with the European standard EN 16931, which defines the mandatory data structures and business rules for electronic invoicing across Europe.

BIS Billing 3.0 dictates exactly what information must be written inside the invoice XML document. It governs the syntax, data types, mandatory fields (such as VAT numbers, payment terms, and line-item descriptions), and applies validation rules via Schematron to ensure logical business compliance.

However, BIS Billing 3.0 has no inherent capability to transmit itself across the internet. It does not handle encryption, does not know how to bypass firewalls, and cannot verify whether the receiving party actually received the file.

The Transport Layer: AS4

AS4 is the underlying technical transport protocol - the secure “armored courier” responsible for moving the document from Point A to Point B. AS4 does not read, parse, or validate the financial content of the invoice. It is entirely payload-agnostic.

The technical responsibility of AS4 is to compress the file to save bandwidth, sign the packet with the sender’s private cryptographic key to verify identity, encrypt the package with the receiver’s public key to ensure absolute confidentiality, and execute the delivery handshake.

To illustrate how these technologies co-exist, the following breakdown contrasts their core functions within a compliant transaction:

Do You Need Your Own Peppol Access Point?

To exchange documents over the Peppol network, an enterprise must route its transactions through a certified AS4 Access Point. This requirement presents IT leadership with a strategic business decision: “Build and certify an in-house Peppol Access Point, or Buy access by partnering with an established certified provider”.

Scenario A: Setting Up and Certifying Your Own Access Point

For most organizations, attempting to build, certify, and host a proprietary Access Point is a major software engineering and administrative undertaking. It is typically pursued only by large government agencies, massive multinational enterprises with millions of transactions, or specialized EDI/VAN operators.

The process to become a certified Peppol Access Point provider is complex. It requires navigating the following operational and technical milestones:

1. Legal Onboarding: The organization must become an active member of OpenPeppol, pay annual membership fees, and sign a formal Service Provider Agreement (SPA) or Transport Infrastructure Agreement (TIA) with the relevant National Peppol Authority.
2. Due Diligence and Auditing: The applicant must undergo extensive business due diligence. This process includes submitting financial statements, liability insurance policies, leadership background checks, and criminal conviction checks for directors.
3. Security Certifications: In many jurisdictions, the national Peppol Authority mandates that Access Points obtain and maintain official security certifications, such as ISO/IEC 27001.
4. Acceptance Testing: IT teams must configure the technical infrastructure to meet Peppol specifications. They must undergo formal unit and acceptance testing within the central OpenPeppol Testbed.
5. PKI Lifecycle Management: Upon successful completion of testing, the organization requests its Production Public Key Infrastructure (PKI) certificates from OpenPeppol. These certificates must be managed, secured, and renewed annually without fail.
6. SLA Maintenance: Certified Access Points are legally obligated to maintain a 99.5% system availability SLA. They must continuously update their systems to align with evolving specifications, such as the 2026 SML domain changes and upcoming BIS 4.0 updates.

Scenario B: Partnering with a Certified Access Point Provider

For the vast majority of businesses, partnering with an established, certified Access Point provider or utilizing a fully managed infrastructure service is the most logical choice. Under this model, the technical and regulatory complexities are abstracted away.

The provider manages the AS4 transport stack, handles certificate lifecycles, maintains high-availability hosting infrastructure, and ensures compliance with global e-invoicing standards. The enterprise simply connects its internal ERP or billing software to the Access Point’s modern REST APIs, reducing integration time from months to days.

Where Aayu AS4 Server Fits

As electronic invoicing mandates expand across Europe and global markets, establishing a secure and compliant transport layer is a critical priority for enterprise IT teams. At Aayu Technologies, we are actively building and expanding our managed file transfer platform to bring dedicated, enterprise-grade AS4 capabilities alongside our established AS2 and EDI integration solutions.

If your organization is planning its transition to Peppol AS4 or needs guidance on meeting upcoming e-invoicing transport mandates, we are here to help. Reach out to us today with your project details, target go-live dates, and system specifications so we can evaluate your requirements and help you build a seamless roadmap to compliance.