Kan ik het productpaspoort koppelen aan mijn ERP- of voorraadsysteem?

Een koppeling is technisch mogelijk, maar niet wettelijk verplicht of uitgesloten

De ESPR schrijft niet voor hóe een fabrikant of importeur de gegevens voor het digitale productpaspoort aanlevert. De verordening stelt eisen aan het paspoort zelf — welke gegevens erin moeten staan, hoe het toegankelijk moet zijn, en met welke technische standaarden het moet werken — maar laat in het midden of die gegevens handmatig worden ingevoerd, uit een spreadsheet komen, of automatisch uit een ERP- of voorraadsysteem worden gehaald. Een koppeling tussen een intern systeem en een passportdienst is dus geen kwestie van wat de wet toestaat, maar van wat de gebruikte techniek en de aangeboden dienst mogelijk maken.

Voor wie dit relevant is, en voor wat niet

Deze vraag speelt vooral bij bedrijven die al met een ERP- of voorraadsysteem werken en niet twee keer dezelfde productgegevens willen bijhouden: één keer in het eigen systeem, één keer voor het paspoort. Dat is een praktische, geen juridische kwestie. De ESPR bepaalt niet dat een fabrikant een geautomatiseerde koppeling moet hebben, en bepaalt evenmin dat dit verboden zou zijn. Wat de verordening wél regelt, is de technische vorm die de paspoortgegevens uiteindelijk moeten hebben — ongeacht hoe ze zijn aangeleverd. Dit onderwerp gaat dus niet over verplichtingen rond de koppeling zelf, maar over de eisen waaraan de onderliggende data moet voldoen, wat vervolgens bepaalt of een koppeling zinvol en werkbaar is.

Nog geen vaste datum, wel al vastliggende technische kaders

De gedelegeerde handeling die de verplichting tot een digitaal productpaspoort voor meubels concreet maakt, is er nog niet; het ESPR-werkplan 2025-2030 noemt 2028 als verwachte periode voor publicatie. Zolang die handeling er niet is, staat ook niet vast welke productgroep-specifieke gegevens precies verplicht worden en in welk format. Wat al wel vaststaat, zijn de algemene technische eisen aan het paspoort uit artikel 10 en artikel 11 van de ESPR: die gelden voor alle producten die onder een gedelegeerde handeling vallen, dus ook straks voor meubels. Die algemene kaders zijn nu al bekend en kunnen worden gebruikt om na te denken over de inrichting van eigen dataprocessen, ook al ligt de exacte inhoud van het meubelpaspoort nog niet vast.

Hoe dit in de praktijk aan te pakken

Wie nu al nadenkt over een koppeling, doet er verstandig aan eerst te kijken welke productgegevens al gestructureerd in het eigen ERP- of voorraadsysteem staan: materiaalsamenstelling, herkomst van onderdelen, afmetingen, onderhoudsinstructies en dergelijke. Dat is de basis waarmee een paspoort wordt samengesteld, of dat nu handmatig gebeurt of via een koppeling. Vervolgens is het zinvol te achterhalen in welk format die gegevens worden vastgelegd, en of dat format zich leent voor uitwisseling met een extern systeem — denk aan gestructureerde velden in plaats van vrije tekst. Op dit platform wordt het paspoort samengesteld uit de gegevens die de fabrikant of importeur aanlevert; hoe die aanlevering precies verloopt en of daarvoor een automatische koppeling beschikbaar is, is een praktische vraag die apart besproken kan worden. Voor de langere termijn is het verstandig productgegevens zo te structureren dat ze zonder grote omzetting geschikt zijn voor een digitaal paspoort, ongeacht of de aanlevering nu handmatig gebeurt of later geautomatiseerd wordt. Dat bespaart dubbel werk op het moment dat de verplichting voor meubels ingaat.

Grondslag: artikel 10 en artikel 11 van de ESPR

Artikel 10 van de ESPR (Verordening (EU) 2024/1781) beschrijft de vereisten waaraan het digitale productpaspoort moet voldoen, waaronder de koppeling van gegevens aan een uniek productidentificatienummer en de toegankelijkheid van die gegevens gedurende de levensduur van het product. Artikel 11 van dezelfde verordening gaat over het technisch ontwerp en de werking van het paspoort, en bevat de eisen rond open standaarden, interoperabiliteit en machineleesbaarheid van de data. Samen bepalen deze artikelen niet hoe gegevens worden aangeleverd, maar wel aan welke technische vorm die gegevens uiteindelijk moeten voldoen — en dat is precies het aanknopingspunt voor de vraag of en hoe een koppeling met een ERP- of voorraadsysteem werkbaar is.

Wat u nu kunt doen

Breng in kaart welke productgegevens al in het eigen ERP- of voorraadsysteem staan en in welk format, en bespreek met de leverancier van het paspoort — in dit geval dit platform — welke aanlevermogelijkheden er praktisch zijn. Zodra de gedelegeerde handeling voor meubels is gepubliceerd, verschijnt hier de concrete datum en de precieze gegevensvereisten; tot die tijd is het vooral zinvol om de eigen data alvast gestructureerd en overdraagbaar te maken.

Waar dit op gebaseerd is

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 koppeling tussen uw ERP- of voorraadsysteem en het digitale productpaspoort is technisch vaak mogelijk en kan veel handwerk besparen. De ESPR schrijft niet voor hoe u aan uw gegevens komt of hoe u ze intern beheert; de verordening stelt eisen aan het paspoort zelf, aan wat daarin moet staan en hoe het toegankelijk moet zijn. Dat betekent dat een koppeling met een eigen systeem geen doel op zich is, maar een middel om aan die eisen te voldoen.

