Peppol is a network, not a format
The single most useful clarification: Peppol is a delivery network and a set of specifications, not a document format. The invoice you send over Peppol is a UBL document conforming to EN 16931, but that is the payload, not Peppol itself. Peppol is the infrastructure that routes that payload from your system to the recipient's system, plus the rules that govern what a valid document on the network looks like.
An analogy helps. UBL and EN 16931 describe what the letter says and how it is written. Peppol is the postal system: the addresses, the sorting offices, the delivery network, and the regulations about what you are allowed to post. You can write a perfectly valid letter and still be unable to deliver it if you are not connected to the postal system. On Peppol, the two problems (producing a valid document and delivering it) are genuinely separate, and conflating them is the source of most confusion.
Peppol is governed by OpenPeppol, a non-profit association, and originated in EU public procurement (the name began as Pan-European Public Procurement On-Line). It has since expanded well beyond Europe and beyond procurement, into general B2B invoicing, with authorities in countries including Belgium, the Netherlands, Norway, Singapore, Australia, Japan, New Zealand, and Malaysia.
The four-corner model
Peppol delivery is built on what is called the four-corner model. It is worth understanding because it explains why you cannot simply send a Peppol document directly to a business partner.
The four corners are: the sender (corner one), the sender's access point (corner two), the receiver's access point (corner three), and the receiver (corner four). A document flows from corner one to corner two to corner three to corner four. The sender hands their invoice to their own access point. That access point locates the receiver's access point and transmits the document to it. The receiving access point delivers it to the receiver.
The elegance of the model is that you connect once, to a single access point, and through it you can reach every other participant on the network, regardless of which access point they use. It works like mobile roaming or email: you have one provider, but you can reach anyone on any provider. This is what makes Peppol scalable. Without it, every business would need a direct technical connection to every other business.
Access points: why you cannot send Peppol invoices yourself
Corner two and corner three, the access points, are the part that surprises people. You cannot put a document directly onto the Peppol network from your own system. You must go through a certified Peppol access point.
An access point is a service provider that has been certified by OpenPeppol, has signed the Peppol agreements, meets the technical and security requirements, and maintains a connection to the network using the prescribed transport protocol (the current standard is Peppol's AS4 profile). Becoming your own access point is possible but demanding: it involves certification, ongoing compliance obligations, conformance testing, and maintaining the transport infrastructure. For this reason the large majority of organisations do not run their own access point. They use an existing certified provider, connecting to it through an API or integration, and let the provider handle the network transmission.
This is a critical planning point. Producing a valid Peppol document and transmitting it are two different capabilities. Software that generates a compliant invoice does not, by itself, put that invoice on the network. Transmission requires an access point relationship. Any Peppol implementation plan has to account for both.
How a document finds its recipient: addressing and discovery
For the sender's access point to deliver to the right place, it has to answer two questions: who is the recipient, and where does their access point live. Peppol solves this with a participant identifier scheme and a discovery mechanism.
Every participant on the network has a Peppol participant identifier. This is not a free-form name but a structured identifier, typically built from an official registration such as a VAT number or a national company number, prefixed with a scheme code that says which identifier system is being used. For example, a Belgian enterprise number uses one scheme code and a Belgian VAT number another. The scheme codes come from a controlled list, so an identifier unambiguously states both the value and the type of registration it represents.
Discovery works through two layers. The SML (Service Metadata Locator) is a central, DNS-based directory for the whole network. Given a participant identifier, it tells the sender's access point where to find that participant's metadata. That metadata lives in an SMP (Service Metadata Publisher), which each participant is registered with. The SMP publishes what document types the participant is able to receive and the address of the access point that serves them.
So the delivery sequence is: the sender's access point takes the recipient's participant identifier, uses the SML to locate the recipient's SMP, reads from the SMP which documents the recipient accepts and where their access point is, and then transmits the document there. This all happens automatically in the background, but it explains an important consequence: to receive documents on Peppol, you must be registered, with a participant identifier and an SMP entry declaring what you can accept. You cannot receive on a network that has no way to find you.
What Peppol BIS adds on top of the base standard
The document you send over Peppol is not just any invoice. It follows a Peppol BIS (Business Interoperability Specification), and for invoicing in Europe specifically, Peppol BIS Billing 3.0. Understanding the relationship between the Peppol specification and the underlying standard matters technically, and it is where Peppol's global reach becomes visible.
In Europe, the underlying standard is EN 16931, the European semantic model: the core data model and the base set of business rules. Peppol BIS Billing takes that as its foundation and layers additional rules on top, the Peppol-specific rules, which tighten and extend the base standard for use on the network. These appear as their own rule family in validation output, separate from the base rules. The document is expressed in UBL syntax and declares its conformance through a customization identifier that names the specification it follows, so a receiving system knows which rule set to apply.
Every Peppol BIS Billing 3.0 invoice declares the same two identifiers, and they are case-sensitive and must match exactly:
<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>The CustomizationID (BT-24) is what a receiving access point uses to recognise the document as a Peppol BIS 3.0 invoice and select the correct rule set. Even a minor variation in it, a wrong separator or version number, causes the document to be misidentified and rejected.
The pattern is always the same, but the base is not always EN 16931. As Peppol expanded beyond Europe, it ran into the fact that EN 16931 encodes European assumptions, such as EU VAT concepts, that do not fit other jurisdictions. The answer is PINT (Peppol International), a global base invoice specification that serves as the foundation for country-specific profiles outside the European world. Each jurisdiction defines its own billing profile on top of the PINT base: there are PINT profiles for Singapore, Malaysia, Australia and New Zealand, Japan, and a growing list of others. So there are effectively two lineages: the EN 16931-based Peppol BIS Billing used across Europe, and the PINT-based country profiles used in the expanding set of non-European Peppol markets.
The unifying principle is that Peppol always works the same way, a base semantic specification plus a jurisdiction-specific overlay of rules, whether the base is EN 16931 in Europe or PINT elsewhere. This is what lets one network span both worlds.
The practical implication is that validating a Peppol invoice is a two-layer exercise regardless of jurisdiction. The document must satisfy the base rules (EN 16931 or the relevant PINT base) and the specific overlay rules for its profile. Passing one is not passing the other. An invoice can be valid against the base standard and still fail because it breaks a profile-specific rule, and such a document will be rejected on transmission even though it looks correct against the base.
The maintenance dimension
As with the invoice formats themselves, Peppol is not static. OpenPeppol maintains the specifications and validation artefacts on a regular release cycle, with updates published on a schedule and transition windows during which participants are expected to migrate from the old version to the new one. New releases can adjust the rule sets, update code lists, and revise the specifications.
For anyone maintaining a Peppol integration directly, this creates a recurring obligation: track the release schedule, obtain the updated validation artefacts, test existing output against the new rules, and migrate within the transition window. Falling behind means generating documents that validate against a superseded rule set and may be rejected once the network moves on. The maintenance is ongoing and calendar-driven, not a one-time setup.
Two problems, deliberately separated
The clearest way to plan a Peppol implementation is to keep the two problems apart in your mind.
The first problem is the document: producing an invoice that is valid Peppol BIS, meaning correct UBL, conforming to EN 16931, and passing the Peppol overlay rules. This is a format and validation problem.
The second problem is delivery: getting that valid document onto the network and to the recipient, which requires an access point relationship and correct use of participant identifiers and discovery.
These are separable, and they are often solved by different components. You might produce and validate the document with one tool and transmit it through an access point provider. Keeping the distinction clear prevents a common planning mistake: assuming that a tool which generates Peppol documents also delivers them, or that an access point relationship removes the need to get the document itself right.
Where a service fits in
For the delivery side, most organisations use a certified access point provider rather than becoming an access point themselves, for the certification and maintenance reasons described above.
For the document side, producing and validating a compliant Peppol invoice is exactly the kind of work that can be delegated rather than built and maintained in house. InvoiceXML generates valid Peppol UBL and validates documents against both the base rules and the applicable overlay, across the European EN 16931-based Peppol BIS Billing profile and the PINT-based profiles for markets such as Singapore, Australia, and Japan, so the two-layer validation and the correct customization identifiers are handled for you, and kept current as the rule sets are revised. It can be reached through a REST API for direct integration, through no-code automation platforms, or through an MCP interface for AI-driven and agentic workflows. Because the standards and overlays are maintained on the service's side, updates arrive without you tracking release schedules or re-integrating validation artefacts.
It is worth being precise about the boundary, because it is the distinction this article has emphasised throughout: a document-layer service produces and validates the invoice, and an access point transmits it. The two are complementary. Getting the document right is necessary regardless of how it is delivered, and delegating that part removes one of the two ongoing maintenance burdens a Peppol integration otherwise carries.
Neither building nor delegating is universally correct. The purpose here is to make the architecture legible: a network with a four-corner delivery model, access points as the on-ramps, a discovery layer that routes by participant identifier, and a two-layer rulebook (a base semantic standard plus a jurisdiction-specific overlay) that governs the document. Seen clearly, the choices about what to build and what to delegate become straightforward rather than surprising.
Get started
Create a free InvoiceXML account → and you receive 100 free credits, no credit card required. Generate valid Peppol BIS Billing or PINT UBL from your own data and watch the two-layer validation run in a single call.
If you are mapping out a Peppol integration and want to separate the document layer from delivery cleanly, get in touch.
Related resources:
- Peppol UBL: formats, profiles, and country coverage
- UBL API: the complete Universal Business Language toolkit
- Create and validate Peppol UBL invoices in C# / .NET
- EN 16931 API: the complete toolkit for European e-invoice compliance
- E-invoicing mandate deadlines by country
- Full API documentation
InvoiceXML is a REST API for European and international e-invoice compliance covering Peppol UBL, Factur-X, ZUGFeRD, XRechnung, and CII. Generate valid Peppol BIS Billing and PINT documents and validate against both base and overlay rules with a single API call. Stateless and GDPR compliant by architecture.