The PEPPOL network explained simply

PEPPOL is not an invoice format. It is a cross-border exchange network made of four logical actors, two registries and a secure transport protocol. This page introduces it without jargon, before diving into technical details elsewhere.

The problem PEPPOL solves

Imagine a supplier in Sweden who wants to invoice a public hospital in Belgium. Without PEPPOL it would have to: discover how that hospital receives invoices (portal? email? proprietary EDI?), open an account with that hospital or its provider, learn its format (local UBL? in-house CIUS?), test, and repeat that work for each of its European public clients. Multiply across 27 member states and several thousand public buyers: onboarding cost becomes prohibitive.

PEPPOL solves this by standardising three axes: discovery (who is the recipient?), format (which XML do we send?), transport (over what channel?). A supplier only registers with one operator — its access point — and can reach any recipient registered on the network without a bilateral agreement.

The 4-corner model

The network's heart is the four-corner model. Rather than discuss it abstractly, let us walk through the sending of an invoice from Swedish supplier Acme AB to Belgian hospital UZB.

Corner C1 — business sender

Corner C1 is the sender's business application: Acme AB's ERP that generates the invoice. This corner does not speak PEPPOL directly: it hands the invoice (typically UBL Invoice 2.1) to its access point via a private API (REST, SFTP, queue, etc.). The C1↔C2 interface is local and specific to the contract between Acme and its access point provider.

Corner C2 — sender access point

Corner C2 is Acme's access point — for instance Tickstar or Pagero — a PEPPOL-certified operator. On invoice arrival, C2 does three things: it validates the document against the PEPPOL BIS Billing 3.0 Schematron; it queries the registry to find the recipient; and it pushes the message to the recipient over AS4.

Corner C3 — receiver access point

Corner C3 is UZB hospital's access point — say B2Brouter or Ibanity. It receives Acme C2's AS4 message, verifies the signature, returns an AS4 receipt proving delivery, and passes the document to its final client UZB.

Corner C4 — business recipient

Corner C4 is the recipient's business application: UZB hospital's accounting system. Like C1, C4 does not speak PEPPOL directly: it retrieves the document through a private API provided by its access point.

The pattern to remember: C1 → C2 → C3 → C4. Only the C2→C3 segment uses the standardised PEPPOL protocol; the C1↔C2 and C3↔C4 segments are private and open. This separation is what makes the network scalable: each access point can innovate on its client interface as long as it stays compliant on the PEPPOL side.

SMP and SML registries

For C2 to know where to push Acme's message bound to UZB, it must be able to resolve the recipient identifier. PEPPOL uses two cascading registries.

The SML (Service Metadata Locator) is a centralised DNS registry run by PEPPOL's technical authority. Given a recipient identifier — for example 0088:5790000435906 for UZB (ICD prefix 0088 for GLNs from GS1, followed by the Belgian GLN) — the SML returns the URL of the SMP serving that recipient.

The SMP (Service Metadata Publisher) is a federated registry. Each access point runs its own SMP for its clients. For a given identifier, the SMP publishes its capabilities: "this recipient can receive BIS Billing 3.0 Invoice", "this recipient can receive BIS Order 3.0", and for each capability the AS4 URL of C3 and the certificate to use for encryption.

The SML+SMP pair is inspired by Internet DNS: a centralised resolver to find the zone server, a zone server to publish details. That architecture lets any recipient change access point without changing its identifier.

AS4 eDelivery transport

Once C2 knows where to push the message (C3 URL) and with which certificate, it uses the AS4 protocol — a SOAP binding of OASIS ebMS 3.0. The PEPPOL AS4 profile is strict: mandatory signature, mandatory encryption, receipt in Non-Repudiation mode, One-Way Push communication pattern.

PEPPOL AS4 is part of the eDelivery building block of the Connecting Europe Facility (CEF), a shared European technical framework. The practical consequence: a country's public authority can rely on the open-source Domibus implementation to deploy its own access point without starting from scratch.

Security via X.509 certificates

Everything rests on a cryptographic chain of trust. Each access point holds a PEPPOL X.509 certificate, signed by the PEPPOL Authority CA. That CA is itself attested by OpenPeppol AISBL. Without a valid certificate, an access point can neither push nor receive.

For a new access point to join the network, it must: 1) pass annual PEPPOL certification (technical audit, conformance tests); 2) register with a national PEPPOL Authority (Digdir in Norway, AGID in Italy, AIFE in France, etc.); 3) obtain its certificate. The process is paid and follows an annual calendar. That is what sets PEPPOL apart from an open protocol like HTTP: network access is gated by an authority.

Further reading

• PEPPOL on ediverse — the reference page on PEPPOL BIS Billing 3.0, EN 16931 and UBL.
• EU e-invoicing roadmap 2025-2030 — where PEPPOL fits into the ViDA directive and national mandates.
• OpenPEPPOL: 4-corner architecture and European adoption — the long-form article.
• AS4 on ediverse — the transport page, for OASIS ebMS 3.0 details.