Why Peppol exists
Before networks like Peppol, sending an e-invoice to a new customer meant agreeing a format, a channel and often a specific platform for every trading relationship. Peppol solves this the way email did for messages: connect once, reach everyone on the network.
Peppol is governed by OpenPeppol, a non-profit association. It defines the network rules, the technical specifications and the certification of service providers. National Peppol Authorities manage Peppol in their country and can add local rules.
The 4-corner model
| Corner | Who | Role |
|---|---|---|
| 1 | Sender (supplier) | Creates the invoice in its ERP |
| 2 | Sender’s Access Point | Sends the document over the network |
| 3 | Receiver’s Access Point | Receives the document |
| 4 | Receiver (buyer) | Imports the invoice into its system |
Supplier and buyer can use different Access Points. The network guarantees they can exchange documents, just as two email providers can.
The 5-corner model
Some countries add a fifth corner: the tax authority. Access Points (or accredited providers) report invoice data to the authority as invoices are exchanged. This is how the UAE model works, where Accredited Service Providers exchange invoices in the PINT AE format and report data to the Federal Tax Authority. It gives governments transaction-level visibility without running a central invoice platform. Read more in what is UAE e-invoicing.
Key Peppol building blocks
Access Point (AP). A certified provider that sends and receives documents using Peppol’s secure transport protocol. You connect your ERP to your AP, usually through the AP’s REST API.
Participant identifier. Each business on Peppol has an ID, typically a scheme code plus a national identifier such as a VAT or business registration number. Correct IDs in your customer master data are essential.
SMP (Service Metadata Publisher). A directory entry that says which Access Point a participant uses and which document types it can receive. The sending AP looks this up before delivering.
SML (Service Metadata Locator). The central lookup service that tells an AP where to find a participant’s SMP.
Document specifications. The formats documents must follow:
- Peppol BIS Billing 3.0: invoice and credit note specification based on the European standard EN 16931, used widely in Europe and beyond.
- PINT (Peppol International): an international invoice model designed so countries can add their own requirements as extensions, such as PINT AE for the UAE.
- National CIUS (core invoice usage specifications), such as Germany’s XRechnung, which add national rules on top of EN 16931.
Validation artefacts. Schematron rules published with each specification, used to validate documents before and during exchange.
How a Peppol invoice travels
- Your ERP posts an invoice.
- Your connector converts it to the required specification (for example BIS Billing 3.0 or PINT AE) and validates it.
- The connector sends it to your Access Point’s API with the receiver’s participant ID.
- Your AP queries the SML and SMP to find the receiver’s AP and supported document types.
- Your AP delivers the document securely to the receiver’s AP.
- The receiver’s AP delivers it to the buyer’s system.
- In 5-corner countries, invoice data is also reported to the tax authority.
- Status flows back to your connector and into your ERP.
Where Peppol is used
- Europe: Belgium (B2B e-invoicing via Peppol), Norway, the Netherlands, Germany (alongside XRechnung exchange), and public-sector e-invoicing across many EU states.
- Asia-Pacific: Australia, New Zealand, Singapore, Japan and Malaysia, with others adopting.
- Middle East: the UAE’s national e-invoicing system, with Oman reported to be following a Peppol-based approach.
Not every e-invoicing regime uses Peppol. Saudi Arabia’s ZATCA, Poland’s KSeF, Egypt’s ETA and Kenya’s eTIMS are centralised government platforms. A multi-country business usually needs both.
Integration checklist for Peppol
- Choose an Access Point (or ASP in the UAE) with a documented API and sandbox.
- Register your participant ID and confirm the document types you can receive.
- Collect correct participant IDs for your customers, and validate them via SMP lookup.
- Map ERP invoice data to the relevant specification (BIS, PINT AE, XRechnung).
- Validate with official Schematron rules before sending.
- Handle inbound invoices: parse, match to POs, create draft bills.
- Monitor delivery status and rejections.
Common mistakes
- Assuming one Peppol format fits all countries. The transport is shared, but specifications differ.
- Ignoring receiving. Many mandates require you to receive e-invoices too.
- Skipping identifier validation. A wrong participant ID means undeliverable invoices.
- Coupling the ERP to one Access Point’s proprietary API. Keep an adapter layer so you can switch.
Receiving invoices through Peppol
Most attention goes to sending, but receiving is where many businesses gain the most. When a supplier sends you a Peppol invoice, it arrives at your Access Point as structured data. Instead of someone typing a PDF into the ERP, your integration can:
- Fetch new inbound documents from your Access Point’s API.
- Validate them and check the supplier against your vendor master.
- Match them to purchase orders and goods receipts.
- Create draft supplier bills in your ERP for approval, with the original XML attached.
- Flag mismatches (price, quantity, tax) for review.
Several mandates, including Germany’s and the UAE’s, make receiving structured invoices part of the obligation, so plan the inbound flow from day one rather than as a later phase.
Validation: why the official rules matter
Each Peppol specification comes with Schematron validation rules: machine-readable checks for mandatory fields, calculations, code values and field combinations. Access Points run them, and so should your integration, before sending.
Validating early has two benefits. Errors are caught inside your own system, where the finance team can fix them, instead of coming back as rejections hours later. And because the rules are official artefacts, you are testing against exactly what the network will enforce. When a specification is updated, the new rule set is dropped into the validation step and tested before go-live.
Peppol and multi-country businesses
For a business invoicing in several countries, Peppol changes the integration question from “how do we connect to each customer?” to “how do we produce the right document for each country?”. The transport through your Access Point is the same for a Belgian customer, a Singaporean customer or, through an ASP, a UAE customer. What changes is the specification and the business rules.
That is why we design Peppol integrations around a canonical invoice model. Your ERP data is mapped once into a neutral structure, then rendered into Peppol BIS Billing 3.0, PINT AE, XRechnung or another specification by a country module. Validation runs against each specification’s official rules before anything is sent. When a country updates its rules, only that module changes.
The same structure handles non-Peppol mandates. A Saudi entity can use a ZATCA module and a Malaysian entity a MyInvois module, both fed from the same canonical layer. One integration platform, many outputs.
How Co-Mate helps
Co-Mate is not an Access Point. We connect your ERP to the Access Point or ASP you choose, map your data to BIS, PINT AE, XRechnung and other specifications, and handle inbound invoices. See our Europe Peppol integration and UAE e-invoicing services.