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

Koppeling is mogelijk, de vorm ligt niet vast in de wet

Ja, een digitaal productpaspoort kan in de praktijk gekoppeld worden aan een ERP- of voorraadsysteem, maar de ESPR schrijft niet voor hóe die koppeling eruitziet. De verordening stelt wel eisen aan het paspoort zelf: het moet technisch zo zijn gebouwd dat gegevens machineleesbaar zijn en dat systemen ze automatisch kunnen uitlezen en verwerken, op basis van open standaarden in plaats van gesloten, merkgebonden formats (artikel 11 van de ESPR, Verordening (EU) 2024/1781). Die eis is gericht op het paspoort en de gegevensdrager, niet op de interne systemen van een bandenimporteur, groothandel of wagenparkbeheerder. Of en hoe een koppeling met een specifiek ERP-pakket werkt, is dus een kwestie van technische inrichting bij de partij die het paspoort samenstelt en host — in dit geval een platform zoals tyrepas.eu — en niet iets wat de wet tot in detail regelt.

Voor wie dit relevant is, en voor wie niet

Deze vraag speelt vooral bij partijen die grote volumes banden verwerken en waarbij productgegevens al ergens in een systeem staan: importeurs die artikelnummers, partijgegevens en technische specificaties beheren, groothandels die voorraad bijhouden per bandtype, en wagenparkbeheerders die banden aan voertuigen koppelen. Voor hen is een koppeling vooral praktisch: gegevens hoeven dan niet dubbel te worden ingevoerd, en paspoortinformatie kan terugvloeien naar het eigen systeem.

Voor eindgebruikers die alleen een band kopen en de QR-code scannen, speelt koppeling met een ERP-systeem geen rol — zij lezen het paspoort, ze voeden het niet. En voor kleinere partijen zonder eigen systeem is koppeling ook niet aan de orde: het paspoort kan dan even goed handmatig worden aangeleverd en geraadpleegd, zonder dat dit iets afdoet aan de geldigheid ervan. De technische eisen uit artikel 11 gaan bovendien over het paspoort als zodanig, niet over de vraag of een leverancier van paspoortdiensten een specifieke koppeling met een bepaald ERP-merk moet aanbieden.

Nog geen vaste datum, wel een duidelijk werkspoor

Wanneer de verplichting tot een digitaal productpaspoort voor banden precies ingaat, staat nog niet vast. In het werkplan van de ESPR voor de periode 2025-2030 wordt een gedelegeerde handeling voor banden verwacht in 2027; pas met de publicatie daarvan wordt een concrete ingangsdatum bekend. Tot die tijd gelden er voor banden geen verplichte eisen aan het paspoort zelf, en dus ook niet aan de manier waarop gegevens worden aangeleverd of uitgewisseld.

Dat betekent niet dat er niets te doen valt. De algemene eisen uit artikel 10 en artikel 11 van de ESPR liggen al vast als kader waarbinnen de gedelegeerde handeling voor banden verder wordt ingevuld: machineleesbaarheid, open standaarden en interoperabiliteit zijn geen nieuwe uitvinding die pas in 2027 verschijnt, maar het fundament waarop de bandenspecifieke regels worden gebouwd. Wie nu al nadenkt over een koppeling, bouwt dus niet op drijfzand, ook al ontbreekt de definitieve datum nog.

Hoe dit in de praktijk wordt aangepakt

De eerste stap is nagaan welke gegevens al in het ERP- of voorraadsysteem staan die straks in een paspoort terug moeten komen: artikelnummer, partij- of batchgegevens, productiedatum, technische specificaties per bandtype. Veel van die gegevens bestaan al, ze staan alleen nog niet gestructureerd klaar voor een paspoort.

De tweede stap is uitzoeken welk formaat de partij die het paspoort samenstelt en host accepteert als invoer. Omdat tyrepas.eu het paspoort opbouwt uit gegevens van de fabrikant of importeur, is de praktische vraag niet zozeer óf koppeling kan, maar in welke vorm de gegevensaanlevering het handigst verloopt: een periodieke export vanuit het ERP-systeem, een gestructureerd bestand, of een andere aanleverroute.

