Een Peppol-dienst inkopen: eisen voor de aanbesteding

Gaat uw organisatie een Peppol-dienst inkopen? Gebruik deze checklist met acht eisen voor de uitvraag, van certificering en SMP-exit tot SLA en datalocatie.

Terug naar Kennisbank

Wanneer een overheidsorganisatie een Peppol-dienst inkoopt, bepaalt de kwaliteit van de uitvraag grotendeels de kwaliteit van de dienst die u daarna jarenlang afneemt. Een Peppol Serviceprovider verzorgt de verbinding tussen uw financiële systeem en het Peppol-netwerk: het verzenden en ontvangen van e-facturen, de registratie van uw organisatie in het netwerk en vaak ook validatie en archivering. Omdat dit een kritieke schakel is in uw factuurstroom, loont het om vooraf scherp te formuleren wat u verwacht.

Deze pagina biedt een eisenkader in acht categorieën. Per categorie leest u waarom de eis ertoe doet en welke concrete vragen u in de uitvraag kunt opnemen. Onderaan vindt u alles samengevat als kopieerbare checklist. Het kader is bruikbaar ongeacht in welk land uw organisatie gevestigd is; nationale aanbestedingsregels en procedures vallen buiten de reikwijdte van deze pagina.

Wilt u eerst weten wat een Peppol Serviceprovider precies doet? Lees dan Wat is een Peppol Serviceprovider.

1. Certificering

Waarom dit een eis is. Alleen partijen die een overeenkomst hebben met OpenPeppol, via een Peppol-autoriteit, mogen als Peppol Serviceprovider berichten over het netwerk uitwisselen. Die toetreding gaat gepaard met technische tests en afspraken over beveiliging en dienstverlening. Een aanbieder die niet zelf gecertificeerd is, kan de dienst wel leveren via een gecertificeerde partij, maar dan wilt u weten wie die partij is en wie waarvoor verantwoordelijk is. Meer over de rol van de autoriteit leest u in Wat is een Peppol-autoriteit.

Vragen voor de uitvraag:

  • Is de aanbieder zelf een door OpenPeppol erkende Peppol Serviceprovider? Zo nee: via welke gecertificeerde onderaannemer wordt de dienst geleverd, en hoe is de verantwoordelijkheidsverdeling contractueel vastgelegd?
  • Bij welke Peppol-autoriteit is de aanbieder aangesloten?
  • Voor welke rol is de aanbieder erkend: de Access Point-rol (verzenden en ontvangen), de SMP-rol (registratie), of beide?
  • Hoe toont de aanbieder aan dat de erkenning geldig blijft gedurende de looptijd van het contract?
  • Hoe wordt u geïnformeerd als de erkenning wordt opgeschort of beëindigd?

2. Ondersteunde documenttypes

Waarom dit een eis is. Peppol is meer dan alleen de factuur. Het netwerk ondersteunt meerdere documenttypen en elk type heeft een eigen specificatie. Voor e-facturatie is Peppol BIS Billing 3.0 de gangbare specificatie: een CIUS op de Europese norm EN 16931. Daarnaast bestaan landspecifieke uitwerkingen. Als uw organisatie op termijn ook orders of catalogi elektronisch wil uitwisselen, is het verstandig dat direct mee te nemen in de uitvraag.

Vragen voor de uitvraag:

  • Ondersteunt de dienst het verzenden én ontvangen van e-facturen en creditnota’s volgens Peppol BIS Billing 3.0?
  • Welke nationale CIUS-varianten of extensies worden ondersteund?
  • Worden ook andere Peppol-documenttypen ondersteund, zoals orders, orderbevestigingen, verzendberichten, catalogi of Invoice Response?
  • Hoe gaat de aanbieder om met nieuwe versies van specificaties, en worden updates zonder meerkosten doorgevoerd?
  • Kan de dienst ontvangen documenten ook aanleveren in het formaat dat uw eigen financiële systeem verwacht (conversie)?

3. SMP-beheer en exitregeling

Waarom dit een eis is. Om berichten te kunnen ontvangen, moet uw organisatie met een Peppol ID geregistreerd staan in een Service Metadata Publisher (SMP). Die registratie vertelt verzenders via welke Peppol Serviceprovider en voor welke documenttypen u bereikbaar bent. De partij die de SMP-registratie beheert, heeft daarmee feitelijk de sleutel van uw bereikbaarheid in handen. Een goede exitregeling is de belangrijkste waarborg tegen leveranciersafhankelijkheid (vendor lock-in).

