Peppol in your billing system: access points, participant IDs, status

Peppol often gets mistaken for an invoice format. It's a network for exchanging business documents, with fixed rules on who may send, how recipients are found and which document types travel over it. The invoice itself is still an EN 16931 invoice. Peppol settles how it arrives.

For a SaaS company that raises three questions. Do we need Peppol at all? Do we join the network ourselves or use a service provider? And what does our billing system have to store so that delivery and status stay traceable?

How the network works: four corners, two access points

Peppol uses a four-corner model. Your billing system (corner 1) hands the invoice to your access point (corner 2). That access point looks up the recipient's access point (corner 3) and transmits the invoice there. From there it reaches the customer's system (corner 4). So you don't need a connection to each customer, just one access point.

How does your access point know where to send? Every recipient is registered on the network with a participant ID. A Service Metadata Publisher (SMP) records which access point handles that ID and which document types the participant can receive. Before each transmission, the sending access point looks this up.

Access points and SMPs are run by certified service providers. OpenPeppol governs the network, and in many countries a national Peppol Authority oversees the rules. In Germany that's KoSIT, according to the OpenPeppol country profile for Germany. KoSIT also maintains XRechnung.

When you need Peppol

In Germany, the most common reason is the public sector. According to the country profile, the IT Planning Council decided that every public body that accepts electronic invoices must be reachable via Peppol. To address German public bodies you need two pieces of information: the Peppol ID and, in addition, the Leitweg-ID for internal routing. The receiving office gives you the Leitweg-ID.

In German B2B, the law doesn't prescribe a transmission channel. An e-invoice may arrive by email, API or portal, as long as both sides agree. Peppol is one option there. It becomes relevant when larger customers move their invoice intake to Peppol and are reluctant to take invoices by email.

Across borders Peppol carries more weight. Several European countries already use it for invoices to public bodies, and under the ViDA package, e-invoicing becomes mandatory for intra-EU B2B supplies from 1 July 2030. If you already manage delivery channels per customer, you'll add a channel then rather than rebuild your invoice model.

A simple rule: if you have public-sector customers, or customers who explicitly ask for Peppol, connect it. Otherwise an e-invoice by email will do for now, with Peppol on the roadmap.

Your own access point or a service provider

Running your own access point means OpenPeppol membership, a service provider agreement, testing on the network and ongoing operation under the Peppol Authority's requirements. For a software company whose product isn't invoice delivery, that rarely pays off.

The usual route is a certified service provider whose API you call from billing. When choosing one, check:

• Whether you generate the XML yourself and the provider only transports it, or whether it converts from your data. If you generate it, the invoice in your system stays the authoritative version.
• Whether it offers participant lookup as a separate API, so you know before sending whether a customer is reachable.
• Which status messages it returns by webhook, and how long it keeps transmission evidence.
• Whether it can register you as a recipient, in case suppliers start sending to you over Peppol.

What your billing system must store about participants

A participant ID consists of a scheme and a value, for example a scheme for VAT numbers or the one for Leitweg-IDs. The permitted schemes are listed in the EAS code list of Peppol BIS Billing 3.0. Store both parts separately, not as one concatenated string. The same data goes into the invoice itself as the buyer's and seller's electronic address.

customer_delivery_profile
  channel: peppol | email | portal
  peppol_participant: { scheme, value }
  buyer_reference: "<Leitweg-ID, for public bodies>"
  last_lookup: { checked_at, found, document_types }
  valid_from, valid_to

Before sending, check whether the participant is found and whether it can receive the document type. That gives three cases:

A common mistake: the participant ID is stored under the wrong scheme, say a VAT number filed under a company-register scheme. The lookup finds nothing even though the customer is registered. So get the ID from the customer exactly as it is registered on the network.

Delivery status: transmitted isn't accepted

The acknowledgement your access point receives after transmission only says the recipient's access point has taken the message. It says nothing about whether the customer processes the invoice. Business-level responses such as acceptance or rejection travel in Peppol as separate messages. According to the country profile, KoSIT plans to make the Message Level Response mandatory. Today you can't rely on every recipient answering.

For the status model that means submitted (handed to your access point), delivered (arrived at the recipient's access point), and optionally accepted or rejected when a business response comes back. Payment terms in your system should hang off delivery, not off generating the file. An invoice still on submitted after, say, 48 hours belongs in a queue someone actually looks at.

The content has to be right before sending, because Peppol transports whatever you hand over. How to check XRechnung before sending is covered in validating XRechnung against EN 16931, and which fields a SaaS invoice needs in XRechnung for SaaS invoices.

What to settle before connecting

1. Which customers ask for Peppol today, and what are their participant IDs? For public bodies, also the Leitweg-ID.
2. Do you generate the XRechnung or Peppol BIS invoice yourself, and is it validated before handover?
3. Which service provider, which status messages, how long is transmission evidence kept?
4. Does billing have a delivery profile per customer with channel, scheme, ID and validity period?
5. Are there separate statuses for submitted, delivered and rejected, and does someone watch the stuck invoices?

Kontier generates XRechnung from the same versioned pricing and tax data as the PDF and the ledger entry; the connected channels are listed under integrations.