De derde stap is nadenken over de andere richting: het terugkoppelen van paspoortgegevens naar het eigen systeem, bijvoorbeeld zodat een wagenparkbeheerder paspoortinformatie kan koppelen aan een voertuigregistratie zonder dat hij zelf het paspoort hoeft op te zoeken via de QR-code. Ook dit is een kwestie van technische afstemming tussen het ERP-systeem en het platform, niet van een wettelijke verplichting.

Tot slot is het van belang om rekening te houden met de looptijd: een paspoort wordt voor een periode van tien jaar gehost. Wie een koppeling opzet, doet er goed aan om ook na te denken over updates gedurende die periode — bijvoorbeeld wanneer productgegevens wijzigen — zodat de koppeling niet alleen bij de eerste aanlevering werkt, maar ook bij latere aanpassingen.

De wettelijke basis: artikel 10 en 11 ESPR

De eisen aan het digitale productpaspoort zelf staan in artikel 10 van de ESPR (Verordening (EU) 2024/1781), dat de algemene vereisten voor het paspoort vastlegt. Artikel 11 van dezelfde verordening gaat specifiek over het technisch ontwerp en de werking van het paspoort, met nadruk op interoperabiliteit en open standaarden zodat gegevens machineleesbaar en uitwisselbaar zijn. Beide artikelen richten zich op het paspoort als product, niet op de interne informatiesystemen van importeurs, groothandels of wagenparkbeheerders — de koppeling daarmee is een technische invulling die daarbovenop komt.

Wie nu al wil voorsorteren, kan het beste beginnen met het in kaart brengen van de eigen productgegevens en contact opnemen met de partij die het paspoort voor banden gaat samenstellen en hosten, om te bespreken welke aanleverroute het beste aansluit bij het bestaande ERP- of voorraadsysteem.

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

Het paspoort moet gegevens kunnen ontvangen uit een bronsysteem

Een productpaspoort wordt niet handmatig getypt in een los formulier — de gegevens komen ergens vandaan: uit een ERP-systeem, een voorraadbeheerpakket, een Excel-export van de fabrikant, of een combinatie daarvan. Artikel 10 van de ESPR (Verordening (EU) 2024/1781) stelt eisen aan welke gegevens in het paspoort moeten staan en hoe die toegankelijk zijn, maar schrijft niet voor via welk systeem een bedrijf die gegevens aanlevert. Voor een bandenimporteur of groothandel met 10 tot 100 medewerkers betekent dit praktisch dat er een vaste, herhaalbare manier moet zijn om productgegevens uit het eigen systeem naar het paspoort te krijgen — niet een eenmalige handmatige invoer die bij de volgende partij banden weer opnieuw wordt uitgevonden.

De koppeling moet passen bij een unieke identificatiecode per product

Artikel 11 van de ESPR beschrijft hoe het digitale productpaspoort technisch moet functioneren, waaronder de koppeling tussen een product en zijn paspoort via een identificatiecode. Een ERP- of voorraadsysteem werkt meestal met eigen artikelnummers, SKU's of interne codes. Voor de koppeling met het paspoort moet die interne code samenvallen met of vertaald worden naar de identificatiecode die het paspoort gebruikt. Bedrijven die per bandmaat of per batch al een duidelijke, unieke code voeren in hun voorraadsysteem hebben hier een voorsprong; bedrijven die met verzamelposten of algemene modelnamen werken, ontdekken vaak pas bij de koppeling dat hun interne administratie niet fijnmazig genoeg is. Meer over die basisstap staat in hoe geef ik elk product een unieke identificatiecode?

Wijzigingen in het bronsysteem moeten doorwerken in het paspoort

Een voorraadsysteem is nooit statisch: prijzen wijzigen, specificaties worden bijgewerkt, een leverancier past een samenstelling aan. Artikel 10 gaat uit van een paspoort dat de actuele stand van zaken weerspiegelt voor zover de gegevenscategorie dat vereist. Voor een bedrijf betekent dit dat een koppeling met het eigen systeem niet alleen bij de eerste invoer moet werken, maar ook bij latere aanpassingen — anders ontstaat een paspoort dat op moment van publicatie klopte, maar nu niet meer.

