European Business Wallet Peppol integratie: wat er verandert in uw implementatie

Wie vandaag Peppol-koppelingen bouwt of onderhoudt, krijgt sinds november 2025 dezelfde vraag uit de directiekamer: moeten wij iets met die European Business Wallet? Het eerlijke antwoord is dat de European Business Wallet Peppol integratie op dit moment nog geen enkele regel code afdwingt, en tegelijk een aantal ontwerpkeuzes raakt die u nu al maakt en later duur terugkoopt. Dit artikel gaat over de vier plekken in een bestaande Peppol-implementatie waar de wallet daadwerkelijk landt, en over wat u er wel en niet op kunt vooruitlopen.

Twee onderdelen laten we hier bewust liggen omdat ze elders al uitgewerkt zijn. De architecturale kern, namelijk hoe de wallet het adresprobleem bij grensoverschrijdende e-facturatie in principe kan oplossen, staat in de analyse van het drielagenprobleem. De vraag hoe Peppol-transport zich verhoudt tot gekwalificeerde aangetekende bezorging staat in het stuk over QERDS en de EBW. Wat hier volgt is de integratielaag daarboven.

Waarom dit nu op de agenda hoort en niet later

De stand van zaken per 5 september 2026 is nuchter. De Raad heeft op 9 juni 2026 zijn onderhandelingsmandaat aangenomen. Het Europees Parlement heeft zijn standpunt nog niet vastgesteld: het proceduredossier 2025/0358(COD) staat op “awaiting committee decision”, met een ontwerpverslag van 1 april 2026, ingediende amendementen van 23 april 2026 en adviezen van IMCO en JURI uit begin juni 2026. De trialogen zijn daarmee nog niet begonnen. Formele aanname wordt op zijn vroegst begin 2027 verwacht, waarna overheidsinstanties twee jaar krijgen om de kernfuncties van de wallet te accepteren. Praktisch betekent dat: een acceptatieplicht die pas rond 2029 bijt, en technische detaillering die grotendeels in nog niet bestaande uitvoeringshandelingen komt te staan.

Dat is geen argument om te wachten. Het is een argument om geen wallet-connector te bouwen en wel uw datamodel op orde te brengen. De ontwerpkeuzes die pijn gaan doen, gaan namelijk niet over protocollen maar over aannames: dat een bedrijf één identifier heeft, dat het recht om dat adres te gebruiken een contractuele afspraak is, en dat de ontvangen factuur na mapping weggegooid mag worden. Die drie aannames zitten in vrijwel elke ERP-koppeling die de afgelopen tien jaar is gebouwd, en de wallet zet ze alle drie onder druk.

Er is nog een structurele factor. Voor bedrijven blijft het gebruik van de wallet vrijwillig, terwijl overheden hem moeten accepteren. Die asymmetrie betekent dat er nooit een moment komt waarop u kunt aannemen dat elke tegenpartij een wallet heeft. Elke integratie die u bouwt, moet dus permanent twee paden ondersteunen: met wallet en zonder. Dat is geen tijdelijke overgangssituatie maar de eindsituatie.

Identiteit en identificatie: een nieuwe identifier, geen nieuw adres

Peppol identificeert deelnemers met een Participant Identifier in de vorm scheme::waarde, waarbij het schema uit de door OpenPeppol beheerde codelijst komt. In Nederland gaat het om 0106 voor het KvK-nummer, 0190 voor het OIN van overheidsorganisaties en 9944 voor het btw-nummer. De Nederlandse Peppolautoriteit (NPa) verplicht Nederlandse entiteiten tot een SMP-registratie voor SI-UBL 2.0 en Peppol BIS Billing 3. De codelijst zelf is een levend document: versie 9.7 dateert van 2 juli 2026 en bevat 105 schema’s, en OpenPeppol wijst er expliciet op dat het een dynamische lijst is.

Het voorstel voor de European Business Wallet hangt de identificatie van de walletbezitter op aan de European Unique Identifier, de EUID uit het systeem van gekoppelde handelsregisters. Dat is een bestaande, in EU-recht verankerde identifier die per land door het handelsregister wordt uitgegeven. In de Peppol-codelijst voor participant identifier schemes komt de EUID op dit moment niet voor.

Daar liggen twee mogelijke uitkomsten, en beide zijn plausibel. In de eerste wordt er een schema voor de EUID aan de Peppol-codelijst toegevoegd, waarna een deelnemer naast zijn KvK-adres ook een EUID-adres kan registreren. In de tweede presenteert de wallet juist een bestaand identificatienummer, bijvoorbeeld het KvK- of btw-nummer, als geverifieerd attribuut. Dan verandert er aan het identifier-niveau niets, maar wel aan de herkomst: waar nu een klant een nummer intypt, komt dan een verifieerbare bewering uit een authentieke bron.

