How Peppol works: the four-corner model

Peppol is not a format and it is not a website. It is an agreement about how two businesses that have never met can exchange a document, with enough structure that neither side has to negotiate anything first.

The shape of that agreement is four corners.

The four corners

1. The sender. Your software, producing an invoice.
2. The sender’s Access Point. A provider that accepts the document from you and puts it on the network.
3. The receiver’s Access Point. A different provider, who has agreed the same rules, and who accepts documents on the receiver’s behalf.
4. The receiver. Their finance system, getting structured data it can post without anyone retyping it.

Corners 1 and 4 are businesses. Corners 2 and 3 are the network. Between the two Access Points the document travels over AS4, a messaging protocol with signing, encryption and receipts — and if you never learn anything about AS4, that is the system working as intended. Your side of the conversation is corner 1 talking to corner 2, which in practice means an HTTPS API.

The reason for the extra hop is interoperability. Every participant only has to agree with their own provider. Because every provider has agreed to the same rules, any sender can reach any receiver without a prior relationship. It is the same trick as email, with two differences that matter: the addressing is a lookup rather than a guess, and the document has to be valid before it will be accepted.

How a sender finds a receiver

This is the part with no equivalent in email, and the part worth understanding properly.

Every participant has an identifier: a scheme and a value, such as a VAT number under scheme 9932. Before sending, the sending Access Point has to answer two questions: where does this participant receive, and what will they accept?

• The SML — the Service Metadata Locator — answers the first. It is a DNS-based lookup: hash the participant identifier, ask DNS, and get back the address of the participant’s SMP. Because it is DNS, it is fast and cached and has no central API to rate-limit you.
• The SMP — the Service Metadata Publisher — answers the second. It lists the document types that participant accepts, the profiles they support, and the endpoint and certificate of their Access Point.

So “can I send this business an invoice?” is answerable before you try, and the answer distinguishes between not on the network and on the network but does not accept this document type. Those are different problems with different fixes, and any code that treats both as a generic failure will send people looking in the wrong place.

One trap worth naming now. There is also a Peppol Directory, a searchable index of participants. It is optional: a business can be fully registered and reachable while being absent from the Directory. If you build a lookup that treats a missing Directory entry as “not registered”, you will tell customers their counterparties cannot receive invoices when they can. The SML and SMP are authoritative; the Directory is convenience.

What an Access Point does, and why not to be one

An Access Point takes on the things you do not want: the AS4 transport, the certificates, the receipts, the interoperability testing against every other provider, and the obligation to be available when someone sends you a document at three in the morning.

Becoming one is a real commitment. For an organisation of 1–50 staff, OpenPeppol’s fees are around €1,850 a year for an Access Point, plus about €1,500 for certification — and roughly €2,750 plus €2,500 if you also run an SMP. From 1 July 2027, ISO 27001 certification becomes mandatory for providers. On top of that sit the operational obligations.

For almost everyone building invoicing into software, the answer is to partner with an existing Access Point and spend the effort on the document instead. That is the stance this guide takes, and it is why einvoicing.dev validates, converts and looks up but does not send: sending is the part that is already a solved, competitive, commodity service.

What your code actually touches

Strip the network away and a sender’s job is small:

1. Produce a valid document. Peppol BIS Billing 3.0 is a restricted profile of the European standard EN 16931, expressed in UBL 2.1 XML. That is chapter 4.
2. Check it before sending. Three layers of rules, in order, which is chapter 5. Your Access Point will reject an invalid document, and finding out at that point is expensive.
3. Look the receiver up. Are they registered, and do they accept this document type? That is the next chapter.
4. Hand it over. An HTTPS call to your Access Point’s API. Every provider’s API looks different, which is an argument for keeping that call behind an interface of your own.

Notice what is not on that list: AS4, certificates, SMP registration, transport receipts. Those belong to corners 2 and 3. The mistake worth avoiding is thinking that “supporting Peppol” means implementing the network. It means producing a document the network will carry, and knowing where to send it.