Vragen voor de uitvraag:

  • Wie beheert de SMP-registratie van uw Peppol ID’s, en welke Peppol ID’s en schema’s worden geregistreerd?
  • Blijft de Peppol ID aantoonbaar eigendom van uw organisatie?
  • Hoe verloopt de overdracht van de SMP-registratie naar een andere Peppol Serviceprovider bij beëindiging van het contract: welke stappen, doorlooptijd en medewerking?
  • Hoe wordt voorkomen dat er tijdens de overstap berichten verloren gaan of dubbel worden afgeleverd?
  • In welk formaat en binnen welke termijn krijgt u bij beëindiging al uw documenten en metadata terug?
  • Zijn aan de exit kosten verbonden, en zijn die vooraf vastgelegd?

4. Validatie

Waarom dit een eis is. Een e-factuur die technisch aankomt, is nog niet per se inhoudelijk correct. Validatie tegen de toepasselijke regels voorkomt dat onjuiste facturen uw verwerkingsproces binnenkomen of dat uw eigen facturen bij de ontvanger worden afgewezen. Even belangrijk is wat er gebeurt als een document niet door de validatie komt.

Vragen voor de uitvraag:

  • Worden uitgaande en inkomende documenten gevalideerd, en tegen welke regelsets?
  • Wat gebeurt er met een afgekeurd document: tegengehouden, doorgestuurd met een waarschuwing, of teruggemeld aan de afzender?
  • Hoe en via welk kanaal wordt u geïnformeerd over afgekeurde documenten, en is de foutmelding begrijpelijk?
  • Ondersteunt de dienst Invoice Response of vergelijkbare statusberichten?
  • Hoe snel worden gewijzigde validatieregels doorgevoerd?

5. SLA (Service Level Agreement)

Waarom dit een eis is. Facturen zijn direct gekoppeld aan betaaltermijnen en de relatie met uw leveranciers. Een storing bij uw Peppol Serviceprovider kan betekenen dat facturen niet aankomen of niet worden verzonden. Een SLA maakt afspraken over beschikbaarheid en ondersteuning toetsbaar.

Vragen voor de uitvraag:

  • Welke beschikbaarheid garandeert de aanbieder, en hoe wordt die gemeten en gerapporteerd?
  • Wat zijn de reactie- en oplostijden per prioriteitsniveau van een storing?
  • Op welke tijden en via welke kanalen is ondersteuning beschikbaar, en in welke talen?
  • Hoe ziet het escalatiepad eruit, en wie is uw vaste aanspreekpunt?
  • Hoe en hoe ver vooraf wordt gepland onderhoud aangekondigd?
  • Welke gevolgen heeft het niet halen van de SLA?
  • Is er een bedrijfscontinuïteitsplan dat periodiek wordt getest?

6. Archivering

Waarom dit een eis is. Overheidsorganisaties hebben vaak zowel fiscale als archiefwettelijke bewaarplichten. Het is belangrijk om vooraf vast te leggen of de Peppol Serviceprovider ontvangen en verzonden documenten bewaart, hoe lang, en wie verantwoordelijk is voor de raadpleegbaarheid tijdens de geldende bewaartermijn.

Vragen voor de uitvraag:

  • Bewaart de aanbieder verzonden en ontvangen documenten, inclusief de originele XML? Zo ja, hoe lang?
  • Kan de bewaartermijn worden afgestemd op de bewaarplicht die voor uw organisatie geldt?
  • Hoe zijn integriteit en onveranderlijkheid van gearchiveerde documenten gewaarborgd?
  • Hoe kunt u gearchiveerde documenten doorzoeken, raadplegen en exporteren, ook na beëindiging van het contract?
  • Hoe en wanneer worden documenten na afloop van de bewaartermijn verwijderd?
  • Wie is verantwoordelijk voor de archivering: de aanbieder, uw organisatie, of een gedeelde verantwoordelijkheid?

7. API en koppelingen

Waarom dit een eis is. De waarde van e-facturatie zit in de automatische verwerking. Dat vraagt om een betrouwbare koppeling tussen de Peppol-dienst en uw financiële systeem of ERP. Kwaliteit en documentatie van de API bepalen hoeveel inspanning de implementatie kost.

