PEPPOL — Pan-European Public Procurement Online
An open, federated network that carries business orders and electronic invoices between European public administrations and companies — and increasingly reaches Australia, Singapore and Japan too.
What is PEPPOL?
PEPPOL is not one more standard alongside EDIFACT or X12: it is a network, a family of specifications and a governance body. The network is built on the four-corner model: the sender (corner 1) hands their document to their Access Point (corner 2); that Access Point routes the data across PEPPOL eDelivery to the receiver's Access Point (corner 3), which delivers it to the receiving end customer (corner 4). The routing key is a Participant ID registered in each Access Point's SMP (Service Metadata Publisher).
Every document type exchanged on the network is framed by a Business
Interoperability Specification — a BIS. The most widely
deployed is PEPPOL BIS Billing 3.0, which defines the electronic
invoice and credit note. All BIS sit on top of the UBL 2.1 syntax from OASIS: a
PEPPOL invoice is therefore, mechanically, a UBL document compliant with a European
semantic profile (EN 16931) plus extra PEPPOL-specific business rules (the
Schematron file PEPPOL-EN16931-UBL.sch).
Anatomy of a PEPPOL Billing 3.0 invoice
A PEPPOL invoice is an XML file rooted at <Invoice> in the UBL 2.1
namespace. Two elements at the head declare compliance: cbc:CustomizationID names the semantic profile (EN 16931 bound to
PEPPOL), while cbc:ProfileID names the business process being followed
(here the billing profile). The pair AccountingSupplierParty / AccountingCustomerParty carries
the issuer and the recipient; line-level detail lives inside cac:InvoiceLine.
<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>F-2026-00187</cbc:ID>
<cbc:IssueDate>2026-05-13</cbc:IssueDate>
<cbc:DueDate>2026-06-12</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">5790000435975</cbc:EndpointID>
<cac:PartyName><cbc:Name>Atelier Marchand SARL</cbc:Name></cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>12 rue de la Soie</cbc:StreetName>
<cbc:CityName>Lyon</cbc:CityName>
<cbc:PostalZone>69001</cbc:PostalZone>
<cac:Country><cbc:IdentificationCode>FR</cbc:IdentificationCode></cac:Country>
</cac:PostalAddress>
</cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">5790000123456</cbc:EndpointID>
<cac:PartyName><cbc:Name>Coopérative Textile Nord</cbc:Name></cac:PartyName>
</cac:Party>
</cac:AccountingCustomerParty>
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="MTR">120</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">2160.00</cbc:LineExtensionAmount>
<cac:Item><cbc:Name>Raw canvas 220 g/m²</cbc:Name></cac:Item>
<cac:Price><cbc:PriceAmount currencyID="EUR">18.00</cbc:PriceAmount></cac:Price>
</cac:InvoiceLine>
</Invoice>
The EndpointID with its schemeID (here 0088,
the GS1 GLN) identifies the party uniquely on the PEPPOL network and lets Access
Points route the document. PEPPOL's value sits in this pair: identifier and
Schematron. A UBL file that does not satisfy the PEPPOL rules is rejected on
receipt, which is what guarantees end-to-end interoperability.
PEPPOL BIS specifications
OpenPEPPOL publishes several profiles and BIS. Each profile describes a business choreography (order only, order + AR, catalogue…); each BIS fully describes the syntax and rules of an individual document.
| Profile / BIS | Documents exchanged | Use |
|---|---|---|
| Profile 3 — Order Only | Order | One-way purchase order, no acknowledgment. |
| Profile 4 — Order + Despatch Advice | Order, DespatchAdvice | Order with a despatch advice in return. |
| Profile 5 — Order, Order Response | Order, OrderResponse | Order with explicit accept / reject. |
| Profile 14 — Catalogue Only | Catalogue | Supplier catalogue exchange. |
| Profile 36 — Invoice Response | InvoiceResponse | Business-level status of an invoice (accepted, disputed, paid). |
| BIS Billing 3.0 | Invoice, CreditNote | EN 16931 invoicing. The most widely deployed profile. |
| BIS Catalogue 3.0 | Catalogue | EN 16931-aligned product catalogue when required. |
| BIS Despatch Advice 3.0 | DespatchAdvice | Standardised despatch advice. |
| BIS Order Only 3.0 | Order | PEPPOL order in the post-PEPPOL-4.0 set. |
Concretely, for every BIS OpenPEPPOL publishes: the UBL syntax tree, two Schematron sets (one for the CEN/TC 434 transposition of EN 16931, one for PEPPOL's own rules), a set of display XSLT stylesheets, and a reference archive of example invoices. Everything is listed on the canonical landing page docs.peppol.eu/poacc/billing/3.0/.
EN 16931 — the European semantic model
EN 16931 is the European Norm adopted by CEN in 2017 in application of EU Directive 2014/55. It defines the semantic model of the electronic invoice in two blocks:
-
Around 165 business terms (Business Terms, coded
BT-1toBT-200+) — for exampleBT-1Invoice number,BT-3Invoice type code,BT-9Payment due date. -
Around 150 business rules (Business Rules, coded
BR-XX) — for exampleBR-01"An Invoice shall have a Specification identifier",BR-CO-15"Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110)".
Each Member State may layer national rules on top, prefixed by the
country code: BR-FR-XX for France (Factur-X via the Portail Public de
Facturation), BR-DE-XX for Germany (XRechnung), BR-IT-XX
for Italy (FatturaPA), and so on. The PEPPOL rules themselves add a third layer that
applies to every invoice traveling on the network, regardless of country.
E-invoicing mandates 2026
B2B electronic invoicing is becoming mandatory across most Member States. The map below reflects the official picture in May 2026 (re-check every six months — the switch-over dates do slip).
| Country | B2B obligation date | Required format |
|---|---|---|
| France | September 2026 (receive) / September 2027 (send, large enterprises) | Factur-X (CII) or UBL via the PPF |
| Belgium | 1 January 2026 | PEPPOL BIS 3.0 |
| Germany | 1 January 2025 (receive) | XRechnung or ZUGFeRD |
| Italy | Already mandatory | FatturaPA via SdI |
| Poland | February 2026 then 2027 | KSeF (national XML) |
| Spain | 2026-2027 | Facturae + new hub |
| Portugal | Phased | UBL via SAF-T |
| Romania | Mandatory | RO e-Factura |
| Hungary | Mandatory | NAV Online Számla |
Transport: AS4
PEPPOL eDelivery carries documents over AS4, an applicative profile published by OASIS on top of ebMS 3.0. AS4 functionally succeeds AS2 at the PEPPOL layer: same signed-and-encrypted peer-to-peer approach, but on a SOAP stack rather than bare HTTP, plus a reliability layer (WS-ReliableMessaging) that guarantees no message loss and no duplication.
For exchanges outside PEPPOL — typically EDIFACT or X12 traffic between industrial companies and their suppliers — AS2 remains dominant. The two protocols frequently coexist at the same integrator.
Tools
- PEPPOL Validator — planned for ediverse v1.2, Schematron
validation of PEPPOL and EN 16931 rules in your browser.
Coming at
/tools/peppol-validator/. - Official OpenPEPPOL validator — peppol.helger.com — a public service maintained by Philip Helger, full Schematron coverage.
Further reading
Official specifications to read before any integration:
- PEPPOL BIS Billing 3.0 — docs.peppol.eu (November 2025 release, cited verbatim throughout these pages).
- UBL 2.1 — OASIS Open Standard (published 2013, copyright OASIS Open).
- EN 16931 — CEN (paywalled, but the semantic model is restated inside BIS Billing 3.0).
- OpenPEPPOL — peppol.org for governance, the Access Point directory, and the Authority register.