The word "Peppol" is used to mean at least four different things in a normal conversation: a network, a set of specifications, a document profile, and a company somebody is buying software from. Only three of those exist.
Separating them makes almost every other question easier.
What it actually is
A governance framework with published specifications attached. There is no central operator through which documents pass, no proprietary technology, and nothing to license. What there is:
- Specifications, published openly, covering the document profiles, the addressing mechanism and the transport.
- Agreements that a service provider signs, binding it to implement those specifications and to accept traffic from every other provider.
- Authorities that administer those agreements in a country or domain, accredit providers, and may add national requirements.
- Providers — access points — that connect businesses to the network.
The agreement is the load-bearing part. Specifications alone do not produce interoperability; plenty of published standards are implemented incompatibly by everybody. What makes this one work is that each provider has contractually undertaken to accept documents from providers it has no relationship with, and can be held to it.
The four corners in practice
You are corner one or corner four. Your provider is corner two or three. That relationship is the only one you manage.
The provider's obligations to you are commercial and negotiable: availability, support, retention, price, onboarding assistance. Its obligations to the network are not negotiable, and they are the reason your document reaches a customer whose provider you have never heard of.
Three implications people find counter-intuitive:
You cannot be unreachable to a specific counterparty. If both parties are on the network, delivery is possible. A provider refusing to deliver to another provider would be in breach of the framework.
Changing provider does not change your address. Your participant identifier belongs to you, and the registration that points it at an endpoint is updated when you move. Migrations are routine, which is a genuine and underrated protection against being locked in.
Your provider's compliance is your exposure. The provider validates, transmits, produces delivery evidence, and in many arrangements archives on your behalf. Choosing one is a controls decision. See choosing an access point or service provider.
Addressing, briefly
Delivery depends on knowing where to send. That is resolved from the recipient's participant identifier through a lookup: find the service metadata for that participant, discover which document types it can receive and at which endpoint, and deliver there.
The important consequence for a business is that being registered is not the same as being reachable for a given document type. A participant can be registered and still not be reachable for the specific profile you are sending, in which case delivery fails at lookup rather than in transit. The mechanics are in addressing on Peppol.
Should you run your own access point?
Occasionally the right answer. Usually not, and the reasoning is worth setting out because it comes up in every large implementation.
| Your own access point | A provider | |
|---|---|---|
| Accreditation | Yours to obtain and maintain | Theirs |
| Certificates | Yours to manage and renew | Theirs |
| Specification updates | Yours to track and implement, on the network's cycle | Theirs, usually included |
| Availability obligation | Yours | Contractual, with a service level |
| Marginal cost per document | Low | Per-document or per-entity pricing |
| Who is accountable at 3am | You | Them, if the contract says so |
The volume at which the arithmetic favours running your own is high, and the arithmetic is not the whole decision: an access point is a piece of regulated infrastructure with an availability obligation, and running one means somebody on your payroll owns that permanently. Businesses that decide on marginal cost alone frequently reverse the decision within two years.
What the network does not do
It does not validate business content. The buyer's own rules are outside the network's scope entirely.
It does not report to a tax administration. Delivery and reporting are separate obligations, which is precisely the point of e-invoicing and e-reporting are not the same obligation. Where a country requires both, the reporting is a second interface.
It does not archive for you. Some providers offer it as a service; the obligation remains yours, and the terms on which a provider holds your documents matter at the end of the contract, not at the start. See archiving a structured invoice.
It does not make an invoice correct. A conforming document with the wrong tax treatment travels perfectly.
Reachable is not the same as able to process
The most useful distinction to carry away from this is one the network's own vocabulary obscures.
Being reachable means a document addressed to you resolves to a provider that will accept it. That is a statement about routing, and it is what a directory lookup tells you. It says nothing about what happens next.
Being able to process means that the document, once delivered, reaches a system that can read it, validate it against your own requirements, and turn it into something your ledger recognises. That is a statement about your internal arrangements, and nothing in the network knows or checks it.
The gap between the two is where a specific and common failure lives. A business registers on the network — perhaps because a customer asked, perhaps as part of a project that was descoped — and the registration is technically correct. Documents arrive. They are acknowledged, because acknowledgement happens at the provider. And they land in a destination that nobody has been told to monitor, where they sit until a supplier telephones about a payment.
From the sender's point of view that transaction succeeded at every observable point. From the receiver's point of view nothing happened. Neither party has an error to look at, which is why this failure persists for weeks rather than hours, and why registering an address is the beginning of the receiving-side work rather than the end of it.
The reason it matters beyond invoicing
The network carries more than invoices. Orders, despatch advices, catalogues and other business documents use the same addressing and the same transport, and several countries have begun using it for document types that have nothing to do with the private sector.
For a business making an architecture decision, that is worth knowing: connecting to the network is not a single-purpose integration, and the next mandate that arrives may use the same channel. Building the connection as reusable infrastructure rather than as an invoicing feature is one of the few decisions in this field that is cheap to take early and expensive to take late. The general point is made in in the ERP, in a platform, or both.
