Wie Peppol wil inbouwen in een ERP-systeem, boekhoudpakket of eigen softwareproduct, staat voor twee keuzes. De eerste is architectonisch: hoe verbindt uw software zich met het Peppol-netwerk? De tweede is praktisch: aan welke eisen moet de API van een Peppol Serviceprovider voldoen om die verbinding betrouwbaar en schaalbaar te maken? Deze pagina zet de drie gangbare architectuurpatronen naast elkaar en geeft een checklist voor de beoordeling van een API. Veldmapping en validatieregels op detailniveau vallen buiten deze pagina. Meer over de onderliggende norm leest u op de pagina over de EN 16931.
Drie architectuurpatronen
Er is geen patroon dat altijd de beste keuze is. De juiste keuze hangt af van uw schaal, de gewenste controle over het proces en de capaciteit die u hebt voor eigen onderhoud.
Connector in het pakket
Koppeling via de API van een Peppol Serviceprovider
Eigen middleware
Waar u op let bij een API
Kiest u voor een koppeling via een API, direct of via middleware, dan bepaalt de kwaliteit van die API grotendeels hoeveel werk de integratie kost en hoe stabiel ze blijft.
Checklist API-kwaliteit
- Webhooks en statusberichten: krijgt u realtime notificaties over de status van documenten (afgeleverd, afgewezen, in behandeling), of moet u zelf pollen?
- Sandbox: is er een testomgeving die het gedrag van het echte netwerk nabootst, zonder dat testberichten het productienetwerk bereiken?
- Validatie: valideert de API documenten vóór verzending, en krijgt u bruikbare foutmeldingen terug? Zie ook Factuurformaten en Peppol documenttypes en standaarden.
- Registratie van Peppol ID's via API: kunt u de registratie en het beheer van Peppol ID's van uw eindgebruikers programmatisch afhandelen?
- Multi-tenant: kunt u meerdere eindklanten apart beheren onder één technische aansluiting, elk met een eigen Peppol ID?
Testen vóór livegang
Een werkende API-koppeling betekent nog niet dat het hele proces werkt. Test end-to-end in de sandbox met een paar vaste handelspartners voordat u een klant live zet. Controleer daarbij verzenden én ontvangen, de verwerking van statusberichten en de afhandeling van afgewezen documenten.
Rol daarna gefaseerd uit. Begin met één klant of één documentstroom, bijvoorbeeld alleen uitgaande facturen, en schaal op zodra die stabiel draait. Zo blijven fouten beperkt tot een kleine groep en leert u van de praktijk voordat uw volledige klantenbestand overgaat.
Wat dit betekent voor integrators
Vertaal de architectuurkeuze en de API-checklist naar concrete actiepunten.
Checklist voor integrators
- Bepaal welk architectuurpatroon past bij uw schaal: één integratie of meerdere klanten en tenants
- Vraag elke kandidaat-API-provider naar de beschikbaarheid van een sandbox, de foutafhandeling en de ondersteuning voor multi-tenant
- Plan vóór livegang een testtraject met echte handelspartners
- Leg vast hoe de registratie van Peppol ID's in uw onboardingproces wordt geautomatiseerd
Wat dit betekent voor softwareleveranciers
Voor softwareleveranciers is de keuze ook een productbeslissing. Een eigen connector bouwen geeft maximale controle, maar u neemt dan ook het blijvende onderhoud op u. Een integratie met de API van een Peppol Serviceprovider houdt de gebruikerservaring in uw eigen product en besteedt de aansluiting op het netwerk uit. Een witlabel-oplossing van een Peppol Serviceprovider brengt e-facturatie het snelst in uw product, met minder invloed op functionaliteit en roadmap. Weeg af welke rol e-facturatie in uw propositie speelt: is het een kernfunctie waarmee u zich onderscheidt, of een basisvoorziening die gewoon moet werken?
Afsluiting
Een goede Peppol-integratie begint bij een bewuste architectuurkeuze en een kritische beoordeling van de API waarop u bouwt. Welk patroon u ook kiest, de vragen uit de checklist bepalen hoe schaalbaar en onderhoudbaar uw oplossing wordt. Meer over factuurformaten en documenttypen leest u op Factuurformaten en Peppol documenttypes en standaarden. Wilt u Peppol Serviceproviders met een API naast elkaar zetten? Bekijk de vergelijker op peppol.nu.
