Back to the glossary
Infrastructure

Peppol: how the European invoice framework works

Peppol is a Europe-wide framework for exchanging procurement documents. Participants join through a certified provider, an access point, and delivery between those providers follows uniform rules. Because every participant is registered in a directory, no company needs to know another's technical setup — the participant identifier is enough.

Also:
PEPPOL · OpenPeppol · Peppol-Verbund
Reviewed on 2026-08-26.

The problem Peppol solves

Two companies want to exchange invoices electronically. Without a common framework they have to settle: which format? which transport? which credentials? who reports failures, and how?

With two parties that is one agreement. With a thousand parties it is hundreds of thousands of agreements — and that is precisely where classic data interchange failed for decades: it worked beautifully between large partners who could afford the coordination, and not at all for everybody else.

Peppol inverts it: each participant coordinates once with a provider, not with every trading partner.

The four-corner model

The basic figure has four parties:

text
1Sender  ──►  Access Point A  ──►  Access Point B  ──►  Recipient
2(corner 1)     (corner 2)          (corner 3)         (corner 4)
  • The sender hands the document to their own provider.
  • Access point A prepares it and passes it on.
  • Access point B is the recipient's provider and takes it in.
  • The recipient receives it in the shape their system expects.

The decisive point: corner 1 and corner 4 do not know each other technically. The sender knows only the recipient's participant identifier. Everything else — address, supported document types, protocol — lives in the directory.

How a document finds its way

Three building blocks make up the addressing:

The participant identifier. It identifies the recipient uniquely and consists of a scheme and a value — such as the VAT identification number with the matching scheme prefix. It travels in the document itself, in BT-49.

The SMP (service metadata publisher). The directory recording which document types a participant accepts and at which technical address. Anyone not listed there cannot be reached — even if their company exists.

The SML (service metadata locator). The central directory that resolves, via DNS, which SMP is responsible for a given identifier. It is the first stop of every delivery.

The sequence is therefore always the same: identifier → ask the SML which SMP is responsible → ask the SMP where and in what shape → hand the document over.

Peppol BIS: the format

Peppol prescribes not only the route but the document. Peppol BIS Billing 3.0 is a CIUS of EN 16931 in UBL syntax.

That is the most important practical consequence for implementation: addressing Peppol means generating UBL. CII is not foreseen there — unlike XRechnung, which permits both syntaxes.

Because Peppol BIS is a CIUS, the same holds here: it may restrict, not extend. A Peppol BIS document is therefore readable by anyone who understands the core of the standard.

What you need to take part

Three things, and none of them is a contract with "Peppol":

  1. An access point. Peppol is not a service you attach to directly — taking part runs exclusively through a certified provider.
  2. An SMP entry. The access point registers you with your participant identifier and the document types you accept.
  3. Documents in the right format. Peppol BIS Billing 3.0, valid against its rule set.

Point three is the part you can prepare independently of everything else: producing and checking a Peppol BIS document is not a question of connectivity. The current state of our own Peppol gateway is on the roadmap.

Peppol and Germany

Germany did not build its public-sector invoice intake on Peppol alone: the federal platforms accept documents by other routes too, and addressing runs through the Leitweg-ID rather than a participant identifier.

Peppol is nonetheless present here — the platforms are reachable, and the common UBL variant of XRechnung comes from the same world. Anyone invoicing public bodies beyond the national border meets it sooner or later.

What Peppol is not

Not a reporting channel to the tax administration. The framework moves documents between companies. Countries that additionally have invoice data reported to the state add a fifth corner for that — a national extension, not part of the base model.

Not an archive. Delivery is an event, not retention. The duty to keep the structured original in an audit-proof way stays with you.

Not a format translator. If you generate CII and want to address Peppol, you must convert. The framework accepts what its specification foresees.

Frequently asked questions