ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.
peppol — data architecture in transit

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 invoice-peppol-billing-3.0.xml
<?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 / BISDocuments exchangedUse
Profile 3 — Order OnlyOrderOne-way purchase order, no acknowledgment.
Profile 4 — Order + Despatch AdviceOrder, DespatchAdviceOrder with a despatch advice in return.
Profile 5 — Order, Order ResponseOrder, OrderResponseOrder with explicit accept / reject.
Profile 14 — Catalogue OnlyCatalogueSupplier catalogue exchange.
Profile 36 — Invoice ResponseInvoiceResponseBusiness-level status of an invoice (accepted, disputed, paid).
BIS Billing 3.0Invoice, CreditNoteEN 16931 invoicing. The most widely deployed profile.
BIS Catalogue 3.0CatalogueEN 16931-aligned product catalogue when required.
BIS Despatch Advice 3.0DespatchAdviceStandardised despatch advice.
BIS Order Only 3.0OrderPEPPOL 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-1 to BT-200+) — for example BT-1 Invoice number, BT-3 Invoice type code, BT-9 Payment due date.
  • Around 150 business rules (Business Rules, coded BR-XX) — for example BR-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).

CountryB2B obligation dateRequired format
FranceSeptember 2026 (receive) / September 2027 (send, large enterprises)Factur-X (CII) or UBL via the PPF
Belgium1 January 2026PEPPOL BIS 3.0
Germany1 January 2025 (receive)XRechnung or ZUGFeRD
ItalyAlready mandatoryFatturaPA via SdI
PolandFebruary 2026 then 2027KSeF (national XML)
Spain2026-2027Facturae + new hub
PortugalPhasedUBL via SAF-T
RomaniaMandatoryRO e-Factura
HungaryMandatoryNAV 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: