End users do not send or receive documents directly via Peppol. They always do so through a certified Service Provider that handles the technology, the governance and the validation. What does that role cover in practice, and what does it leave out?
Schedule a meeting
A Peppol Service Provider (SP, also called a Peppol provider or Access Point provider) fills four roles at once. It is an Access Point (sends and receives documents via AS4 and validates against EN 16931, BIS Billing and CIUS rules), it is an SMP (publishes in the Peppol directory which document types your organization can receive), it is an onboarding partner (registers new participants with the right identifier and handles migration), and it is a compliance and support layer (keeps the connection up to date with changing standards and answers network questions). The end user does not need to know any of that infrastructure.
Whether an invoice is correct in amount, VAT calculation or contract is the responsibility of the sender and recipient themselves, possibly through their own workflow or approval process.
The receiving organization approves itself through its own P2P or AP system. The SP transports and validates technically.
The fiscal retention duty sits with the end user. An SP can offer archiving as an additional service, but that is not part of the SP role itself.
You file returns and fiscal reporting yourself, possibly via your accountant or via an additional CTC or DRR service from the SP.
Confusion about the role almost always comes from this side. An SP is not an invoice platform, not an accounting party and not a legal intermediary.
The illustration shows the Peppol 4-corner model: sender (corner 1), the sender's Access Point (corner 2), the recipient's Access Point (corner 3) and recipient (corner 4). Each Service Provider connects its own customer's corner to the network of all other APs. Sender and recipient do not have to use the same SP; that is what makes Peppol an open network. The APs trust each other's certificates, respect each other's validation rules and return status messages. End users notice no difference between one and two SPs along the way.
A formal agreement with OpenPeppol via the national Peppol Authority. In the Netherlands that is the NPa (Dutch Peppol Authority).
Valid PKI certificates from OpenPeppol for the AP and, where applicable, for the SMP. Periodic rollovers are the SP's responsibility.
Complete technical tests that show the AS4 endpoint, the SMP and the validation chain work correctly according to the current specifications.
ISO 27001 certification, ISAE 3402 reporting, transparency requirements around migration and SLAs, and demonstrable onboarding and support processes.
An SP is not a party that may call itself that. The steps to become a Service Provider:
For an organization that wants to use Peppol, the SP role mainly means you only need to choose one party that handles the full technical, legal and operational picture. With one connection you are reachable by, and can send to, all participants in the worldwide Peppol network. No vendor lock-in: the Peppol address is yours, not the SP's. When you switch, the address stays the same; only the routing behind the scenes changes. The compliance pressure of changing standards sits with the SP, not with you. And liability is clearly divided: the SP is responsible for transport and technical validation, the end user for the content and the fiscal and commercial consequences.
Years operational as a certified AP, uptime achieved, and governance involvement with OpenPeppol or the national Peppol Authority.
Does the provider have its own OASIS-compliant SMP, or does it depend on a third party's SMP? An own SMP means own control over registrations and migrations.
Invoices only, or also orders, status messages, MLS and e-procurement flows? That determines whether you will have to switch later to expand.
Does the SP also cover DBNAlliance, local clearance platforms and large procurement networks alongside Peppol? For international organizations that is decisive. Read Hybrid solutions.
Per document, or does every technical message (status, MLS, evidence) count as a separate transaction? See the Peppol pricing page for the eConnect model.
An SP that actively contributes to BIS versions, PINT profiles and governance sees changes earlier and can prepare its customers better.
All certified APs can do the same thing technically, but they differ in reliability, coverage, integrations, pricing model and involvement in the standard. For a quick assessment, look at least at:
eConnect is the first certified Peppol Access Point in the Netherlands (2013) and was co-founder of SimplerInvoicing, the Dutch e-invoicing network that has since grown into the Dutch Peppol Authority (NPa). eConnect is also an active participant in OpenPeppol working groups. We operate our own OASIS-compliant SMP, run on several redundant APs and are the provider of the Dutch central government Access Point on Peppol via Digipoort/Logius. Each year eConnect processes more than 12 million documents.
In practice the terms are often used interchangeably. Strictly speaking, the Access Point (AP) is one of the technical components a Service Provider provides; the SP also has an SMP, an onboarding role and an operational/compliance layer. Anyone who says "Access Point provider" actually means the Service Provider. Anyone who says "Access Point" may mean either the party or only the AS4 endpoint.
No. The Peppol address belongs to your organization, not to the SP. When you switch you keep the same Peppol address and your organization stays reachable without interruption for all participants in the network. The migration key needed to switch is standardized by OpenPeppol; no SP may stop you from switching.
An SP must at least support the mandatory document types prescribed by OpenPeppol and the relevant Peppol Authority (BIS Billing, MLS, and the current PINT profiles where applicable). On top of that, an SP can choose to support additional document types, such as e-orders, despatch advice, Invoice Response Messages and sector-specific profiles. A broad document offering is a distinguishing criterion between SPs.
Liability in Peppol is arranged via the Service Provider Agreement with OpenPeppol and the SLA between the end user and their SP. The SP is responsible for the correctness of transport (AS4 delivery, validation, evidence) and the availability of the AP and SMP. The end user remains responsible for the content of the document and for the fiscal and commercial consequences. In the case of a transport error, the SP can show via Message Level Status and Invoice Response Messages at what moment the document was delivered.
Every certified SP is listed in the OpenPeppol Service Provider register. The national Peppol Authority (in the Netherlands: NPa) also publishes a list of accredited SPs. An SP that is not in both registers may not call itself a Peppol Service Provider.
Schedule a meeting for an open conversation about what an SP does, what sets eConnect apart and which connection fits your organization.
Schedule a meeting
Compare Access Points