Het paspoort moet aan de technische vereisten voldoen, ongeacht de bron van de data

Artikel 10 van de ESPR (Verordening (EU) 2024/1781) beschrijft wat voor gegevens een digitaal productpaspoort moet bevatten en aan welke voorwaarden het moet voldoen, zoals juistheid en volledigheid. Voor een bedrijf van 10 tot 100 medewerkers betekent dit dat de herkomst van de gegevens — of die nu handmatig worden ingevoerd of automatisch uit een ERP-systeem komen — niet vermindert wat er van de inhoud wordt verwacht. Een koppeling verandert dus niets aan de verplichting; het verandert alleen hoe u die verplichting praktisch invult.

Het paspoort moet aansluiten op het technisch ontwerp dat artikel 11 vereist

Artikel 11 van de ESPR (Verordening (EU) 2024/1781) gaat over het technisch ontwerp en de werking van het digitale productpaspoort, waaronder de manier waarop gegevens worden opgeslagen, uitgewisseld en ontsloten via de datadrager. Voor een koppeling met een eigen systeem betekent dit dat de output van die koppeling — de gegevens die uiteindelijk in het paspoort belanden — moet passen binnen het technisch kader dat voor het paspoort geldt, zoals het gebruikte gegevensmodel en de wijze van ontsluiten via de QR-code op het meubel. Een exportbestand uit een ERP-pakket is dus zelden direct een paspoort; het is meestal een bron die eerst moet worden vertaald naar het juiste formaat.

Elke koppeling levert data die aan een unieke identificatiecode gekoppeld moet worden

Een ERP- of voorraadsysteem werkt meestal met interne artikelnummers of SKU's. Die vallen niet automatisch samen met de identificatiecode die het productpaspoort vereist. Bij het opzetten van een koppeling is het dus van belang om te bepalen hoe elk product een unieke identificatiecode krijgt en hoe die code zich verhoudt tot de bestaande artikelcodering in het eigen systeem. Zonder die vertaalslag ontstaat het risico dat interne nummers per ongeluk in het paspoort belanden, of dat één productpaspoort niet goed te herleiden is naar de juiste voorraadregel.

Waar het misgaat in de praktijk

Automatische synchronisatie zonder controlemoment. Een koppeling die rechtstreeks en zonder tussenstap gegevens uit het ERP-systeem naar het paspoort stuurt, lijkt efficiënt, maar betekent ook dat een fout in het bronsysteem — een verkeerd ingevoerd materiaalpercentage, een verlopen certificaat — automatisch doorwerkt in een gepubliceerd paspoort.

Verwarring tussen interne SKU en publieke identificatiecode. Bedrijven gebruiken soms hetzelfde interne artikelnummer als externe identificatiecode, zonder te checken of dat nummer al ergens anders in gebruik is of aan de vereisten voldoet. Dit speelt met name bij bedrijven die met GS1 Digital Link werken en de koppeling daarmee moeten afstemmen.

Geen koppeling tussen voorraadmutatie en paspoortstatus. Als een product uit productie wordt genomen of wordt vervangen door een nieuwe variant, wordt dat in het ERP-systeem vaak wel bijgehouden, maar leidt dat niet automatisch tot een update van het paspoort. De vraag of en hoe gegevens na publicatie aangepast kunnen worden wordt dan pas laat gesteld, meestal nadat een klant of toezichthouder een discrepantie signaleert.

Onvoldoende aandacht voor samengestelde producten. Een ERP-systeem registreert onderdelen en varianten vaak los van elkaar, terwijl de vraag of het meubel als geheel of elk onderdeel apart een paspoort nodig heeft, apart beantwoord moet worden. Een koppeling die uitgaat van de structuur in het voorraadsysteem loopt dan het risico de verkeerde eenheid als uitgangspunt te nemen.

Koppeling stopt bij systeemwissel of leverancierswissel. Wanneer een bedrijf van ERP-pakket wisselt, van hostingpartij verandert, of stopt met een bepaalde IT-leverancier, wordt er niet altijd bij stilgestaan dat de koppeling met het paspoort dan opnieuw ingericht moet worden. Dit raakt ook de vraag wat er met het paspoort gebeurt als een bedrijf zelf stopt of van vorm verandert.

Wat u kunt vastleggen

Een overzicht van welke velden uit het ERP- of voorraadsysteem automatisch worden overgenomen in het paspoort, en welke velden altijd handmatig worden gecontroleerd voordat publicatie plaatsvindt.
Een vastgelegde vertaaltabel tussen interne artikelnummers en de identificatiecodes die extern gebruikt worden, inclusief de afspraak over wie deze tabel actueel houdt.
Een procedure voor het moment waarop een wijziging in het bronsysteem — nieuw materiaal, nieuwe leverancier, aangepaste samenstelling — aanleiding geeft om het paspoort te controleren of aan te passen.
Afspraken met de IT-leverancier of hostingpartij over wat er gebeurt bij een systeemwissel, inclusief wie verantwoordelijk is voor het overzetten van de koppeling.
Een intern controlemoment (bijvoorbeeld per kwartaal) waarin steekproefsgewijs wordt gecheckt of de gegevens in het gepubliceerde paspoort nog overeenkomen met de actuele stand in het ERP-systeem.
Documentatie over de taal of talen waarin gegevens vanuit het ERP-systeem worden aangeleverd, in relatie tot de vraag in welke taal het paspoort aangeboden moet worden.

Wij stellen sjablonen ter beschikking voor een aantal van deze afspraken, zodat vastleggen niet bij elk product opnieuw vanaf de grond moet gebeuren.

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.