kan ik mijn bestaande productdatabase gebruiken voor het productpaspoort

Wat u concreet moet doen

Wat er van u wordt verwacht

Veel bedrijven met 10 tot 100 medewerkers hebben al een productdatabase: een ERP-systeem, een PIM-systeem, of gewoon een uitgebreid Excel-bestand met artikelnummers, materialen, afmetingen en leveranciersgegevens. De vraag is niet óf die database nuttig is, maar of de gegevens erin voldoen aan wat de ESPR van een digitaal productpaspoort verwacht. Dat zijn twee verschillende dingen.

De inhoud moet overeenkomen met wat de gedelegeerde handeling vraagt

Artikel 9 van de ESPR (Verordening (EU) 2024/1781) beschrijft het digitaal productpaspoort als een verzameling productinformatie die via een gegevensdrager toegankelijk is. Welke informatie dat precies moet zijn, wordt per productgroep vastgelegd in een gedelegeerde handeling. Voor meubels is die nog niet gepubliceerd. Praktisch betekent dit dat een bestaande database een deel van de gevraagde gegevens vaak al bevat — materiaalsamenstelling, herkomst, afmetingen — maar zelden alles. Reparatie-informatie, recyclinginstructies of gegevens over herwinbaarheid staan doorgaans niet standaard in een ERP-systeem dat is ingericht voor voorraadbeheer en facturatie.

De data moet structureel koppelbaar zijn aan een gegevensdrager

Artikel 11 van de ESPR stelt eisen aan het technisch ontwerp: het paspoort moet bereikbaar zijn via een gegevensdrager (zoals een QR-code) en de gegevens moeten op een gestructureerde, machinaal leesbare manier worden aangeboden. Een database die alleen intern wordt gebruikt en niet is ingericht om per productexemplaar of -model een unieke, blijvende koppeling met een datadrager te leggen, voldoet daar niet automatisch aan. Voor een bedrijf van deze omvang betekent dit meestal dat er een extra laag nodig is tussen de bestaande database en de buitenwereld: een systeem dat de juiste gegevens uit de database haalt, in de juiste vorm zet, en aan een QR-code koppelt die tien jaar bereikbaar blijft.

De toegankelijkheid moet aan de eisen van artikel 10 voldoen

Artikel 10 van de ESPR gaat over wie welke gegevens mag zien en hoe lang die beschikbaar moeten blijven. Een interne database is meestal niet ingericht op publieke of gedeeltelijk publieke toegankelijkheid, laat staan op een bewaartermijn die los staat van of het bedrijf zelf nog bestaat. Dat vraagt om een aparte voorziening naast de bestaande database, niet om een vervanging ervan.

Waar het misgaat in de praktijk

Een fabrikant gaat ervan uit dat omdat alle technische specificaties al in het ERP-systeem staan, het paspoort "er zo uitrolt". In de praktijk ontbreken juist de velden die de ESPR waarschijnlijk gaat vragen, zoals reparatie- en demontage-informatie, en die moeten alsnog handmatig worden aangevuld.

Een importeur werkt met een database van de fabrikant uit een land buiten de EU en neemt aan dat die gegevens één-op-één te gebruiken zijn. De brondata is vaak niet in de structuur of taal die nodig is, en de importeur heeft als marktdeelnemer in de EU een eigen verantwoordelijkheid voor de juistheid van de gegevens die uiteindelijk in het paspoort komen.

Een projectinrichter heeft een eigen artikeldatabase per klantproject, maar die is niet gekoppeld aan een individuele gegevensdrager per product. Bij een controle blijkt dat er geen directe, stabiele link is tussen een verkocht meubelstuk en de bijbehorende paspoortgegevens.

Een bedrijf update de eigen database regelmatig, bijvoorbeeld bij een materiaalwijziging, maar vergeet dat het paspoort van al verkochte producten daardoor niet meer overeenkomt met het fysieke product. De interne database is een "levend" bestand, het paspoort moet juist een betrouwbare vastlegging zijn op het moment van verkoop.

Een bedrijf met veel kleur- en stofvarianten beheert die varianten als los veld binnen één productcode, terwijl het paspoort mogelijk per variant andere gegevens nodig heeft — denk aan een ander materiaalpercentage bij een andere stofkeuze. Wie hiermee te maken heeft, vindt meer over deze specifieke complicatie bij hoe maak ik paspoorten voor een meubelcollectie met veel kleur- en stofvarianten.

Wat u kunt vastleggen

• Een overzicht van welke gegevens al in de bestaande database staan, en welke daarvan waarschijnlijk relevant zijn voor een productpaspoort — gebaseerd op wat artikel 9 en 10 van de ESPR (Verordening (EU) 2024/1781) als richting geven, ook al ligt de exacte lijst per productgroep nog niet vast.
• Een aantekening over de bron en betrouwbaarheid van elk gegeven: is het zelf vastgesteld, of overgenomen van een toeleverancier of fabrikant elders in de keten.
• Een werkwijze voor het bijhouden van wijzigingen in productgegevens, zodat duidelijk is welke versie van de data bij welk verkocht product hoort.
• Afspraken met leveranciers over welke gegevens zij aanleveren en in welk formaat, zeker wanneer de eigen database afhankelijk is van hun input.
• Een overzicht van productvarianten en de gegevens die per variant kunnen verschillen, met name bij kleur- en stofuitvoeringen.

Wie dit nu al wil structureren, ook zonder dat de gedelegeerde handeling er is, vindt een aanpak in wat kan ik nu al doen terwijl de regels nog niet definitief zijn. En voor wie wil weten hoe deze inventarisatie past in de rest van het traject, staat een overzicht in hoe pak ik het productpaspoort voor meubels stap voor stap aan.

Een bestaande productdatabase is dus zelden waardeloos, maar ook zelden voldoende op zichzelf. Ze vormt in de meeste gevallen een bruikbaar startpunt: de basisgegevens staan er, de structuur en de koppeling met een gegevensdrager meestal niet. Het is verstandig die twee dingen apart te beoordelen — wat er al aan data is, en wat er nog nodig is om die data een paspoort te laten worden.