Vragen voor de uitvraag:

  • Welke koppelmogelijkheden biedt de dienst (REST-API, standaardkoppelingen, bestandsuitwisseling)?
  • Is de API-documentatie openbaar of vooraf in te zien?
  • Is er een sandbox waarin u de koppeling kunt testen zonder productiegegevens?
  • Ondersteunt de dienst webhooks voor statuswijzigingen?
  • Hoe wordt u geïnformeerd over wijzigingen in de API, en hoe lang blijven oudere versies ondersteund?
  • Welke ondersteuning biedt de aanbieder tijdens de implementatie?

8. Informatiebeveiliging en datalocatie

Waarom dit een eis is. Facturen bevatten bedrijfs- en soms persoonsgegevens. Overheidsorganisaties werken vaak met een eigen beveiligingsbeleid en eisen aan de jurisdictie waarin gegevens worden opgeslagen. Die eisen gelden ook voor uw Peppol Serviceprovider en eventuele onderaannemers.

Vragen voor de uitvraag:

  • Hoe worden gegevens versleuteld tijdens transport en in opslag?
  • Hoe is toegangsbeheer ingericht?
  • In welke regio en onder welke jurisdictie worden gegevens opgeslagen en verwerkt?
  • Welke onderaannemers zijn betrokken, en hoe wordt u geïnformeerd over wijzigingen daarin?
  • Over welke aantoonbare certificeringen of audits beschikt de aanbieder?
  • Is de aanbieder bereid een verwerkersovereenkomst te sluiten?
  • Hoe en binnen welke termijn worden beveiligingsincidenten gemeld?
  • Mag uw organisatie audits uitvoeren of auditrapporten inzien?

Wat dit betekent voor u

Als overheidsorganisatie koopt u met een Peppol-dienst geen losse software, maar een schakel in uw financiële kernproces en in uw bereikbaarheid voor leveranciers. Deze eisen zijn achteraf lastig te herstellen.

Kopieerbare checklist voor uw uitvraag

Neem deze punten letterlijk over in uw uitvraag.
  • ✓ Certificering: de aanbieder is een door OpenPeppol erkende Peppol Serviceprovider (of werkt via een gecertificeerde onderaannemer), met Peppol-autoriteit, erkende rol(len) en aantoonbare geldigheid gedurende de contractduur
  • ✓ Documenttypes: verzenden en ontvangen volgens Peppol BIS Billing 3.0, relevante nationale CIUS-varianten en eventueel orders, catalogi en statusberichten
  • ✓ SMP-beheer en exit: Peppol ID blijft eigendom van de organisatie; overdracht met vastgelegde stappen, doorlooptijd, kosten en teruglevering van documenten
  • ✓ Validatie: uitgaande en inkomende documenten worden gevalideerd tegen EN 16931, Peppol BIS en toepasselijke CIUS; afgekeurde documenten worden aantoonbaar afgehandeld
  • ✓ SLA: gegarandeerde en gerapporteerde beschikbaarheid, reactie- en oplostijden, ondersteuningskanalen, escalatiepad
  • ✓ Archivering: bewaring inclusief originele XML, bewaartermijn afgestemd op de geldende bewaarplicht, integriteitswaarborgen en export
  • ✓ API en koppelingen: gedocumenteerde API, sandbox, webhooks of statusmeldingen, versiebeleid en implementatieondersteuning
  • ✓ Informatiebeveiliging en datalocatie: versleuteling, toegangsbeheer, opslag binnen de vereiste jurisdictie, subverwerkers, certificeringen, verwerkersovereenkomst en incidentmelding
Vergelijk aanbieders op deze eisen in de Peppol-vergelijker

Tot slot

Een goede uitvraag voor een Peppol-dienst draait om meer dan de vraag of een aanbieder facturen kan verzenden. Certificering, eigenaarschap van uw registratie, een werkbare exitregeling, validatie, dienstverleningsafspraken, archivering, koppelmogelijkheden en informatiebeveiliging bepalen samen of de dienst jarenlang betrouwbaar blijft en of u later zonder problemen kunt overstappen.

Voor de bredere context van e-facturatie in de publieke sector leest u E-facturatie voor overheden. Wie de marktoriëntatie wil voorbereiden, kan de beschikbare Peppol Serviceproviders naast elkaar zetten op precies de punten uit deze checklist in de vergelijker op peppol.nu.

Klaar om aanbieders te vergelijken?

Vergelijk Peppol Serviceproviders op precies deze eisen.

Peppol.nu - Jouw gids in de wereld van elektronische facturatie