Kan ik het productpaspoort koppelen aan mijn ERP- of voorraadsysteem?
Een koppeling is het uitgangspunt van het systeem, niet een uitzondering
Ja, een koppeling tussen een productpaspoort en een ERP- of voorraadsysteem past bij hoe het digitale productpaspoort is bedoeld. Artikel 11 van de ESPR (Verordening (EU) 2024/1781) schrijft voor dat het paspoort technisch zo wordt opgezet dat gegevens via open, interoperabele standaarden kunnen worden uitgewisseld tussen de partijen in de keten. Dat betekent dat de gegevens die nu al in een ERP- of voorraadsysteem staan — artikelnummers, materiaalgegevens, herkomst, technische specificaties — in beginsel de bron kunnen zijn waaruit het paspoort wordt gevuld, in plaats van dat alles handmatig opnieuw wordt ingevoerd. Elektropas.com is in die keten de plek waar deze gegevens worden samengevoegd tot een paspoort, gehost, en gekoppeld aan een QR-datadrager. Hoe die koppeling er precies technisch uitziet — welk bestandsformaat, welke API, welke velden verplicht zijn — is voor elektronica en ICT-apparatuur nog niet vastgelegd, omdat de gedelegeerde handeling voor deze deelcategorie nog niet is gepubliceerd.
Voor wie dit geldt en waar de grens ligt
Deze vraag speelt vooral bij fabrikanten en importeurs die hun productgegevens al gestructureerd bijhouden — in een ERP-pakket, een PIM-systeem of een voorraadadministratie — en die willen voorkomen dat het paspoort een losstaand, handmatig proces wordt. Voor hen is een koppeling relevant omdat het dubbel werk scheelt en de kans op fouten kleiner maakt.
Waar dit niet voor geldt: het productpaspoort vervangt het ERP-systeem niet, en andersom evenmin. Het paspoort is een apart, extern toegankelijk gegevensbestand dat is gekoppeld aan een fysiek product via een unieke identificatie en een datadrager, zoals artikel 10 van de ESPR beschrijft. Een ERP-systeem blijft de interne administratie van de onderneming; het paspoort is de laag die naar buiten toe — richting consument, toezichthouder of volgende schakel in de keten — informatie ontsluit. Een koppeling betekent dus dat gegevens uit het ene systeem doorstromen naar het andere, niet dat beide systemen samensmelten.
De exacte technische standaard staat nog niet vast voor elektronica
Een vaste datum waarop de technische specificatie voor elektronica en ICT-apparatuur bekend wordt, is er nog niet. Volgens het ESPR-werkplan 2025-2030 worden de gedelegeerde handelingen per productcategorie uitgewerkt, en voor elektronica wordt dit vanaf 2027 verwacht. Tot die handeling is gepubliceerd, gelden alleen de algemene uitgangspunten uit artikel 10 en 11: het paspoort moet interoperabel, machineleesbaar en gebaseerd op open standaarden zijn. Wélke standaard dat concreet wordt voor elektronica — welk dataformaat, welke koppelvlakken, welke verplichte velden — ligt nog niet vast. Zodra de gedelegeerde handeling voor deze deelcategorie is gepubliceerd, wordt die informatie hier aangevuld.
Hoe dit in de praktijk wordt aangepakt
De volgorde waarin dit meestal wordt opgepakt, ziet er als volgt uit. Eerst wordt in kaart gebracht welke gegevens al in het bestaande ERP- of voorraadsysteem staan en welke daarvan vermoedelijk relevant zijn voor een productpaspoort — denk aan materiaalsamenstelling, herkomst, technische documentatie en reparatie-informatie. Vervolgens is het zinvol om te kijken of die gegevens al gestructureerd en consistent zijn vastgelegd, omdat machineleesbaarheid een van de uitgangspunten van artikel 11 is: hoe schoner en eenduidiger de brondata, hoe eenvoudiger een latere koppeling wordt. Daarna is het een kwestie van wachten op de gedelegeerde handeling voor elektronica, omdat pas dan duidelijk wordt welk formaat en welke koppelmethode worden vereist. Zodra die specificatie er is, kan gekeken worden of het bestaande systeem een export in dat formaat kan leveren, of dat een tussenstap nodig is. Er is op dit moment geen reden om al een specifieke technische integratie te bouwen, omdat de standaard waarop die zou moeten aansluiten nog niet vaststaat — dat werk zou dan mogelijk over moeten.
De wettelijke basis: artikel 10 en 11 van de ESPR
Dat een koppeling met een ERP- of voorraadsysteem denkbaar en beoogd is, volgt uit twee artikelen. Artikel 10 van de ESPR beschrijft de vereisten waaraan het digitale productpaspoort moet voldoen, waaronder de koppeling aan een unieke productidentificatie en de toegankelijkheid van gegevens voor de betrokken partijen. Artikel 11 gaat specifiek over het technische ontwerp en de werking van het paspoort, en bepaalt dat dit gebeurt op basis van open, interoperabele standaarden die gegevensuitwisseling door de keten heen mogelijk maken. Samen vormen deze artikelen de basis waarom een koppeling tussen interne bedrijfssystemen en het externe paspoort geen toevoeging is, maar onderdeel van hoe het systeem is opgezet — al is de precieze technische invulling voor elektronica nog niet gepubliceerd.
Wie nu al wil voorsorteren, doet er goed aan om de eigen productgegevens op orde te brengen: consistent, gestructureerd en compleet, zodat een latere koppeling — zodra de standaard voor elektronica bekend is — zo min mogelijk extra werk vraagt. Elektropas.com volgt de publicatie van de gedelegeerde handeling voor elektronica en ICT-apparatuur, en vult deze pagina aan zodra de technische specificatie bekend is.
Waar dit op gebaseerd is
- Verordening (EU) 2024/1781 (ESPR), artikel 11 (technisch ontwerp en werking van het digitale productpaspoort)
- Verordening (EU) 2024/1781 (ESPR), artikel 10 (vereisten voor het digitale productpaspoort)
De verordening zelf staat op EUR-Lex. Wij verwijzen per bewering; u hoeft ons niet te geloven.
Wat u concreet moet doen
Wat er van u wordt verwacht
Een ERP- of voorraadsysteem koppelen aan het digitaal productpaspoort is voor veel bedrijven de logische route: de productgegevens staan er al, dus waarom niet automatisch doorzetten? De ESPR (Verordening (EU) 2024/1781) schrijft niet voor hoe die koppeling technisch werkt, maar wel aan welke eisen het paspoort zelf moet voldoen. Die eisen bepalen in de praktijk wat een koppeling met een eigen systeem wel en niet mag zijn.
Het paspoort moet voldoen aan de technische eisen uit artikel 11
Artikel 11 van de ESPR (Verordening (EU) 2024/1781) beschrijft de technische ontwerpeisen van het digitaal productpaspoort: hoe gegevens toegankelijk moeten zijn, in welke vorm en met welke koppeling naar de unieke identificatie van het product. Voor een bedrijf van 10 tot 100 medewerkers betekent dit dat een koppeling met het eigen ERP-systeem niet vrijblijvend een export van een Excel-bestand kan zijn: de data die vanuit het systeem wordt aangeleverd, moet aansluiten op het technische formaat dat voor het paspoort geldt. Welk formaat dat precies is, wordt per productcategorie uitgewerkt; daarover leest u meer op de pagina over het bestandsformaat van het paspoort.
Het paspoort moet gekoppeld zijn aan een unieke productidentificatie
Artikel 10 van de ESPR (Verordening (EU) 2024/1781) stelt eisen aan de inhoud en structuur van het paspoort, waaronder de koppeling aan een identificatiecode per product. Een ERP-systeem werkt vaak al met artikelnummers, SKU's of batchcodes, maar die zijn niet automatisch gelijk aan de identificatiecode die het paspoort vereist. Voor een middelgroot bedrijf betekent dit dat er een vertaalslag nodig is tussen de interne productcodering en de identificatiecode die extern, via de QR-code, wordt ontsloten. Hoe die unieke code per product wordt opgezet, staat beschreven op de pagina over het geven van een unieke identificatiecode aan elk product.
De koppeling moet gegevens actueel houden zonder de herkomst te verliezen
Een ERP-systeem verandert voortdurend: voorraadniveaus wijzigen, artikelen worden uitgefaseerd, nieuwe varianten komen erbij. Het paspoort volgt een ander ritme — het moet gedurende een vastgestelde periode bereikbaar blijven, ook als het onderliggende product niet meer wordt verkocht. Een koppeling die simpelweg "live" doorgeeft wat er op dit moment in het ERP-systeem staat, loopt het risico dat historische paspoorten worden overschreven of verdwijnen zodra een product uit het actieve assortiment wordt gehaald. Hoe lang een paspoort beschikbaar moet blijven, staat toegelicht op de pagina over hoe lang het paspoort moet blijven bestaan.
Waar het misgaat in de praktijk
Een paar situaties komen relatief vaak terug bij bedrijven die hun ERP-systeem willen koppelen aan het productpaspoort.
Automatische sync overschrijft actieve paspoorten. Wanneer een artikel in het ERP-systeem wordt aangepast — een nieuwe leverancier van een onderdeel, een gewijzigde verpakking — wordt die wijziging soms direct doorgezet naar het gepubliceerde paspoort, zonder dat duidelijk is of dat een nieuw paspoort moet worden of een update van het bestaande.
Artikelnummer wordt verward met productidentificatie. Het interne artikelnummer uit het voorraadsysteem wordt gebruikt als unieke identificatiecode voor het paspoort, terwijl dat nummer bijvoorbeeld per verkoopkanaal of regio kan verschillen — waardoor één fysiek product met meerdere, onderling afwijkende paspoorten eindigt.
Uitfasering in het ERP-systeem trekt het paspoort mee offline. Zodra een product als "niet meer leverbaar" wordt gemarkeerd in het voorraadsysteem, stopt de koppeling met publiceren of onderhouden van het paspoort — terwijl het paspoort nog bereikbaar moet blijven voor producten die al bij de consument in gebruik zijn.
Koppeling levert data in een formaat dat niet aansluit. Het ERP-systeem exporteert gegevens in een intern format (bijvoorbeeld een CSV met bedrijfseigen veldnamen) dat niet één-op-één overeenkomt met de structuur die het paspoort vereist, waardoor een tussenstap nodig blijkt die niet was voorzien.
Verpakkingsniveaus raken door elkaar. Een voorraadsysteem registreert vaak op het niveau van de verkoopeenheid, terwijl een paspoort per productvariant of per verpakkingseenheid kan verschillen — met name bij producten die in dozen met meerdere apparaten worden geleverd. Hoe dat samenspel werkt, staat beschreven op de pagina over hoe het productpaspoort werkt bij een doos met meerdere apparaten.
Wat u kunt vastleggen
Voor bedrijven die overwegen hun ERP- of voorraadsysteem te koppelen aan het productpaspoort is het praktisch om vooraf een aantal zaken schriftelijk vast te leggen:
- Een overzicht van welke velden uit het ERP-systeem corresponderen met welke velden in het paspoort, inclusief een toelichting op afwijkingen tussen interne artikelcodering en de externe productidentificatie.
- Een procedure voor wat er gebeurt bij wijziging van een product: wanneer leidt een aanpassing in het ERP-systeem tot een nieuw paspoort, en wanneer tot een update van het bestaande paspoort.
- Een procedure voor uitfasering, waarin is vastgelegd dat het paspoort losstaat van de status "actief" of "uitgefaseerd" in het voorraadsysteem.
- Een afspraak over wie verantwoordelijk is voor de koppeling — intern IT-team, extern platform, of een combinatie — en wie controleert of de aangeleverde data daadwerkelijk aansluit op het vereiste formaat.
- Documentatie van het gebruikte technische formaat, zodat bij een controle of audit kan worden aangetoond dat de koppeling aansluit op de eisen uit artikel 11 van de ESPR (Verordening (EU) 2024/1781).
Voor bedrijven die naast het ERP-systeem ook een GS1-structuur gebruiken voor hun logistiek, is het van belang om te weten of en hoe die structuur aansluit op de eisen van het paspoort; meer daarover staat op de pagina over wat GS1 Digital Link is en of dat nodig is voor het productpaspoort. Ook is het verstandig om vast te leggen hoe de koppeling omgaat met het register waarin paspoorten moeten worden opgenomen, zoals toegelicht op de pagina over het Europese register van digitale productpaspoorten.
Dit is geen juridisch advies. Deze pagina geeft algemene informatie over de regelgeving waar dit platform over gaat. Wij kennen uw situatie niet. Bij twijfel over uw eigen geval raadpleegt u een jurist of de bevoegde toezichthouder.
Geschreven met AI op basis van de bronnen hierboven, gecontroleerd door een mens op 2026-08-22. Klopt er iets niet? Laat het weten — correcties krijgen voorrang.