Wat verandert er in uw implementatie. In beide scenario’s is de kritieke aanname dezelfde: één bedrijf is niet gelijk aan één Peppol-adres. Als uw datamodel de Peppol-identifier als veld op de klantrecord heeft staan, en niet als een aparte tabel met schema, waarde, herkomst, bewijs en geldigheidsdatum, dan is dat de eerste refactor die u wilt doen. Ook het onderscheid tussen het routeringsadres in cbc:EndpointID en de juridische identificatie in cac:PartyLegalEntity wordt scherper zodra er meerdere geverifieerde nummers in omloop zijn. Codelijsten horen bovendien als data in uw systeem te zitten en niet als enumeratie in de broncode: elke hardcoded 0106 of 9944 is een release die u straks moet plannen.

Wat vaststaat: de EUID bestaat en is in het voorstel het ankerpunt voor identificatie. Wat waarschijnlijk is: de Peppol-codelijst wordt uitgebreid, want dat is precies waar die lijst voor is. Wat open ligt: of een wallet ooit een e-facturatie-eindpunt als attribuut gaat dragen. Dat laatste is een beleidskeuze die in de uitvoeringshandelingen moet vallen, en die keuze is nog niet gemaakt.

Attesten en machtigingen: bewijs op de plek waar nu een afspraak staat

Dit is de plek waar de wallet het meeste toevoegt, en tegelijk de plek die in de meeste implementaties het slechtst gemodelleerd is. Vandaag berust de vraag “mag deze klant dit Peppol-adres gebruiken” op de Peppol Serviceprovider-overeenkomst. De Policy for use of Identifiers legt bij de serviceprovider de verplichting neer om passende governance te voeren over identificatieschema’s bij het aanmaken, wijzigen en verwijderen van SMP-informatie, maar schrijft geen verificatieprocedure voor. In de praktijk betekent dat een uittreksel, een getekend formulier, of een mail van een bekend domein. Het bewijs is contractueel, per provider verschillend en niet machineleesbaar.

De wallet brengt hier twee dingen. Ten eerste elektronische attesten van attributen, het instrumentarium dat eIDAS 2.0 met Verordening (EU) 2024/1183 heeft geïntroduceerd, inclusief gekwalificeerde attesten en attesten die door of namens een publieke instantie uit een authentieke bron worden afgegeven. Ten tweede het digitaal beheer van vertegenwoordigingsrechten en mandaten, dat in het voorstel als expliciete functionaliteit is opgenomen. De Raad heeft daar in zijn mandaat aan toegevoegd dat het autorisatiestelsel bestaande volmachtwetgeving onverlet laat en dat nationale procedurele vereisten van toepassing blijven, wat de juridische werking bewust beperkt houdt.

Wat verandert er in uw implementatie. Onboarding wordt verifieerbaar in plaats van beweerd. Dat is alleen goedkoop als het bewijs bij u al een eigen plek heeft. Concreet: leg per identifier vast welke bron het bewijs leverde, welk document het was, op welke datum, door wie geaccepteerd en tot wanneer geldig. Wie dat vandaag als getypt veld en een PDF in een ticketsysteem afhandelt, moet bij invoering van attesten het hele onboardingproces herbouwen. Wie het als een getypeerd bewijsobject modelleert, voegt straks één nieuw bewijstype toe.

Hetzelfde geldt voor vertegenwoordiging. Een administratiekantoor dat namens tweehonderd klanten verstuurt, is in de meeste systemen een gebruikersaccount met rechten. Dat is iets anders dan een mandaat. Modelleer expliciet dat entiteit X namens entiteit Y documenten van type Z mag versturen tot datum D, los van welke gebruiker inlogt. Zodra dat als data bestaat, kan een verifieerbaar mandaat uit een wallet die record vullen in plaats van hem te vervangen. Binnen WE BUILD is “Company Representative acting on behalf of a Company” niet voor niets een van de dertien use cases.

Wat open ligt is aanzienlijk: of OpenPeppol wallet-attesten ooit als geldig bewijs voor SMP-registratie zal aanmerken, of dat als beleid of alleen als optie komt, en hoe intrekking en herbevestiging worden geregeld. Reken erop dat er een verversingsmodel komt en zorg dat uw bewijsobject een vervaldatum kent.

Ondertekening en zegeling: waar dat in de bestaande stroom past

