Purpose of the Peppol Directory
The Peppol Directory is the network’s public register for discovering who is on Peppol and which document profiles and versions they can receive. It exists to make counterparties findable (by name, country, endpoint/Participant ID, and capability) before any message is sent. It is a searchable catalogue, not the component that performs message delivery.
A crucial governance note: updating the Directory is performed by SMP providers and is not mandatory. Therefore, a company can be fully routable on Peppol and still not appear in the public Directory. This does not invalidate their Peppol status; it only means their SMP has not published a “business card” to the Directory.
Where the Directory fits in the delivery chain (Directory vs. SML/SMP vs. Access Points)
Peppol uses a “four-corner” model. The Directory supports human-readable discovery. Technical discovery and routing happen via SML/SMP and are executed by certified Access Points:
- Your Access Point identifies the receiver (ideally by Peppol Participant ID).
- It consults the Service Metadata Locator (SML), the global index, to find which Service Metadata Publisher (SMP) holds the receiver’s metadata.
- It asks that SMP for two things: the receiver’s capabilities (document types/profiles/versions) and the receiver endpoint.
- It then transmits the structured document to the receiver’s Access Point over the Peppol transport.
In short: the Directory helps you find parties; SML/SMP enable your provider to reach them. This separation is intentional and codified in Peppol’s eDelivery specifications.
Participant IDs: the Address the Network Routes On
Every organization on Peppol is addressed by a Peppol Participant Identifier (often called the Peppol Endpoint ID). The format is governed by the Peppol Policy for the use of Identifiers and associated code lists. These rules define scheme codes (e.g., ISO-based or Peppol-issued codes) and how national identifiers (such as VAT, business numbers, GLN, etc.) are embedded to ensure uniqueness and cross-border interoperability. Because many entities share similar names, routing relies on the Participant ID—not on names or free-text VAT entries.
For implementers and onboarding teams, this means the Participant ID must be stored in ERP/CRM master data alongside the commercial record. Independent explainers from service providers reflect the same design: the ID is the anchor for addressing and fraud-resistant, automated routing.
What the Directory Shows ‒ and Why it Matters
The Directory surfaces two types of information aggregated from SMPs:
a) Who the participant is – a Business Card view (name, country, optional additional identifiers, contacts, website, registration date, and other free-text). This is published by SMPs to make participants discoverable.
b) What the participant can receive – the participant’s capabilities (e.g., Peppol BIS Billing 3.0) and, in some cases, other document types supported in that jurisdiction. These capabilities come from the participant’s SMP record and are exposed for easy verification before you send.
Important clarification about formats
Peppol is an e-delivery framework for standardised, structured business documents (e.g., e-invoices in BIS 3.0 / PINT). Files like PDF or CSV can be included as attachments within the structured XML (Base64-encoded with a mimeCode and filename), but the XML remains the canonical payload for automation and validation.
Registration and Publication: from “Routable” to “Discoverable”
When an organisation is onboarded by its provider:
- The provider creates/maintains the participant’s SMP record (capabilities, endpoint, certificates, technical contacts).
- The provider registers the participant with the SML so that the sender side can dynamically locate the SMP for that participant and document type.
- Optionally, the provider publishes a Business Card to the Peppol Directory, making the participant searchable by name, country, ID and capability. Publication is recommended for transparency but is not required to be routable.
This explains why a legitimate receiver might not appear in public search: Directory visibility depends on SMP publication, while routing depends on SML/SMP being correctly maintained.
How to Use the Directory Effectively (and Avoid Mis-routing)
Use the Directory as a front-door check, then let SML/SMP do the heavy lifting.
- Look up and capture the counterparty’s Participant ID and capabilities in the Directory. The public site and its documentation describe search fields (including REST API parameters for automation).
- Store the Participant ID and capability profile in master data. Do not rely on names or unstructured VAT strings for addressing.
- Send via your Access Point. The AP will use SML → SMP discovery to resolve the current endpoint for the target document type and deliver. This guarantees you deliver the right profile to the right endpoint.
Practical Implementation Guidance for Onboarding and Change Management
- Data governance. Treat the Participant ID as a key field in customer/supplier masters; add the capability set (document profile + version) as attributes so your ERP selects the correct variant each time.
- Directory publication. If you want to be findable by name/capability, instruct your provider to publish your Business Card to the Directory and keep it current (contacts, website, additional identifiers).
- SMP accuracy. Ensure your SMP entry reflects endpoint URLs, certificates, service descriptions and technical contacts; these fields are defined in the SMP specification and support robust discovery and support processes.
- Attachments policy. If you must include PDF/CSV/images, ensure they are embedded as binary attachments with mimeCode and filename in the XML; never substitute attachments for the structured payload.
- Diagnostics. When a partner is not visible in the Directory but is expected to be live, ask their provider to confirm SML/SMP registration and, if desired, to publish to the Directory.
A Precise Analogy for Internal Non-technical Stakeholders
The Directory functions like a public phone book that lets you find organisations and see what “call types” they accept. Your provider, acting as your operator (Access Point), uses SML/SMP as the switchboard to resolve the right line and complete the call. This analogy mirrors the way service providers and OpenPeppol’s documentation describe the roles of Directory, SML, and SMP.
Helpful Sources
- OpenPeppol – Peppol Directory overview (search fields, non-mandatory publishing). OpenPeppol
- Peppol Directory docs (purpose, aggregation from SMPs). Peppol Directory
- EU eDelivery SML/SMP (dynamic discovery model). European Commission
- Peppol SML spec v1.3.0 (2025-02-06) (latest flow for participant metadata). docs.peppol.eu
- Peppol Policy for use of Identifiers (2025-02-06) + code lists (ID schemes). docs.peppol.eu+1
