A supplier asks a new customer for their Peppol ID, receives a number, files it in the customer master and treats onboarding as finished. The number is genuine. The invoice still does not arrive, and the problem surfaces days later as silence rather than as an error message.
That happens because an address on this network is not a destination. It is the start of a chain of lookups, each answering a different question: where the receiver's metadata is published, what that metadata says the receiver will take, and which endpoint and certificate transport should then use. Any link can answer wrongly while the one before it answered correctly.
Taking the chain apart is worth doing once, because it gives you something no provider dashboard will: a way to read a delivery problem and work out who has to fix it. It is rarely the person who typed the identifier.
A participant identifier is a scheme and a value
The identifier is a pair. The value is normally a number the business already holds for another purpose — a national company registration number, a VAT identifier, a location number from an international scheme. The scheme says which register that number was drawn from.
Neither half is an address on its own. The same digit string can be a company number in one national register and something entirely unrelated in another, so a value without its scheme is a lookup key with no table attached.
The permitted schemes come from a published code list maintained by OpenPeppol and built on the international register of identifier schemes. That places addressing squarely inside the same discipline as every other coded value on an invoice, which is the subject of code lists and the schemes behind them.
A supplier portal with a single box labelled "Peppol ID" collects the value and discards the scheme, or accepts whatever the customer pasted in whatever notation their provider happens to use. What you end up with looks like a complete data set and is not. Storing the two parts as two fields is the cheapest decision in the whole project, and it belongs in master data work rather than in an integration.
From an identifier to a publisher
The first lookup does not ask what the receiver accepts. It asks where to go and ask.
The identifier is transformed into a domain name by a published algorithm and resolved through the Domain Name System. The service answering that query is the Service Metadata Locator, and its entire job is to name the Service Metadata Publisher responsible for that participant. It holds no business information. It returns a pointer.
What the service metadata actually says
The publisher returns a signed document, and this is where the address stops being a location and becomes a claim about capability.
For the participant, the metadata lists the document types that may be sent, each within a named process or profile — an invoice under a billing profile is a different registration from an ordering document, and a receiver may hold one without the other. Against each entry sits the endpoint address, the transport profile that endpoint speaks, the certificate that identifies it, and the period during which the entry is active.
That last set is what the transport layer consumes. The sending access point uses the endpoint address and the certificate to establish a secured exchange with the receiving access point under the AS4 transport profile. Nothing in that exchange revisits the question of whether the receiver wanted the document; that question was answered by the metadata.
A postal address tells you where something goes. Peppol service metadata tells you where something goes and what will be accepted when it gets there. "We have their Peppol ID" answers the first question and says nothing about the second.
The chain, step by step
| Step | What is looked up | What answers | What the sender sees when it fails |
|---|---|---|---|
| Build the identifier | The scheme and value held in your own master data | Your system | Nothing leaves, or your own access point refuses a malformed pair |
| Locate the publisher | A domain name derived from the identifier | The Service Metadata Locator, over DNS | Recipient not found, usually immediately and usually accurate |
| Retrieve the metadata | The participant's service metadata document | The Service Metadata Publisher named by the previous step | The participant resolves but the metadata cannot be read or has expired |
| Match the capability | Whether your document type and process appear in that metadata | The metadata document itself | Refusal for an unsupported document type, before anything is transmitted |
| Take the endpoint and certificate | Endpoint address, transport profile, certificate, validity period | The matching metadata entry | A transport error: unreachable endpoint, or a certificate that does not check out |
| Hand over to the receiver's systems | Nothing — this is outside the network | The receiver's own processing | A successful receipt and no payment. The only failure with no signal at all |
The last row is the one worth sitting with. Every earlier step produces a machine-readable failure that somebody can be alerted to; the final step produces a delivery that succeeded technically and achieved nothing.
Registration, and who is actually doing it
Businesses do not usually register themselves. The publisher is operated by a service provider that has signed the network's agreements with a Peppol Authority, and it is that provider who publishes the metadata for its customers and registers them so the locator can find them. The customer's involvement is often limited to signing a contract and naming which identifier to use.
Three things follow that matter more than they sound.
Your customer frequently cannot tell you what they are registered for. Their provider can, and the metadata itself can, because it is published to be read.
Registration is a statement made by a provider about what it will accept, not a test that anything downstream passed. A provider can register a document type the receiver's finance system has never been configured for, and the registration will resolve perfectly.
An identifier is published through one publisher at a time. Adding a second provider is not an addition; it is a move, and until the move completes the network keeps pointing where it pointed before.
Where this breaks
A well-formed identifier in the wrong scheme. Somebody records a company registration number and labels it with the scheme their previous customer used. The pair is syntactically perfect. Most of the time it resolves to nothing. Occasionally the value is legitimately registered under that other scheme by an unrelated business and the lookup succeeds — at which point the failure has become a delivery to a stranger.
Registered for a document type nobody processes. The metadata lists a profile, the transport works, the receipt comes back. Behind the access point the file lands in a directory or a mailbox that was set up during a pilot and never wired into accounts payable. There is no error anywhere in the chain, because on the network's own terms nothing went wrong.
A migration that leaves the lookup behind. A receiver changes provider. The new publisher has the metadata, the old registration has not been withdrawn, and senders keep resolving to an endpoint the receiver no longer watches. This is the failure most likely to affect many suppliers at once, and the sender's own retry and escalation handling is the only thing that will surface it.
What an identifier is worth on its own
Not much, and that is a useful conclusion rather than a pessimistic one. An identifier is a question you can ask the network; the answer is the metadata, and the metadata is public. A sender that resolves a customer's address before the first invoice, and checks the document type it intends to send is listed there, has moved a whole class of failure from month-end to onboarding.
That check costs one lookup. Doing it habitually is the practical difference between a business that has a directory of Peppol IDs and one that has working addresses — and it is why the network's four-corner shape puts the capability statement in the middle of the road rather than at the end of it.
