Registering a Peppol participant means publishing, on a Service Metadata Publisher (SMP), what a company can receive (which document types, at which Access Point endpoint) and activating that record in the SML, the network’s DNS-based locator that maps a participant ID to its SMP. From that moment any sender’s Access Point can resolve the ID, discover the capabilities and deliver. A third, optional step lists the participant in the public Peppol Directory, which is how humans (and search tools) find Peppol-reachable companies. One asymmetry surprises most teams: sending requires no registration at all – any party with an Access Point can send; it is receiving that requires the SMP record.
Why can a participant live on only one SMP?
Because the SML is a resolver: one participant identifier resolves to exactly one SMP at a time, the way a domain resolves to one authoritative name server. A company can happily use several service providers for different things, but its receiving capability for a given Peppol ID lives with one provider. This is the design fact behind every “can we be on two Access Points?” question – for one ID, no; and it is why changing providers is a migration, not a parallel sign-up.
How does migration between Access Points work?
The shape is consistent across the network even where details differ per provider. The new provider prepares the participant’s registration on its SMP; the transfer is authorised – in practice this usually involves a migration key or consent step with the current SMP, since the network protects IDs from hostile takeovers; the SML entry is repointed to the new SMP; and the old registration is removed. From the network’s perspective the switch is atomic – senders resolving the ID simply start finding the new SMP. Plan for a short transition window and verify with a lookup rather than assuming: query the ID and confirm the new endpoint answers. Providers built for this, Finbite’s Peppol API included, expose registration and migration as API operations rather than support tickets, which matters when you manage participants for many users.
What should a platform automate?
Three lifecycle moments. Registration at user onboarding – create the participant, declare received document types, verify with a lookup. Monitoring: a participant whose SMP record disappears stops receiving silently, so check reachability on a schedule, not on complaint. And offboarding: deregister participants you no longer serve; a stale SMP record that points at a dead endpoint means senders’ invoices fail against your infrastructure. For the sending-side basics, start with how to send e-invoices via API.
What is the difference between SMP and SML in Peppol?
The SMP publishes a participant’s receiving capabilities (document types, Access Point endpoint); the SML is the DNS-based locator that maps a participant ID to its SMP. Senders resolve SML → SMP → deliver.
Can a company be registered on two Peppol Access Points?
Not for the same participant ID — the SML resolves one ID to one SMP at a time. Receiving capability lives with one provider; switching is a migration.
Do I need to register a participant to send Peppol invoices?
No. Sending requires only an Access Point. Registration on an SMP is required to receive documents.
How does Peppol Access Point migration work?
The new provider registers the participant on its SMP with authorisation (typically a migration key or consent), the SML repoints, the old record is removed. Verify with a participant lookup after the switch.