What is Peppol?

The Four-Corner Model

Peppol uses a federated architecture called the four-corner model:

Corner 1: The sender (your business or your customer’s ERP)
Corner 2: The sender’s Access Point (certified Peppol service provider)
Corner 3: The receiver’s Access Point
Corner 4: The receiver

The sender’s ERP generates a Peppol BIS invoice and submits it to their Access Point. The Access Point looks up the receiver’s Peppol ID in the network’s directory (SML/SMP), finds the receiver’s Access Point, and delivers the invoice via the AS4 transport protocol. The receiver’s Access Point delivers the invoice to the receiver’s system.

No direct connection between sender and receiver is needed. No bilateral agreements. No format negotiation. As long as both sides have a certified Access Point and a registered Peppol ID, they can exchange documents.

Access Points

An Access Point is a certified service provider that connects your business to the Peppol network. It handles message routing, delivery receipts, and protocol compliance.

Access Points are certified by a Peppol Authority (one per country or region). Certification requires passing conformance tests for message handling, security, and SLA compliance.

As a business, you choose one Access Point. As an ERP vendor, you either become a certified Access Point yourself (significant investment, full control) or you integrate with an existing one via their API.

Most mid-market ERP vendors choose the second option. The Access Point handles the transport; the ERP vendor focuses on generating valid invoices.

Peppol IDs

Every participant on the Peppol network has a unique identifier. The format combines a scheme ID (identifying the type of identifier) with the actual value.

Common scheme IDs:

In UBL, a Peppol ID looks like this:

<cbc:EndpointID schemeID="0208">0123456789</cbc:EndpointID>

Getting the scheme ID wrong is one of the most common integration errors. The scheme must match the identifier type and the country. An invoice with a Dutch KvK number but scheme ID 9930 (German VAT) will be rejected.

SML and SMP (Service Discovery)

The Service Metadata Locator (SML) and Service Metadata Publisher (SMP) form Peppol’s directory system. When an Access Point needs to deliver an invoice, it queries the SML to find which SMP holds the receiver’s metadata, then queries the SMP to get the receiver’s Access Point URL and supported document types.

This happens automatically — you don’t interact with SML/SMP directly unless you’re building an Access Point.

Peppol BIS Billing 3.0

Peppol BIS (Business Interoperability Specification) Billing 3.0 is the invoice format specification. It’s a CIUS (Core Invoice Usage Specification) of EN 16931, meaning it takes the European e-invoicing standard and adds Peppol-specific rules on top.

The underlying syntax is UBL 2.1 (Universal Business Language). An alternative CII syntax exists but UBL is the default for most implementations.

Every Peppol invoice must pass:

1. UBL 2.1 XML schema validation
2. EN 16931 business rules (BR-01 through BR-65)
3. Peppol-specific rules (PEPPOL-EN16931-R001 through R080)
4. Country CIUS rules (if applicable — e.g., XRechnung for Germany, BEvCIUS for Belgium)

The specification identifier that goes in your invoice:

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0

Full specification: docs.peppol.eu/poacc/billing/3.0

Where Peppol Is Mandatory (2026)

The mandate landscape is moving fast. Here’s where Peppol stands as of March 2026:

For the complete country-by-country breakdown with mandate dates: EU e-invoicing deadlines →

Why ERP Vendors Need Peppol Support

If you build or maintain an ERP that serves EU businesses, Peppol support is no longer optional in most markets. The question isn’t whether to support it — it’s how to support it without breaking your existing invoice pipeline.

The common pitfall: adding Peppol as an afterthought. ERP generates a PDF or flat file, a converter turns it into UBL, and the result gets pushed to an Access Point. This works until it doesn’t — and it stops working exactly when your customer needs it most (month-end, audit, cross-border transaction with edge-case VAT rules).

The structural approach: validate every invoice against all four rule layers before it reaches the Access Point. Catch schema errors, missing fields, wrong scheme IDs, and rounding mismatches before they become rejections.

That’s what a pre-submission compliance gate does. It sits between your ERP export and the Access Point, and it makes sure nothing leaves your system that would get rejected on the other end.

Invoice Navigator validates Peppol BIS Billing 3.0 documents against both the Peppol-specific rules and the underlying EN 16931 standard, ensuring compliance for cross-border exchange.

Common Peppol Validation Errors

These are the errors we see most frequently in production Peppol pipelines:

PEPPOL-EN16931-R010 — Buyer reference is missing or invalid. Required for all Peppol invoices. Maps to BT-10 (Buyer Reference). Many ERPs leave this blank by default.

PEPPOL-EN16931-R001 — Business process identifier missing. The ProfileID element must contain the Peppol BIS 3.0 process identifier.

BR-CO-10 — Sum of invoice line net amounts doesn’t match the total. Usually a rounding issue — especially common with Belgian invoices after the 2026 rounding rule change.

BR-16 — Order reference missing when required. Some country CIUS rules make this mandatory (Germany’s BR-DE-15 requires a buyer reference for public sector invoices).

BR-CO-09 — VAT identifier prefix doesn’t match the country code. The VAT number must start with the correct two-letter country prefix.

For the full error library with fix guidance: All validation errors →

Peppol vs. Other Systems

Peppol vs. email with PDF attachment — Peppol delivers structured, machine-readable data. PDFs require OCR or manual entry. Most EU mandates explicitly require structured formats, making PDF invoices non-compliant.

Peppol vs. Italy’s SDI (FatturaPA) — SDI is Italy’s centralized national system. Peppol is federated and pan-European. Italy uses SDI domestically but is adopting Peppol for cross-border B2B. Compare in detail →

Peppol vs. France’s Chorus Pro / PDP — France uses certified platforms (PDP) that connect to a government portal (PPF). Peppol can serve as a PDP-compatible channel. France is Peppol-compatible but not Peppol-exclusive.

Peppol vs. Poland’s KSeF — KSeF is Poland’s centralized e-invoicing system. Peppol runs alongside it for cross-border transactions. Businesses selling to Polish buyers may need both.

Peppol vs. XRechnung — XRechnung is Germany’s CIUS (format specification). Peppol is the network. XRechnung invoices are sent via Peppol. You need both for German government invoicing. Compare in detail →

Step 1: Choose Your Access Point Strategy

Become an Access Point — if you process 100K+ invoices/year and want full network control. Requires Peppol Authority certification, infrastructure investment, and ongoing compliance obligations.

Use an existing Access Point — if you want to focus on invoice generation and let someone else handle transport. Most Access Points offer APIs for programmatic submission and delivery.

Step 2: Register Peppol IDs

Your customers each need a Peppol ID registered on the network. The Access Point handles registration. You need to know which scheme ID to use per country (see the table above).

Step 3: Generate Valid Peppol BIS 3.0 Invoices

Your ERP’s invoice export must produce valid UBL 2.1 XML that passes Peppol validation. The specification defines required fields, data types, and business rules.

Key required fields: invoice number (BT-1), issue date (BT-2), currency code (BT-5), seller/buyer identifiers, line items with prices and quantities, VAT breakdown.

Step 4: Validate Before Submission

Run every invoice through the four validation layers before sending it to the Access Point. This catches errors before they cause rejections.

Validate a Peppol invoice now →

For API integration: Developer documentation →
For sandbox testing: Sandbox environment →