In de huidige Peppol-keten worden documenten niet op documentniveau ondertekend. Vertrouwen komt uit het transport: AS4-berichten worden ondertekend met certificaten uit de Peppol-PKI, en de ontvanger vertrouwt zijn accesspoint. Het UBL-formaat kent een plek voor een handtekening, maar Peppol BIS Billing 3.0 gebruikt die niet. Fiscaal is dat verdedigbaar, want artikel 233 van de btw-richtlijn laat elke belastingplichtige zelf kiezen hoe hij de authenticiteit van de herkomst en de integriteit van de inhoud waarborgt, en noemt bedrijfscontroles met een betrouwbaar controlespoor als volwaardige route. Geavanceerde handtekeningen en EDI zijn daar voorbeelden, geen verplichting.

De wallet voegt digitaal ondertekenen, tijdstempelen en zegelen toe als kernfunctie. Een gekwalificeerd elektronisch zegel geniet onder eIDAS het vermoeden van integriteit van de gegevens en van de juistheid van hun herkomst. Transportbeveiliging bewijst dat een bericht via een vertrouwd kanaal is gekomen, een zegel bewijst iets over het document zelf, ook nadat het het netwerk heeft verlaten.

Wat verandert er in uw implementatie. Twee dingen, en het tweede is de dure. Ten eerste komt er een validatiestap bij: iemand moet het zegel controleren, de trust list raadplegen, de intrekkingsstatus op ontvangstmoment vaststellen en het validatierapport bewaren. Langetermijnvalidatie is een reëel kostenpost en geen bijzaak, want een zegel dat over zeven jaar niet meer te valideren is, bewijst in een geschil niets.

Ten tweede, en dit is de goedkoopste maatregel in dit hele artikel: bewaar de originele ontvangen payload, niet alleen de gemapte velden. Veel ERP-koppelingen normaliseren de inkomende UBL naar interne records en gooien de bytes weg. Een genormaliseerde factuur is per definitie niet meer te verifiëren tegen een handtekening of zegel, omdat elke byte telt. Sla de originele payload op met een hash en de transportmetadata. Dat kost vandaag opslag en is achteraf niet te repareren.

Wat open ligt: of gezegelde documenten überhaupt over Peppol zullen reizen dan wel over het eigen beveiligde kanaal van de wallet, en of OpenPeppol een ingebedde handtekening in BIS zou toestaan of vereisen. Daar is niets over besloten. De vraag naar het beveiligde kanaal loopt bovendien direct door naar de QERDS-discussie, die in het genoemde zusterartikel is uitgewerkt.

Wat de wallet uitdrukkelijk niet vervangt

Het is verleidelijk om de wallet te lezen als een nieuw netwerk. Dat is hij niet.

• Het Peppol-transportmodel blijft. Het voorstel gaat over identiteit, attesten, ondertekenen, vertegenwoordiging en een beveiligd kanaal. Het definieert geen routeringsnetwerk met SMP- en SML-opzoeking, capaciteitsontdekking en documenttypeonderhandeling. Peppol beantwoordt de vraag of deze ontvanger een BIS Billing 3.0-factuur kan verwerken, op welk eindpunt en met welk certificaat. Een wallet beantwoordt de vraag wie iemand is en wat hij kan bewijzen. Alleen bij de opzoeklaag raken die vragen elkaar echt.
• De documentstandaarden blijven. EN 16931 blijft het semantische model, Peppol BIS Billing 3.0 blijft de implementatie ervan, en de Europese btw-hervorming verankert die richting verder. Een wallet heeft geen opvatting over factuurregels, btw-categorieën of toeslagen.
• De rol van de Peppol Serviceprovider blijft. Validatie, mapping, foutafhandeling, monitoring, verwerking van meldingen, bijhouden van codelijsten, voldoen aan de eisen van de Peppolautoriteit en archivering verdwijnen niet. Een wallet voegt een identiteitsbron toe, geen middleware.

De enige laag waar de wallet werkelijk iets kan verdringen is de adressering en opzoeking, en dat is precies het onderwerp van het eerder genoemde stuk over het drielagenprobleem. Wie meer wil dan dat belooft, loopt vooruit op besluiten die nog niet genomen zijn.

European Business Wallet Peppol integratie: wat u nu al kunt doen

Alles hieronder is nuttig ongeacht wat er in de trialogen gebeurt. Dat is het selectiecriterium geweest.

