The Service Metadata Locator (SML) and Service Metadata Publisher (SMP) enable a sending Peppol Access Point to discover how a recipient can receive a specific business document. The SML identifies which SMP holds the recipient’s metadata. The SMP then returns the recipient’s supported document types, processes and technical endpoint information. This dynamic lookup removes the need for each sender and receiver to configure a direct connection in advance.
| Component | Current specification | Function |
| SML | Peppol SML 1.3.0, valid from 1 November 2025 | Locates the SMP associated with a participant identifier through DNS |
| SMP | Peppol SMP 1.4.0, valid from 1 November 2025 | Publishes participant capabilities and delivery endpoint metadata |
| Identifier policy | Peppol Policy for use of Identifiers 4.4.0 | Defines how participant identifiers are represented and resolved |
The difference between SMP and SML
| SML | SMP | |
| Full name | Service Metadata Locator | Service Metadata Publisher |
| Main question | Which SMP holds metadata for this participant? | Can this participant receive this document and process, and where should it be sent? |
| Lookup method | DNS U-NAPTR | HTTPS REST request |
| Stores document capabilities | Nein | Ja |
| Stores the delivery endpoint and certificate | Nein | Ja |
The SML is a locator. It does not contain the recipient’s complete service configuration. Each participant identifier is registered with one SMP, and that SMP publishes the detailed metadata used for delivery.
How the discovery process works
- The sending Access Point receives the recipient’s Peppol participant identifier, for example
0088:7300010000001. - It converts the participant identifier into the DNS name defined by the Peppol identifier policy.
- A DNS U-NAPTR lookup returns the base URL of the SMP associated with that participant.
- The sending Access Point queries the SMP for the recipient and the exact document type it intends to send.
- The SMP response identifies the supported process, transport profile, delivery endpoint and certificate.
- The sending Access Point uses this metadata to create the AS4 connection and transmit the message.
Business users do not normally perform these requests themselves. The sending Peppol Service Provider completes the lookup before transmission.
How a participant identifier becomes a DNS lookup
The DNS name is derived from the participant identifier rather than exposing the identifier directly. The identifier is converted to lowercase, hashed with SHA-256 and encoded with Base32 without padding. The participant meta scheme and the SML zone are then appended.
Conceptual form:
BASE32(SHA-256(lowercase("0088:7300010000001")))
.iso6523-actorid-upis
.<SML-zone>Case normalization happens before hashing because Peppol participant identifier values are treated as case insensitive. A sender that hashes a differently normalized value will query the wrong DNS name.
What an SMP publishes
An SMP organizes metadata by participant, document type and process. A service record can include:
- the participant identifier;
- the document type identifier;
- one or more supported process identifiers;
- the transport profile;
- the receiving Access Point endpoint address;
- the certificate used for secure transport;
- service activation and expiration dates; and
- technical contact or service information where provided.
The sending Access Point requests metadata for a specific document type. A participant can therefore be registered in Peppol and receive invoices while having no published capability for orders or another invoice profile.
The conceptual SMP resource path is:
{smp-base-url}/{participant-identifier}/services/{document-type-identifier}The participant and document identifiers must be represented and percent-encoded as required by the SMP REST specification. An unencoded example should not be copied directly into an implementation.
Registration and capability are separate checks
An SML record confirms that a participant identifier is associated with an SMP. It does not confirm that the participant accepts every Peppol document. The SMP capability record determines whether the requested combination of document type and process is supported.
This distinction explains why a recipient may be found by Peppol ID but still reject a particular message. The participant may support BIS Billing invoices but not credit notes, orders or the process identifier used by the sender. The sending Access Point must query the exact combination before transmission.
SMP and SML are not the Peppol Directory
The Peppol Directory is an optional, human-searchable service built from business-card data published by participating SMPs. It helps users find organizations, Peppol IDs and published document capabilities. It is not the routing registry used by Access Points.
Use Qvalia’s Peppol ID search to check information available through the directory. An Access Point still uses the SML and SMP discovery flow to determine the technical route for an actual message.
Common discovery and routing failures
| Symptom | Likely cause |
| No DNS result for the participant | The participant identifier is wrong, uses the wrong scheme or is not registered in the SML |
| SMP is found but the service record returns no match | The recipient has not published support for that document type |
| Document type is found but the process is missing | The requested process identifier is not registered for that document |
| Endpoint is found but AS4 delivery fails | The endpoint, certificate, transport profile or receiving service requires investigation |
| A recent provider change is not reflected immediately | Cached DNS or service metadata may still contain the previous route |
Check the participant scheme and value first, followed by the document type and process identifiers. Treat a Peppol Directory search as a useful user-facing check, while treating current SMP metadata as the technical source for delivery.
Who maintains the metadata
The recipient’s Peppol Service Provider registers the participant identifier, maintains the SML association and publishes the participant’s capabilities in its SMP. When a participant changes provider, the SML association must point to the new SMP and the required capabilities must be published there.
The sending Access Point performs discovery and uses the returned endpoint information for transport. Companies using Peppol normally manage their identifiers and receiving capabilities through their provider rather than operating the SML or querying SMP records manually. Read more about how a Peppol Access Point handles discovery, validation and transport.
Related guidance
Normative sources
Peppol SML 1.3.0, Peppol SMP 1.4.0 and Policy for use of Identifiers 4.4.0, OpenPeppol.