Procuring a Peppol service: tender requirements

Is your organisation procuring a Peppol service? Use this checklist of eight tender requirements, from certification and SMP exit to SLA and data location.

Back to Knowledge Base

When a public sector organisation procures a Peppol service, the quality of the tender largely determines the quality of the service it will rely on for years. A Peppol Service Provider connects your financial system to 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 state your expectations precisely from the outset.

This page offers a requirements framework in eight categories. For each category you will find why the requirement matters and which concrete questions to include in your tender. At the bottom, everything is summarised as a copyable checklist. The framework applies regardless of the country your organisation is based in; national procurement rules and procedures are outside the scope of this page.

Want to know first what a Peppol Service Provider actually does? 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 Peppol Service Provider. Joining involves technical testing and commitments on security and service delivery. A supplier that is not certified itself can still deliver the service through a certified party, but you will then want to know who that party is and who is responsible for what. Read more about the role of the authority in What is a Peppol Authority.

Questions for your tender:

  • Is the supplier itself a Peppol Service Provider recognised by OpenPeppol? If not, through which certified subcontractor is the service delivered, and how is the division of responsibilities set out in the contract?
  • Which Peppol Authority is the supplier affiliated with?
  • For which role is the supplier recognised: the Access Point role, the SMP role, or both?
  • How does the supplier demonstrate that its recognition remains valid throughout the contract term?
  • How will you be informed if the recognition is suspended or terminated?

2. Supported document types

Why this is a requirement. Peppol covers more than the invoice. The network supports multiple document types, each with its own specification. For e-invoicing, Peppol BIS Billing 3.0 is the common specification: a CIUS based on the European standard EN 16931. National specifications also exist. If your organisation may also want to exchange orders or catalogues electronically, it is sensible to include this in the tender from the start.

Questions for your tender:

  • Does the service support sending and receiving e-invoices and credit notes in line with Peppol BIS Billing 3.0?
  • Which national CIUS variants or extensions are supported?
  • Are other Peppol document types supported, such as orders, order responses, despatch advices, catalogues or Invoice Response?
  • How does the supplier handle new versions of specifications, and are updates implemented at no extra cost?
  • Can the service deliver received documents in the format your own financial system expects (conversion)?

3. SMP management and exit arrangement

Why this is a requirement. To receive messages, your organisation must be registered with a Peppol ID in a Service Metadata Publisher (SMP). This registration tells senders through which Peppol Service Provider, and for which document types, you can be reached. Whoever manages the SMP registration effectively holds the key to your reachability. A sound exit arrangement is the most important safeguard against vendor lock-in.

Questions for your tender:

  • Who manages the SMP registration of your Peppol ID(s), and which Peppol IDs and schemes are registered?
  • Does the Peppol ID demonstrably remain the property of your organisation?
  • How is the SMP registration transferred to another Peppol Service Provider when the contract ends: which steps, lead time and cooperation?
  • How is it ensured that no messages are lost or delivered twice during the switch?
  • In what format and within what period will you receive all documents and metadata on termination?
  • Are there costs attached to exit, and are they fixed in advance?

4. Validation

Why this is a requirement. An e-invoice that arrives technically is not necessarily correct in content. Validation against the applicable rules prevents incorrect invoices from entering your processing workflow and prevents your own invoices from being rejected by the recipient. Just as important is what happens when a document fails validation.

Questions for your tender:

  • Are outgoing and incoming documents validated, and against which rule sets?
  • What happens to a rejected document: 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 similar status messages?
  • How quickly are changes to validation rules implemented?

5. SLA (Service Level Agreement)

Why this is a requirement. Invoices are directly linked to payment terms and your relationship with suppliers. An outage at your Peppol Service Provider can mean invoices are not received or not sent. An SLA makes commitments on availability and support verifiable.

Questions for your tender:

  • What availability does the supplier guarantee, and how is it measured and reported?
  • What are the response and resolution times per incident priority level?
  • During which hours and through which channels is support available, and in which languages?
  • What does the escalation path look like, and who is your dedicated 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 public records retention obligations. It is important to agree in advance whether the Peppol Service Provider stores received and sent documents, for how long, and who is responsible for keeping them accessible during the applicable retention period.

Questions for your tender:

  • Does the supplier store 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 guaranteed?
  • How can you search, view and export archived documents, including after the contract ends?
  • How and when are documents deleted after the retention period?
  • Who is responsible for archiving: the supplier, your organisation, or a shared responsibility?

7. API and integrations

Why this is a requirement. The value of e-invoicing lies in automated processing. That requires a reliable integration between the Peppol service and your financial system or ERP. The quality and documentation of the API determine how much effort implementation takes.

Questions for your tender:

  • Which integration options does the service offer (a 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 integration without production data?
  • Does the service support webhooks for status changes?
  • How are you informed about API changes, and how long are older versions supported?
  • What support does the supplier provide 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 on the jurisdiction in which data is stored. These requirements also apply to your Peppol Service Provider and any subcontractors.

Questions for your tender:

  • 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 of changes?
  • Which demonstrable certifications or audits does the supplier hold?
  • Is the supplier willing to sign a data processing agreement?
  • How, and within what period, are security incidents reported?
  • May your organisation carry out audits or review audit reports?

What this means for you

As a public sector organisation, procuring a Peppol service means buying not a standalone piece of software but a link in your core financial process and in your reachability for suppliers. These requirements are difficult to fix afterwards.

Copyable checklist for your tender

Copy these points directly into your tender.
  • ✓ Certification: the supplier is a Peppol Service Provider recognised by OpenPeppol (or works through a certified subcontractor), stating its Peppol Authority, recognised role(s) and demonstrable validity throughout the contract term
  • ✓ Document types: sending and receiving in line with Peppol BIS Billing 3.0, relevant national CIUS variants and where needed 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 all documents
  • ✓ Validation: outgoing and incoming documents are validated against EN 16931, Peppol BIS and 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 obligation, integrity safeguards and export
  • ✓ API and integrations: 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
Compare providers on these requirements in the Peppol comparison tool

In conclusion

A good tender for a Peppol service is about more than whether a supplier can send invoices. Certification, ownership of your registration, a workable exit arrangement, validation, service level agreements, archiving, integration options and information security together determine whether the service remains reliable for years and whether you can later switch without problems.

For the broader context of e-invoicing in the public sector, see E-invoicing for public sector bodies. If you want to prepare your market consultation, you can line up the available Peppol Service Providers on exactly the points in this checklist in the comparison tool on peppol.nu.

Ready to compare suppliers?

Compare Peppol Service Providers on exactly these requirements.

Peppol.nu - Your guide in the world of electronic invoicing