The Service Metadata Publisher (SMP) is the address book of the Peppol network. When an Access Point (AP) sends a document, it uses the Participant Identifier of the recipient to find -- via the Service Metadata Locator (SML) and the Domain Name System (DNS) -- which SMP the recipient is registered with, which endpoint URL to call, and which document types are supported. This article describes the discovery chain step by step.

Peppol is an open network: there is no central mailbox that receives and distributes all documents. Instead, every certified Service Provider maintains its own SMP, containing the metadata of its customers -- which documents they can receive, via which AP, and with which certificates they sign. The sending AP must discover where to deliver the document before every submission, and uses the recipient's SMP for this.

The SMP specification is an Organization for the Advancement of Structured Information Standards (OASIS) standard. eConnect is listed on the European Commission's eDelivery SMP-compliant solutions list with its own implementation.

Every organisation on Peppol has at least one Participant Identifier, built from a scheme and a value:

iso6523-actorid-upis::<scheme>:<value>

The scheme is a code from the Electronic Address Scheme (EAS) code list -- an OpenPeppol register of national and international identifier systems. The most commonly used EAS codes:

A full overview is available at docs.peppol.eu/edelivery/codelists/ and in Peppol ID and identifiers.

The sending AP answers three questions for every document:

1. Where is the recipient's SMP? Lookup via SML / DNS NAPTR.
2. Which endpoint and certificate match the required document type? Lookup against the SMP itself.
3. Which Peppol profile does the recipient support? The answer is in the SMP response (BIS Billing V3, NLCIUS, PINT EU, etc.).

B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu

B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
   IN NAPTR 100 10 "U" "Meta:SMP" "!^.*$!https://smp.example.com/!" .

GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587

GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<DocumentTypeId>

The end-to-end illustration below shows how a Dutch Participant Identifier (KvK number) leads to a concrete endpoint URL:

1. Sender wants to send invoice to:
   iso6523-actorid-upis::0106:54441587  (eConnect, EAS 0106 -- KvK)

2. Sender AP performs DNS NAPTR lookup:
   B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
   --> SMP URL: https://smp.econnect.eu/

3. Sender AP queries SMP:
   GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587
   --> ServiceGroup including DocumentTypeId for NLCIUS invoice

4. Sender AP queries ServiceMetadata for NLCIUS:
   GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<NLCIUS-DocumentTypeId>
   --> EndpointURI: https://ap.econnect.eu/as4
   --> Certificate: <X.509 / PKI-cert>
   --> TransportProfile: peppol-transport-as4-v2_0

5. Sender AP builds SBDH with routing metadata,
   signs and sends via AS4 + TLS to the EndpointURI.

When registering in an SMP, capabilities per document family are configured per organisation:

Each capability has a value of on, off or inherited. The full set of capabilities determines which document types the sending AP can find in the SMP -- and therefore what a recipient is actually reachable for.

SMP lookups are performed on every submission. For scale and robustness, the eConnect SMP applies its own caching layer: lookups remain available -- even if an external SMP is temporarily unreachable -- by reusing cached metadata within the validity period. eConnect guarantees 99.99% uptime on the SMP.

Two similar-sounding terms that are often confused in practice:

• The SML (Service Metadata Locator) is the central DNS zone (edelivery.tech.ec.europa.eu for production) in which all Participant Identifiers are published, pointing to the correct SMP. There is one production SML and one test SML; OpenPeppol is taking over management from the European Commission (transition until end of August 2026).
• The SMP (Service Metadata Publisher) is the directory of an individual Service Provider. Every SP runs its own SMP for its own customers.

Think of it like DNS: the SML is the top-level phone book that refers to the right regional directory; the SMP is that directory with the actual details.

In addition to the machine-readable SMP, there are two public front-ends for manual lookups:

• Peppol Directory -- directory.peppol.eu: the public register of Peppol participants, with search by organisation name, country and Participant ID. Asynchronous: may lag behind the actual SMP status.
• Peppol Lookup Service -- lookup.peppol.org, since March 2026: queries the SMP directly and shows the current publication status. Useful for troubleshooting when the Directory and actual registration are out of sync.

For customers who want to programmatically check whether a recipient is reachable, the eConnect Peppol Service Bus (PSB) offers the queryRecipientParty endpoint that queries the SMP directly and indicates via which channel and format the recipient is reachable.

A Participant Identifier can only be registered with one SMP at a time -- otherwise C2 would not know where to send the document. When switching providers, a migration procedure with a migration key applies: the current SMP generates a key, and the new SMP uses it to take over the registration seamlessly. During the transition, the organisation remains reachable; the identifier does not change, so trading partners notice nothing. See Peppol registration for the procedure at eConnect.

A recipient can be findable on Peppol -- the NAPTR lookup and SMP query succeed -- and still be unable to receive invoices. The SMP publishes per document type a capability. Receiving invoices falls under invoices; returning a business status (BIS Invoice Response 3.0) falls under the separate capability invoiceResponse. These are independent registrations.

If a recipient is registered on their Peppol ID exclusively for Invoice Response transaction 3.0 (invoiceResponse on on, invoices on off), the sending AP finds no invoices endpoint in the SMP. There is then no valid delivery path for an invoice, and the eConnect platform reports No valid delivery options when sending. The recipient can send an Invoice Response via that identifier, but cannot receive an invoice on it.

Two solutions:

1. Alternative delivery point: ask the customer to contact the recipient and ask via which channel (email or supplier portal) the invoice can be delivered.
2. Different Peppol ID: check whether the recipient has a second Peppol ID on which the invoice document type (invoices) is registered. An organisation can register multiple identifiers with separate document type capabilities per identifier.

When in doubt, check which document types a recipient publishes via the Peppol Lookup Service or programmatically via queryRecipientParty.