1. Ontkoppel bedrijfsidentiteit van Peppol-adres. Eén partijrecord met meerdere identifiers, elk met schema, waarde, bron, bewijs, ingangsdatum en vervaldatum.
2. Behandel de Peppol-codelijsten als data. Versie 9.7 van 2 juli 2026 is niet de laatste. Geen enumeraties in de broncode, en een gedocumenteerd updateritme.
3. Maak onboardingbewijs machineleesbaar en getypeerd. Welke bron, welk document, welke datum, wie accepteerde, tot wanneer geldig.
4. Modelleer vertegenwoordiging als eersteklas gegeven, los van gebruikersaccounts en rollen.
5. Bewaar de originele ontvangen en verzonden payload met hash en transportmetadata, naast de gemapte gegevens.
6. Isoleer validatie achter één interface, zodat schema, Schematron en straks eventueel zegelvalidatie stappen in dezelfde keten zijn en geen losse bouwsels.
7. Ondersteun meerdere identifiers per ontvanger in uw opzoeklogica, met expliciete cache-TTL en een gedefinieerde terugvaloptie.
8. Wijs één persoon aan die de OpenPeppol-codelijstreleases, de WE BUILD eInvoicing use case en het dossier in het Parlement volgt. Eén persoon, niet een werkgroep.
9. Vraag de Nederlandse Peppolautoriteit wat haar standpunt is voordat u er zelf een inneemt.

Wat u nu juist niet moet vastleggen. Bouw geen wallet-connector: de profielen uit het architectuurraamwerk en de uitvoeringshandelingen liggen er niet. Ga niet uit van een e-facturatie-eindpunt als walletattribuut, want dat is nog een open beleidskeuze. Kies nog niet tussen “de wallet vervangt de SMP” en “de wallet voedt de SMP”, want beide varianten zijn nog levend. Ontwerp geen archivering die verplichte zegels veronderstelt. En doe richting klanten geen contractuele toezegging over EBW-compatibiliteit zolang de verordening niet is aangenomen.

Vragen die u als ondernemer aan uw leverancier stelt

U hoeft de techniek hierboven niet te kennen om te toetsen of uw leverancier voorsorteert. Deze acht vragen zijn genoeg, en de kwaliteit van het antwoord zegt meer dan het antwoord zelf.

• Kunt u meerdere Peppol-identifiers per entiteit vastleggen, en wat gebeurt er in uw systeem als wij er een bij krijgen?
• Bewaart u de originele ontvangen factuurbestanden of alleen de verwerkte gegevens, en kan ik die originelen exporteren?
• Hoe legt u vast dat wij gerechtigd zijn ons Peppol-adres te gebruiken, en hoe zou u een digitaal attest uit een handelsregister verwerken?
• Hoe is geregeld dat ons accountantskantoor namens ons verstuurt: als een vastgelegde machtiging met einddatum, of als een accountrecht?
• Met welke frequentie verwerkt u nieuwe versies van de Peppol-codelijsten, en hoe merken wij dat?
• Wie bij u volgt het EBW-dossier, en wat is uw standpunt over de European Business Wallet Peppol integratie?
• Welke kosten zou een koppeling met de wallet naar verwachting meebrengen, en valt dat binnen ons huidige contract?
• Wat gebeurt er in uw oplossing als een tegenpartij wel met een wallet werkt en wij niet, of andersom?

Meer over de politieke tijdlijn staat in het artikel over de trialoog over de European Business Wallet, en voor de bredere context is er de tijdlijn van het wetgevingstraject.

Bronnen

1. Voorstel voor een Verordening betreffende de instelling van European Business Wallets, COM(2025) 838 final, EUR-Lex
2. Procedurefiche 2025/0358(COD), Legislative Observatory van het Europees Parlement
3. Raad van de Europese Unie, European business wallets: Council adopts negotiating position, 9 juni 2026
4. Europese Commissie, beleidspagina European Business Wallets
5. Verordening (EU) 2024/1183 tot wijziging van Verordening (EU) nr. 910/2014 met betrekking tot het Europees kader voor digitale identiteit
6. OpenPeppol eDEC Code Lists, versie 9.7 van 2 juli 2026
7. Peppol EDN Policy for use of Identifiers, versie 4.4.0
8. Nederlandse Peppolautoriteit, Use of Peppol in the Netherlands
9. Richtlijn 2006/112/EG betreffende het gemeenschappelijke stelsel van belasting over de toegevoegde waarde, artikel 233
10. WE BUILD Consortium, overzicht van de dertien use cases

De European Business Wallet Peppol integratie is nog geen implementatieopdracht, maar wel een selectiecriterium. Een leverancier die meerdere identifiers per entiteit aankan, originele documenten bewaart en machtigingen expliciet vastlegt, is straks goedkoop aan te sluiten. Een leverancier die dat niet doet, herbouwt zijn onboarding. Op de onafhankelijke vergelijker van Peppol Serviceproviders op Peppol.nu filtert u op softwareomgeving, factuurvolume, doellanden en bedrijfsgrootte, zodat u die vragen aan de juiste partijen stelt.