When your organisation procures a Peppol service, through a tender or a request to several providers, the quality of the request largely determines the quality of the service you then use for years. A service provider handles the connection between your financial system and the Peppol network: sending and receiving e-invoices, registering your organisation in the network and often validation and archiving as well. Because this is a critical link in your invoice flow, it pays to define your expectations precisely in advance.
This page offers a requirements framework in eight categories. For each category, you can read why the requirement matters and which specific questions you can include in your request. At the bottom, you will find everything summarised as a checklist you can copy. The framework can be used regardless of the country in which your organisation is established; national procurement rules and procedures are outside the scope of this page. The route through which public sector bodies receive e-invoices does differ per country: in the Netherlands, Belgium and Luxembourg via Peppol, among other channels, in Germany with XRechnung via the federal government portals, and in France via Chorus Pro. See E-invoicing for public sector bodies.
Would you first like to know exactly what a service provider does? Then read What is a Peppol service provider?
1. Certification
Why this is a requirement. Only parties that have an agreement with OpenPeppol, through a Peppol Authority, may exchange messages over the network as a service provider. This accession involves technical tests and agreements on security and service delivery. A provider that is not certified itself can still deliver the service through a certified party, but then you want to know who that party is and who is responsible for what. You can read more about the role of the authority in What is a Peppol Authority?
Questions for the request:
- Is the provider itself a service provider accredited by OpenPeppol? If not, through which certified subcontractor is the service delivered, and how is the division of responsibilities set out in the contract?
- With which Peppol Authority is the provider affiliated?
- For which role is the provider accredited: the Access Point role (sending and receiving), the SMP role (registration), or both?
- How does the provider demonstrate that the accreditation remains valid throughout the term of the contract?
- How will you be informed if the accreditation is suspended or terminated?
2. Supported document types
Why this is a requirement. Peppol is more than just the invoice. The network supports multiple document types and each type has its own specification. For e-invoicing, Peppol BIS Billing 3.0 is the common specification: a CIUS of the European standard EN 16931. In addition, there are country-specific implementations. If your organisation also wants to exchange orders or catalogues electronically in the future, it is wise to include this in the request right away.
Questions for the request:
- Does the service support both sending and receiving e-invoices and credit notes in accordance with Peppol BIS Billing 3.0?
- Which national CIUS variants or extensions are supported?
- Are other Peppol document types also supported, such as orders, order confirmations, despatch advices, catalogues or Invoice Response?
- How does the provider handle new versions of specifications, and are updates implemented at no extra cost?
- Can the service also deliver received documents in the format your own financial system expects (conversion)?
3. SMP management and exit arrangement
Why this is a requirement. To be able to receive messages, your organisation must be registered with a Peppol ID in a Service Metadata Publisher (SMP). That registration tells senders through which service provider and for which document types you can be reached. The party that manages the SMP registration therefore effectively holds the key to your reachability. A good exit arrangement is the most important safeguard against vendor lock-in.
Questions for the request:
- Who manages the SMP registration of your Peppol IDs, and which Peppol IDs and schemes are registered?
- Does the Peppol ID demonstrably remain the property of your organisation?
- How does the transfer of the SMP registration to another service provider work when the contract ends: which steps, lead time and cooperation?
- How is it prevented that messages are lost or delivered twice during the switch?
- In which format and within what period will you get all your documents and metadata back on termination?
- Are there costs associated with the exit, and are they fixed in advance?
- Under which identification number will you be registered? Dutch public sector bodies are registered under their OIN (government organisation identification number).
- In the Netherlands, the old service provider must transfer or end the registration within three working days: does the provider set this out in the contract?
4. Validation
Why this is a requirement. An e-invoice that arrives technically is not necessarily correct in terms of content. Validation against the applicable rules prevents incorrect invoices from entering your processing workflow, or your own invoices from being rejected by the recipient. Equally important is what happens when a document fails validation.
Questions for the request:
- Are outgoing and incoming documents validated, and against which rule sets?
- What happens to a rejected document: is it held back, forwarded with a warning, or reported back to the sender?
- How and through which channel are you informed about rejected documents, and is the error message understandable?
- Does the service support Invoice Response or comparable status messages?
- How quickly are changed validation rules implemented?
5. SLA (Service Level Agreement)
Why this is a requirement. Invoices are directly linked to payment terms and your relationship with your suppliers. An outage at your service provider can mean that invoices do not arrive or are not sent. An SLA makes agreements on availability and support verifiable.
Questions for the request:
- What availability does the provider guarantee, and how is it measured and reported?
- What are the response and resolution times per incident priority level?
- At what times and through which channels is support available, and in which languages?
- What does the escalation path look like, and who is your dedicated point of contact?
- How, and how far in advance, is planned maintenance announced?
- What are the consequences of failing to meet the SLA?
- Is there a business continuity plan that is tested periodically?
6. Archiving
Why this is a requirement. Public sector organisations often have both tax and archival retention obligations. It is important to establish in advance whether the service provider retains received and sent documents, for how long, and who is responsible for their accessibility during the applicable retention period.
Questions for the request:
- Does the provider retain sent and received documents, including the original XML? If so, for how long?
- Can the retention period be aligned with the retention obligation that applies to your organisation?
- How are the integrity and immutability of archived documents safeguarded?
- How can you search, consult and export archived documents, including after the contract ends?
- How and when are documents deleted at the end of the retention period?
- Who is responsible for archiving: the provider, your organisation, or is it a shared responsibility?
7. API and connections
Why this is a requirement. The value of e-invoicing lies in automatic processing. That requires a reliable connection between the Peppol service and your financial system or ERP. The quality and documentation of the API determine how much effort the implementation takes.
Questions for the request:
- Which connection options does the service offer (REST API, standard connectors, file exchange)?
- Is the API documentation public or available for review in advance?
- Is there a sandbox in which you can test the connection without production data?
- Does the service support webhooks for status changes?
- How are you informed about changes to the API, and for how long are older versions supported?
- What support does the provider offer during implementation?
8. Information security and data location
Why this is a requirement. Invoices contain business data and sometimes personal data. Public sector organisations often work with their own security policy and requirements regarding the jurisdiction in which data is stored. Those requirements also apply to your service provider and any subcontractors.
Questions for the request:
- How is data encrypted in transit and at rest?
- How is access management organised?
- In which region and under which jurisdiction is data stored and processed?
- Which subcontractors are involved, and how are you informed about changes to them?
- Which verifiable certifications or audits does the provider have?
- Is the provider willing to enter into a data processing agreement?
- How and within what period are security incidents reported?
- May your organisation carry out audits or inspect audit reports?
- Does the provider hold ISO 27001 or an equivalent certification? In the Netherlands, the Peppol Authority requires this of service providers.
What this means for you
As an organisation, with a Peppol service you are not buying stand-alone software, but a link in your core financial process and in your reachability for suppliers. These requirements are difficult to fix afterwards.
Checklist to copy into your request. Include these points verbatim in your request:
- Certification: the provider is a service provider accredited by OpenPeppol (or works through a certified subcontractor), with Peppol Authority, accredited role(s) and demonstrable validity throughout the contract term
- Document types: sending and receiving in accordance with Peppol BIS Billing 3.0, relevant national CIUS variants and, where applicable, orders, catalogues and status messages
- SMP management and exit: the Peppol ID remains the property of the organisation; transfer with defined steps, lead time, costs and return of documents; registration under the correct identification number (the OIN for Dutch public sector bodies); in the Netherlands, transfer within three working days
- Validation: outgoing and incoming documents are validated against EN 16931, Peppol BIS and the applicable CIUS; rejected documents are demonstrably handled
- SLA: guaranteed and reported availability, response and resolution times, support channels, escalation path
- Archiving: retention including the original XML, retention period aligned with the applicable retention obligation, integrity safeguards and export
- API and connections: documented API, sandbox, webhooks or status notifications, versioning policy and implementation support
- Information security and data location: encryption, access management, storage within the required jurisdiction, sub-processors, certifications, data processing agreement and incident reporting, ISO 27001 or an equivalent certification
Find suitable providers in the comparison tool and present this checklist to them.
In conclusion
A good request for a Peppol service is about more than whether a provider can send invoices. Certification, ownership of your registration, a workable exit arrangement, validation, service level agreements, archiving, connection options and information security together determine whether the service remains reliable for years and whether you can switch later without problems.
For the broader context of e-invoicing in the public sector, read E-invoicing for public sector bodies. In the comparison tool on Peppol.now, you will find providers that suit your situation; you then present the checklist to them.
