Peppol is more than a network for e-invoices. It is a set of agreements on which documents you exchange, how those documents are structured, how you identify the recipient and how messages travel securely from sender to recipient.

Do you build software that sends or receives e-invoices or other procurement documents? Then this knowledge determines which document types you support, which validations you perform and whether you build the infrastructure yourself or outsource it to a service provider.

Document types within Peppol

Every document type within Peppol is defined in a Peppol BIS specification. A BIS describes which fields are mandatory, which code lists apply and which business rules a document must comply with. All documents are based on the UBL syntax.

Invoice

The most widely used document on the network, based on Peppol BIS Billing 3.0 and therefore on the European standard EN 16931.

✓ Complies with the EN 16931 semantic model
✓ Contains mandatory fields for VAT, parties and invoice lines
✓ Supports attachments, such as a PDF rendition

Credit Note

Credits a previously sent invoice in full or in part. Also covered by Peppol BIS Billing 3.0.

✓ Separate UBL document type, alongside the invoice
✓ Refers to the original invoice
✓ Same validation rules as the invoice

Corrective invoice

Corrects a previously sent invoice. Whether this is permitted or a credit note is required depends on national legislation.

✓ Falls within Peppol BIS Billing 3.0
✓ Refers to the original document
✓ National rules determine its use

Order and order response

Allows a buyer to place an order electronically. The supplier accepts, rejects or amends it.

✓ Defined in Peppol BIS specifications for ordering
✓ Order and response each have their own document type
✓ Lays the foundation for automatic matching with the invoice

Despatch Advice

Announces in advance what will be delivered, when and in what packaging.

✓ Supports goods receipt and inventory management
✓ Refers to the underlying order
✓ Enables three-way matching (order, delivery, invoice)

Catalogue

Shares product information and prices between supplier and buyer.

✓ Contains items, specifications and prices
✓ Optionally with a catalogue response from the buyer
✓ Prevents manual entry of item data

Message Level Response (MLR)

A technical response on the content: has the received message been processed correctly or rejected?

✓ Reports validation errors back to the sender
✓ Concerns the message, not the business content
✓ Useful for error handling in your software

Invoice Response (IMR)

A business status message about an invoice: received, in process, accepted, rejected or paid.

✓ Gives the supplier insight into the invoice status
✓ Reduces status queries by email and phone
✓ Works with standardised status codes

A typical document process

Catalogue: The supplier shares items and prices.
Order: The buyer orders on the basis of the catalogue.
Order response: The supplier accepts, amends or rejects the order.
Despatch Advice: The supplier announces what will be delivered.
Invoice: The supplier invoices. The buyer can report the status back with an Invoice Response.

Not every organisation uses the full process. Many implementations start with the invoice and the credit note and later expand to ordering and logistics documents.

PINT, the international invoice model

PINT (Peppol International Invoice Model) is an additional model alongside Peppol BIS Billing 3.0. BIS Billing 3.0 is built on the European standard EN 16931 and assumes a European VAT system. Countries outside Europe often work with other tax systems, such as GST or SST. PINT makes Peppol usable for those countries too.

Base specification

A common core of invoice fields that applies to all PINT variants.

Country-specific extensions

Additional rules per country or region, for example for Japan, Australia and New Zealand, Singapore and Malaysia.

Interoperable

The same infrastructure and the same transport protocol as the rest of the Peppol network.

Identifier schemes: how Peppol recognises a participant

Every participant on the Peppol network has a Peppol ID, made up of a scheme ID from the ISO 6523 list and an identification number. To learn which scheme IDs are common and how to find your own Peppol ID, see Peppol ID.

Validation and compliance

A Peppol document passes through two validation layers before it is considered correct.

Syntactic validation

A check of the XML structure against the UBL XSD schema: is the structure correct, are the elements in the right place and do they have the right data type?

Schematron validation

A check of the business rules: the rules from EN 16931, Peppol-specific rules and, where applicable, country-specific rules, such as correct totals and mandatory fields per situation.

Examples of country-specific rules are the NLCIUS (the Dutch CIUS) in the Netherlands and XRechnung in Germany; in Belgium and Luxembourg, Peppol BIS Billing 3.0 is the standard, and in France e-invoicing runs through plateformes agréées (approved platforms).

You can read more about the semantic model underlying the Peppol invoice in What is the EN 16931? How the various invoice formats relate to one another is explained on the E-invoice formats page.

The technical core of the Peppol network

In the Peppol architecture, the sender and the recipient are each connected through an Access Point. The Access Points exchange messages with each other. Anyone with an Access Point can reach any participant on the network, regardless of which service provider that participant uses.

Access Point and AS4

Sends and receives messages via the AS4 protocol. Validates messages, routes them to the correct receiving Access Point and processes technical receipt acknowledgements.

SMP (Service Metadata Publisher)

Records for each participant which document types it can receive and through which Access Point. A sender consults the recipient's SMP before sending a message.

SML (Service Metadata Locator)

The central, DNS-based registry of the network. Points each Peppol ID to the correct SMP, so that every Access Point can find the recipient without a central message hub.

PKI and certificates

All Access Points and SMPs use X.509v3 certificates within the Peppol PKI framework, with at least SHA-256. Certificate status is checked via OCSP. Certificates have a limited validity period and must be renewed periodically.

Peppol Directory

A publicly searchable overview of participants on the network. You search by name or Peppol ID and see which document types an organisation supports.

Peppol standardises the traffic between Access Points. The connection between your software and an Access Point is not standardised: each service provider offers its own API for this, usually for sending documents, querying status, validation and looking up participants in the SMP and the Directory.

Do you run your own Access Point? Then take operational requirements into account, such as encrypted connections via TLS 1.2 or higher, high availability, monitoring, audit logging and timely certificate renewal. Technically, a modern, supported runtime environment is sufficient, for example Java or .NET.

What this means for you as a software vendor: build or outsource?

If you want to support Peppol in your software, you choose between your own Access Point with SMP and an integration with a service provider. Your own Access Point gives you full control, but you then become responsible for everything listed below. A service provider takes over these tasks.

Accession and contracts

The formal accession with the Peppol Authority and the associated obligations.

Certificate management

Requesting, installing and periodically renewing PKI certificates, including OCSP checks.

AS4 transport

Sending, receiving, receipt acknowledgements and error handling between Access Points.

SMP registration

Registering your customers in the SMP and in the SML, with the correct document types.

Validation

Syntactic and Schematron validation, updated with every new release of the specifications.

Availability and monitoring

Redundant infrastructure, logging and incident handling.

New document types and models

Support for ordering, logistics or PINT without your own development work at transport level.

Identification of end users

Establishing who your customers are before you register them.

Reporting

Mandatory periodic reporting to OpenPeppol.

Security

In the Netherlands, the Peppol Authority requires ISO 27001 or equivalent.

What you still do yourself: populate your data model correctly, record the correct identifiers and scheme IDs, make errors and status messages (MLR, Invoice Response) visible to your users and integrate your service provider’s API. When choosing, pay attention to the document types and PINT variants a provider supports, the quality of the API and documentation, and the way validation errors are reported back.

The same assessment framework applies to integrators. Anyone connecting multiple clients to Peppol benefits most from a provider with clear participant onboarding and good support for SMP registration.

The standards on this page form the foundation. The next step is Integrating Peppol into your software: which API, which document types and which service provider suit your product.

Use the comparison tool to find service providers that suit your product, and ask about the document types and PINT variants you need.