De Europese Commissie heeft op 20 juli 2026 het register voor digitale productpaspoorten en de testomgeving in gebruik genomen. Daarmee is een abstracte ESPR-component veranderd in een systeem dat bedrijven daadwerkelijk kunnen uitproberen. Voor fabrikanten is nu vooral één onderscheid belangrijk: het register is de centrale index, terwijl het productpaspoort zelf gedecentraliseerd blijft.
Wat er op 20 juli live is gegaan
Het register neemt unieke productidentificaties, registratiegegevens en geselecteerde metadata op. De volledige productinformatie blijft beschikbaar bij de verantwoordelijke marktdeelnemer of bij een ingeschakelde DPP-dienstverlener. De Commissie beschrijft het register daarom uitdrukkelijk als een indexdienst en niet als een centraal contentmanagementsysteem.
Registraties zijn voorzien via een beveiligde gebruikersinterface en via een API. Bedrijven kunnen bovendien een elektronisch registratiebewijs genereren. Dat is relevant voor B2B-processen, omdat leveranciers en klanten daarmee kunnen aantonen dat een pas in het EU-systeem is geregistreerd, zonder de volledige dataset te dupliceren.
De start heeft niet alleen betrekking op ESPR-productgroepen. De Commissie noemt ook batterijen, bouwproducten, speelgoed, wasmiddelen en tensiden voor eindgebruikers, voor zover het toepasselijke Unierecht een digitaal productpaspoort voorschrijft. De eerste bindende termijn blijft 18 februari 2027 voor bepaalde batterijen.
Register, resolver en gegevensbron zijn drie verschillende lagen
Een robuust DPP-systeem moet de taken duidelijk scheiden:
- Het EU-register bevestigt dat een identificatie en de voorgeschreven metadata zijn geregistreerd.
- Een resolver verwijst de persistente productidentificatie door naar de passende bron.
- De eigenlijke gegevensbron levert actuele inhoud voor mensen en machines.
Deze scheiding is geen detail. Wie alle gegevens uitsluitend op een eigen productpagina zet, heeft nog geen registerintegratie. Wie daarentegen alleen een identificatie registreert, biedt nog geen bruikbaar productpaspoort. Beide moeten via stabiele identificatoren met elkaar worden verbonden.
Voor het opzoeken is een open, permanente link geschikt. Een GS1-Digital-Link-resolver kan verschillende weergaven op basis van dezelfde identificatie toegankelijk maken: een begrijpelijke webpagina, machineleesbare JSON-LD of aanvullende documentatie. De gegevensdrager op het product of de verpakking blijft daarbij stabiel, ook als de doelsystemen verder worden ontwikkeld.
Wat bedrijven in de testomgeving moeten controleren
De testomgeving is niet alleen bedoeld voor een handmatige kliktest. Ze moet worden behandeld als een voorfase van de productie-integratie.
Organisatie en rollen
Eerst moet worden vastgesteld welke juridische entiteit registreert, wie haar in het systeem vertegenwoordigt en welke teams registraties mogen aanmaken of wijzigen. Dit betreft stamgegevens, compliance, IT en eventueel externe dienstverleners. Een persoonlijke testtoegang vervangt geen rollenmodel voor de latere bedrijfsvoering.
Identificaties en granulariteit
Het productteam moet nagaan of het latere paspoort op model-, batch- of individueel productniveau wordt bijgehouden. Het antwoord hangt af van de toepasselijke sectorwetgeving. De registertest is het juiste moment om interne product-ID's, GTINs, batchidentificaties en de extern gebruikte persistente identificatie aan elkaar te koppelen.
API en herhaalbaarheid
Een productieproces vereist meer dan één geslaagde POST. Registratie, updates en foutafhandeling moeten herhaalbaar en gelogd zijn. Daaronder vallen idempotente requests, technische ontvangstbevestigingen en een duidelijke koppeling tussen ERP-record, DPP en registervermelding. Een op API gebaseerde DPP-procedure vermindert handmatige afwijkingen wanneer producten in grotere aantallen worden aangemaakt.
Scheiding van metadata en vakgegevens
De registergegevens mogen geen tweede productdataset worden. Bepaal welke velden in het register verplicht zijn en welke in het gedecentraliseerde paspoort blijven. Voor elke informatie is een leidende bron, een verantwoordelijke partij en een actualiseringsregel nodig.
Bewijs en monitoring
Registratiebewijzen moeten samen met tijdstempel, gebruikte identificatie en systeemrespons worden opgeslagen. Daarnaast is een controle nodig: bestaat het paspoort, is de resolver bereikbaar en komen registermetadata en productstatus nog met elkaar overeen?
Waarom de douane een eigen controleketen nodig heeft
Het register ondersteunt douaneautoriteiten bij de geautomatiseerde controle, vóór het in het vrije verkeer brengen, of een geldig geregistreerd DPP en de vereiste goederencode aanwezig zijn. Voor importeurs ontstaat daardoor een nieuwe afhankelijkheid: productidentificatie, registervermelding en douaneaangifte moeten consistent zijn.
Een fout wordt dus niet pas op een productpagina zichtbaar. Ze kan het grensproces beïnvloeden. Bedrijven moeten al in de testfase gegevensstromen van het aanmaken van het product tot en met de importdocumentatie simuleren en vastleggen wie een foutieve registratie op korte termijn mag corrigeren.
Een zinvol 30-dagen-testplan
- Selecteer een echte juridische entiteit en een kleine, representatieve productselectie.
- Documenteer voor elk product de geplande DPP-granulariteit en de leidende identificaties.
- Voer een volledige doorloop uit via de gebruikersinterface en, indien relevant, de API.
- Archiveer registratiebewijs, resolverrespons en machineleesbare productgegevens gezamenlijk.
- Test foutscenario's: dubbele identificatie, verouderde metadata, niet-bereikbare gegevenshost en teruggetrokken product.
- Leid uit de resultaten een bedrijfsmodel af met verantwoordelijkheden, monitoring en escalatieroute.
De operationele start van het register betekent nog niet dat alle sectorspecifieke gegevensvereisten al volledig van kracht zijn. Wel verschuift de discussie van presentaties naar controleerbare processen. Bedrijven kunnen nu vaststellen of hun identificaties, rollen en API's op elkaar aansluiten, voordat de eerste verplichte termijnen ingaan.