De koppeling moet herleidbaar zijn naar de bron

Een paspoort dat gegevens toont zonder dat nog te achterhalen is uit welk systeem, welke export of welke versie die gegevens komen, is moeilijk te verantwoorden bij een controle. Dit volgt niet uit een specifiek artikel maar uit de praktische kant van artikel 10 en 11 samen: gegevens moeten kloppen én controleerbaar zijn. Voor bedrijven met een koppeling naar hun ERP betekent dit dat een vorm van logging of versiebeheer wenselijk is — wanneer is welke set gegevens overgezet, en door wie.

Waar het misgaat in de praktijk

Een groothandel koppelt de voorraadmodule van het ERP-systeem één keer aan het paspoort bij de lancering, maar vergeet dat nieuwe bandmaten die later worden toegevoegd niet automatisch worden meegenomen — het paspoort blijft steken op het assortiment van de startdatum.

Een importeur gebruikt in het ERP-systeem een verzamelcode voor een hele productlijn ("175/65R14 zomerband, diverse merken"), terwijl het paspoort per unieke identificatiecode moet werken. De koppeling levert dan één paspoort op voor producten die eigenlijk elk hun eigen paspoort nodig hebben — zie ook hoe verhoudt de bandenmaat zich tot de unieke identificatiecode?

Een wagenparkbeheerder krijgt een export van de fabrikant in een format dat niet aansluit op het eigen voorraadsysteem, en de gegevens worden handmatig overgetypt in een tussenbestand. Bij de volgende levering wordt dat tussenbestand niet bijgewerkt, waardoor het paspoort een oudere versie van de specificaties toont dan wat er daadwerkelijk in het magazijn ligt.

Een bedrijf koppelt het ERP-systeem rechtstreeks aan het paspoort zonder tussenstap, en een fout in een exportveld (bijvoorbeeld een verwisselde kolom met bandmaten) komt ongezien in meerdere paspoorten terecht, omdat niemand de gekoppelde data na overzetting nog controleert.

Een importeur denkt dat één keer koppelen voldoende is voor alle toekomstige varianten van een model, terwijl er voor iedere maat of uitvoering eigenlijk aparte gegevens nodig zijn — de vraag of gegevens hergebruikt mogen worden voor verschillende bandmaten van hetzelfde model komt dan te laat aan de orde, zie kan ik dezelfde gegevens gebruiken voor meerdere bandmaten van hetzelfde model?

Wat u kunt vastleggen

Een overzicht van welk systeem (ERP, voorraadbeheer, leveranciersportaal) de bron is voor welk gegevensveld in het paspoort, zodat bij een vraag of controle direct duidelijk is waar een cijfer of specificatie vandaan komt.
Een vaste procedure voor het overzetten van gegevens bij nieuwe producten, inclusief het moment waarop de unieke identificatiecode wordt toegekend en gekoppeld.
Een afspraak over wie verantwoordelijk is voor het bijwerken van het paspoort wanneer gegevens in het bronsysteem wijzigen — en binnen welke werkwijze dat gebeurt.
Een controlestap na iedere koppeling of export, waarin steekproefsgewijs wordt nagekeken of de gegevens in het paspoort overeenkomen met het bronsysteem.
Een logboek of versiehistorie van wat er is overgezet en wanneer, zodat een wijziging achteraf herleidbaar is.
Documentatie van de technische koppeling zelf (welke exportformaten, welke velden worden gemapt, welke software of tussenlaag wordt gebruikt), bruikbaar als bijlage bij interne audits.

Voor bedrijven die nog moeten bepalen of hun banden überhaupt onder deze verplichting vallen, is dat een logische eerdere stap — zie geldt het digitaal productpaspoort voor mijn banden? Wie meer wil weten over de rol van het paspoort in de keten als geheel, en waar de koppeling met een eigen systeem in past, vindt een algemene uitleg in wat is een digitaal productpaspoort voor banden?

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.