If you spend any time around Peppol implementation work, two technical terms appear quickly: SMP and SML. They matter because they help the network determine where a participant is published and which document capabilities that participant can receive.

The names sound infrastructure-heavy, but the practical question is straightforward: when you have a participant ID, how do you find the right receiving information?

What SML means

SML stands for Service Metadata Locator. Its job is to help locate where metadata for a participant is published.

In practical terms, the SML helps answer:

  • which metadata service is responsible for this participant
  • where the next lookup step should go

It is a locating layer, not the place where teams usually read the detailed receiving setup itself.

What SMP means

SMP stands for Service Metadata Publisher. This is where the participant’s receiving capabilities are published.

That metadata can include things like:

  • which participant ID is registered
  • which document types the participant can receive
  • which processes are supported
  • which technical endpoint is used for delivery

This is why the SMP matters during onboarding and receiver lookup. If the metadata is wrong or missing, the integration may fail even when the document itself looks fine.

How the lookup flow works

A simplified Peppol lookup flow looks like this:

  1. start with the participant ID
  2. use the SML to determine which SMP handles that participant
  3. read the participant’s metadata from the SMP
  4. use that metadata to route the document correctly

That lookup step is part of why participant IDs and receiving capabilities need to be accurate long before broad rollout.

How this relates to the Peppol Directory

Teams sometimes expect the Peppol Directory to answer every lookup question. In practice, it is better to think of the Directory as a discovery tool and SMP plus SML as the underlying publication and lookup model that makes routing possible.

That is why:

  • directory search is useful during onboarding and research
  • exact participant publication checks matter more before live sending
  • support teams need to know which layer they are actually investigating

Why business teams should still care

SMP and SML are technical components, but they create practical consequences for product and operations teams:

  • onboarding can stall if participant publication is incomplete
  • support cases become harder if receiver lookup is opaque
  • multi-customer rollout gets slower if teams do not understand capability publication
  • troubleshooting becomes noisy when the wrong problem is blamed on the document payload

This is one reason strong Peppol providers do more than offer raw transport. They also help teams work with the lookup and publication model behind it.

A practical takeaway

SML helps you find the right metadata location. SMP holds the participant’s published receiving details. Together, they are a key part of how Peppol routes documents to the right place.

If you want the surrounding pieces next, read What Is the Peppol Directory? , How to check if a company is on Peppol , What Is a Peppol participant ID? , and How to choose a Peppol provider .