Die EU-Kommission hat am 20. Juli 2026 das Register für Digitale Produktpässe samt Testumgebung in Betrieb genommen. Damit ist aus einer abstrakten ESPR-Komponente ein System geworden, das Unternehmen tatsächlich ausprobieren können. Für Hersteller ist jetzt vor allem eine Unterscheidung wichtig: Das Register ist der zentrale Index, der Produktpass selbst bleibt dezentral.
Was am 20. Juli live gegangen ist
Das Register nimmt eindeutige Produktkennungen, Registrierungsdaten und ausgewählte Metadaten auf. Die vollständigen Produktinformationen liegen weiterhin beim verantwortlichen Wirtschaftsakteur oder bei einem beauftragten DPP-Dienstleister. Die Kommission beschreibt das Register deshalb ausdrücklich als Indexdienst und nicht als zentrales Content-Management-System.
Registrierungen sind über eine gesicherte Benutzeroberfläche und über eine API vorgesehen. Unternehmen können zudem einen elektronischen Registrierungsnachweis erzeugen. Das ist für B2B-Prozesse relevant, weil Lieferanten und Kunden damit belegen können, dass ein Pass im EU-System eingetragen wurde, ohne den gesamten Datenbestand zu duplizieren.
Der Start betrifft nicht nur ESPR-Produktgruppen. Die Kommission nennt auch Batterien, Bauprodukte, Spielzeug, Waschmittel und Endnutzer-Tenside, soweit das jeweilige Unionsrecht einen Digitalen Produktpass verlangt. Die erste verbindliche Frist bleibt der 18. Februar 2027 für bestimmte Batterien.
Register, Resolver und Datenquelle sind drei verschiedene Schichten
Ein belastbares DPP-System sollte die Aufgaben sauber trennen:
- Das EU-Register bestätigt, dass eine Kennung und die vorgeschriebenen Metadaten registriert sind.
- Ein Resolver leitet die persistente Produktkennung zur passenden Ressource weiter.
- Die eigentliche Datenquelle liefert aktuelle Inhalte für Menschen und Maschinen.
Diese Trennung ist kein Detail. Wer sämtliche Daten ausschließlich in einer eigenen Produktseite ablegt, hat noch keine Registerintegration. Wer umgekehrt nur eine Kennung registriert, stellt noch keinen brauchbaren Produktpass bereit. Beides muss über stabile Identifikatoren verbunden werden.
Für die Auflösung eignet sich ein offener, dauerhafter Link. Ein GS1-Digital-Link-Resolver kann unterschiedliche Darstellungen aus derselben Kennung erreichbar machen: eine verständliche Webseite, maschinenlesbares JSON-LD oder eine ergänzende Dokumentation. Der Datenträger auf Produkt oder Verpackung bleibt dabei stabil, auch wenn sich die Zielsysteme weiterentwickeln.
Was Unternehmen in der Testumgebung prüfen sollten
Die Testumgebung ist nicht nur für einen manuellen Klicktest gedacht. Sie sollte wie eine Vorstufe zur produktiven Integration behandelt werden.
Organisation und Rollen
Zuerst muss geklärt werden, welche Rechtseinheit registriert, wer sie im System vertritt und welche Teams Registrierungen anlegen oder ändern dürfen. Das betrifft Stammdaten, Compliance, IT und gegebenenfalls externe Dienstleister. Ein persönlicher Testzugang ersetzt kein Rollenmodell für den späteren Betrieb.
Kennungen und Granularität
Das Produktteam sollte nachvollziehen, ob der spätere Pass auf Modell-, Chargen- oder Einzelstückebene geführt wird. Die Antwort hängt vom jeweiligen Sektorrecht ab. Der Registertest ist der richtige Zeitpunkt, um interne Produkt-IDs, GTINs, Chargenkennungen und die extern verwendete persistente Kennung aufeinander abzubilden.
API und Wiederholbarkeit
Ein produktiver Prozess braucht mehr als einen erfolgreichen POST. Registrierung, Aktualisierung und Fehlerbehandlung müssen wiederholbar und protokolliert sein. Dazu gehören idempotente Requests, technische Quittungen und eine klare Zuordnung zwischen ERP-Datensatz, DPP und Registereintrag. Ein API-basierter DPP-Prozess reduziert manuelle Abweichungen, wenn Produkte in größeren Mengen angelegt werden.
Trennung von Metadaten und Fachdaten
Die Registerdaten sollten nicht zum zweiten Produktdatenbestand werden. Definieren Sie, welche Felder im Register erforderlich sind und welche im dezentralen Pass bleiben. Für jede Information braucht es eine führende Quelle, eine verantwortliche Stelle und eine Aktualisierungsregel.
Nachweis und Monitoring
Registrierungsnachweise sollten zusammen mit Zeitstempel, verwendeter Kennung und Systemantwort gespeichert werden. Zusätzlich braucht es einen Abgleich: existiert der Pass, ist der Resolver erreichbar und stimmen Register-Metadaten und Produktstatus noch überein?
Warum der Zoll eine eigene Prüfkette braucht
Das Register unterstützt Zollbehörden dabei, vor der Überlassung zum freien Verkehr automatisiert zu prüfen, ob ein gültiger registrierter DPP und der erforderliche Warencode vorliegen. Für Importeure entsteht dadurch eine neue Abhängigkeit: Produktkennung, Registereintrag und Zollanmeldung müssen konsistent sein.
Ein Fehler wird daher nicht erst auf einer Produktseite sichtbar. Er kann den Grenzprozess betreffen. Unternehmen sollten schon im Test Datenflüsse von der Produktanlage bis zur Importdokumentation simulieren und festlegen, wer eine fehlerhafte Registrierung kurzfristig korrigieren darf.
Ein sinnvoller 30-Tage-Testplan
- Eine reale Rechtseinheit und ein kleines, repräsentatives Produktsortiment auswählen.
- Für jedes Produkt die geplante DPP-Granularität und führenden Kennungen dokumentieren.
- Einen vollständigen Durchlauf über Benutzeroberfläche und, wenn relevant, API ausführen.
- Registrierungsnachweis, Resolver-Antwort und maschinenlesbare Produktdaten gemeinsam archivieren.
- Fehlerfälle testen: doppelte Kennung, veraltete Metadaten, nicht erreichbarer Datenhost und zurückgezogenes Produkt.
- Aus den Ergebnissen ein Betriebsmodell mit Verantwortlichkeiten, Monitoring und Eskalationsweg ableiten.
Der operative Start des Registers bedeutet noch nicht, dass alle sektorspezifischen Datenanforderungen bereits vollständig gelten. Er verschiebt die Diskussion aber von Präsentationen zu überprüfbaren Abläufen. Unternehmen können jetzt erkennen, ob ihre Kennungen, Rollen und APIs zusammenpassen, bevor die ersten Pflichttermine greifen.
