Ab dem 18. Februar 2027 greift die erste Stufe der EU-weiten Pflicht zum Digitalen Produktpass: Batterien -- Elektrofahrzeug-, Leichtfahrzeug- und Industriebatterien mit mehr als 2 kWh -- dürfen dann nur noch mit einem digitalen Batteriepass in Verkehr gebracht werden (Europäische Kommission). Danach folgen schrittweise Textilien, Elektronik, Möbel und weitere Warengruppen. Grundlage ist die Ökodesign-Verordnung für nachhaltige Produkte (ESPR, Verordnung (EU) 2024/1781), die seit dem 18. Juli 2024 in Kraft ist und den Rahmen für nahezu alle physischen Produkte setzt (Europäische Kommission). Der Digitale Produktpass ist dabei ein digitaler Produktausweis, der Angaben zu Material, Reparierbarkeit, Herkunft und Recycling über einen QR-Code oder einen anderen Datenträger zugänglich macht (Europäische Kommission). Für Händler und Hersteller heißt das: strukturierte Produktdaten bereitstellen -- und genau diese Daten liegen bereits in ERP und PIM. Dieser Artikel zeigt, wie das Datenmodell nach CIRPASS und GS1 aussieht, welche Rolle der eindeutige Identifier spielt und wie eine Middleware den Produktpass aus den Bestandssystemen speist, statt Daten doppelt zu pflegen.
Was der Digitale Produktpass ist -- und ab wann er Pflicht wird
Der Digitale Produktpass (DPP) ist im Kern ein strukturierter Datensatz, der ein physisches Produkt mit seinen Nachhaltigkeits- und Lebenszyklusinformationen verknüpft. Die Europäische Kommission beschreibt ihn als digitalen Produktausweis für Produkte, Komponenten und Materialien, der relevante Informationen zur Nachhaltigkeit speichert und elektronisch zugänglich macht (Europäische Kommission). Erreichbar wird der Pass über einen Datenträger am Produkt -- in der Regel einen QR-Code --, der auf einen Online-Datensatz verweist. Verschiedene Zielgruppen greifen mit unterschiedlichen Rechten darauf zu: Verbraucher sehen Pflege- und Reparaturhinweise, Recycler die Materialzusammensetzung, Marktüberwachungsbehörden die Konformitätsnachweise.
Die ESPR erweitert den bisherigen Ökodesign-Ansatz von energieverbrauchsrelevanten Produkten auf praktisch alle physischen Warengruppen -- ausgenommen sind im Wesentlichen Lebensmittel, Futtermittel und Arzneimittel (Europäische Kommission). Die konkreten Anforderungen je Warengruppe legt die Kommission in delegierten Rechtsakten fest. Den Auftakt macht jedoch nicht die ESPR selbst, sondern die EU-Batterieverordnung (Verordnung (EU) 2023/1542): Ab dem 18. Februar 2027 ist der Batteriepass für EV-, Leichtfahrzeug- und Industriebatterien über 2 kWh verpflichtend (Europäische Kommission). Im April 2025 hat die Kommission zudem den ersten ESPR-Arbeitsplan 2025 bis 2030 verabschiedet, der sechs vorrangige Produktgruppen benennt: Stahl und Aluminium, Textilien mit Schwerpunkt Bekleidung, Möbel, Reifen und Matratzen (Europäische Kommission).
| Warengruppe | Zeithorizont | Grundlage |
|---|---|---|
| Batterien (EV, Leichtfahrzeug, Industrie über 2 kWh) | ab 18. Februar 2027 | Batterieverordnung (EU) 2023/1542 |
| Eisen und Stahl | delegierter Rechtsakt indikativ ab 2026 | ESPR-Arbeitsplan 2025-2030 |
| Textilien (Fokus Bekleidung) | delegierter Rechtsakt indikativ ab 2027 | ESPR-Arbeitsplan 2025-2030 |
| Reifen und Aluminium | delegierter Rechtsakt indikativ ab 2027 | ESPR-Arbeitsplan 2025-2030 |
| Möbel und Matratzen | im Arbeitsplan als vorrangig vorgesehen | ESPR-Arbeitsplan 2025-2030 |
| Zwischenüberprüfung des Arbeitsplans | 2028 | Europäische Kommission |
Batterien sind erst der Anfang
Welche Daten der Produktpass verlangt
Der genaue Datenumfang wird je Warengruppe im delegierten Rechtsakt festgelegt, doch die Kategorien sind über die Verordnung bereits abgesteckt. Der Digitale Produktpass soll Angaben zu technischer Leistung, zu verwendeten Materialien und deren Herkunft, zu Reparatur- und Wartungsaktivitäten, zur Recyclingfähigkeit sowie zu den Umweltwirkungen über den Lebenszyklus enthalten (Europäische Kommission). Aus Sicht der Systemintegration ist entscheidend: Fast alle diese Angaben existieren bereits im Unternehmen -- verteilt über ERP, PIM und angrenzende Systeme.
Materialien und Zusammensetzung
Stoffliche Zusammensetzung, Rezyklatanteil und gegebenenfalls kritische Rohstoffe je Bauteil oder Charge.
Reparierbarkeit
Verfügbarkeit von Ersatzteilen, Reparaturanleitungen und -- wo vorgesehen -- ein Reparierbarkeitsindex.
Herkunft und Lieferkette
Ursprung, Fertigungsort und Stationen entlang der Lieferkette zur Rückverfolgbarkeit.
Kreislauffähigkeit
Hinweise zu Demontage, Recycling und fachgerechter Entsorgung am Ende der Nutzung.
Umweltwirkung
CO2-Fußabdruck, Energieverbrauch und Angaben zu enthaltenen Chemikalien über den Lebenszyklus.
Konformität
Konformitätsnachweise und Erklärungen, die Marktüberwachungsbehörden elektronisch prüfen können.
Genau hier liegt der Hebel für die Integration: Materialstämme, Chargen und Herkunftsangaben sind typischerweise als Stammdaten im ERP hinterlegt, während Attribute, Varianten, Medien und beschreibende Texte im PIM gepflegt werden. Der Produktpass entsteht nicht durch eine neue, separate Datenerfassung, sondern durch das Zusammenführen und Anreichern vorhandener Datenbestände.
Das Datenmodell: CIRPASS, GS1 Digital Link und eindeutige Identifier
Damit ein Produktpass über Branchen und Systeme hinweg lesbar bleibt, braucht es ein gemeinsames Datenmodell. Diese Grundlage schafft das von der EU geförderte Konsortium CIRPASS. Das Nachfolgeprojekt CIRPASS-2 startete im Mai 2024, bündelt 49 Partner und erprobt den Produktpass über drei Jahre in 13 großangelegten Pilotprojekten in den Wertschöpfungsketten Textil, Elektronik, Reifen und Bau (CIRPASS). Allein sechs dieser Piloten entfallen auf Textilien und fünf auf Elektronik (CIRPASS). Aus der ersten Projektphase stammt die EU DPP Core Ontology (März 2025), die als faktische Interoperabilitätsreferenz für die sektoralen Piloten dient (CIRPASS).
Der zweite Baustein ist der eindeutige Identifier. Ein Produktpass muss mit einer eindeutigen Produktkennung verknüpft sein, über die der Datensatz aufgefunden wird. Hier kommt der GS1 Digital Link ins Spiel: Er bettet etablierte GS1-Kennungen wie die GTIN in eine Web-Adresse ein, sodass ein QR-Code nach ISO/IEC 18004 direkt auf den Produktpass-Datensatz auflöst (GS1 Germany). Der Datenträger selbst muss nach ESPR einem ISO/IEC-Standard entsprechen (Europäische Kommission); neben dem QR-Code kommen dafür auch GS1 DataMatrix, RFID-Tags oder NFC-Chips infrage (GS1 Germany).
| Datenträger | Eigenschaft | Typischer Einsatz |
|---|---|---|
| QR-Code (ISO/IEC 18004) | Mit jedem Smartphone scannbar, günstig zu drucken | De-facto-Standard für den DPP am Produkt |
| GS1 DataMatrix | Hohe Datendichte auf kleiner Fläche | Kleinteile und stark bedruckte Produkte |
| RFID-Tag | Auslesen ohne Sichtkontakt, mehrere Objekte zugleich | Logistik und Bestandsführung |
| NFC-Chip | Antippen mit dem Smartphone | Höherwertige Einzelprodukte |
Der Identifier ist der Anker des Produktpasses
Woher die Daten kommen: ERP und PIM als Quellen
Die Kernfrage jedes DPP-Projekts lautet nicht, welche neuen Daten erhoben werden müssen, sondern wo die geforderten Angaben bereits liegen. In der Praxis verteilen sie sich auf zwei Hauptquellen. Das ERP führt die kaufmännischen und logistischen Stammdaten: Artikelstämme, Chargen, Seriennummern, Lieferanten und Herkunftsangaben. Das PIM führt die beschreibenden Produktinformationen: Attribute, Materialangaben, Varianten, Medien und mehrsprachige Texte.
- Aus dem ERP: eindeutige Artikelkennung und GTIN, Chargen- und Seriennummern, Lieferanten- und Herkunftsdaten, Stücklisten als Grundlage für die Materialzusammensetzung.
- Aus dem PIM: Materialattribute und Zusammensetzung, Pflege- und Reparaturhinweise, Dokumente wie Anleitungen und Konformitätserklärungen, mehrsprachige Beschreibungen.
- Aus angrenzenden Systemen: CO2- und Lebenszyklusdaten aus Nachhaltigkeits- oder Lieferantensystemen sowie Prüf- und Konformitätsnachweise aus dem Qualitätsmanagement.
Das Problem: Diese Angaben doppelt zu pflegen -- einmal im Fachsystem und einmal in einer separaten Produktpass-Lösung -- führt zu widersprüchlichen Ständen und hohem Aufwand. Wird eine Rezeptur geändert oder ein Lieferant gewechselt, müsste die Änderung an zwei Stellen nachgezogen werden. Genau diese doppelte Datenhaltung gilt es zu vermeiden. Wie sich Produktdaten sauber zwischen den Systemen abbilden lassen, vertieft der Beitrag zum Daten-Mapping zwischen ERP und Shop; den Aufbau einer durchgängigen Produktdaten-Pipeline beschreibt der Beitrag zur PIM-Integration.
Die Middleware: Produktdaten DPP-konform aggregieren
Die Antwort auf die doppelte Datenhaltung ist eine Middleware, die zwischen den Bestandssystemen und dem Produktpass vermittelt. Sie liest die relevanten Felder aus ERP und PIM, führt sie zu einem konsistenten Datensatz zusammen, bildet sie auf das DPP-Datenmodell ab und stellt sie über eine API bereit -- abrufbar über den Identifier im Datenträger. Die führende Datenhaltung bleibt in den Fachsystemen; die Middleware ist die Aggregations- und Bereitstellungsschicht, nicht ein weiteres Datensilo.
- Felder aus ERP und PIM auslesen: Über die jeweiligen APIs werden Artikelkennung, Materialien, Herkunft, Dokumente und Konformitätsangaben abgeholt.
- Auf das DPP-Modell mappen: Die Felder werden auf die Struktur nach CIRPASS-Core-Ontology und die Anforderungen des delegierten Rechtsakts abgebildet.
- Validieren und anreichern: Pflichtfelder werden geprüft, Einheiten normalisiert und fehlende Angaben aus angrenzenden Systemen ergänzt.
- Identifier verankern: Jeder Datensatz erhält seinen GS1 Digital Link, der im QR-Code am Produkt hinterlegt wird.
- Über API bereitstellen: Der Pass wird als versionierter Datensatz ausgeliefert und beim Scan des Datenträgers rollenabhängig zugänglich gemacht.
Weil der Produktpass über eine öffentlich erreichbare Schnittstelle ausgeliefert wird, gehören Zugriffssteuerung und Versionierung von Anfang an in die Architektur. Nicht jede Angabe ist für jede Zielgruppe bestimmt: Verbraucher, Recycler und Behörden erhalten unterschiedliche Sichten auf denselben Datensatz. Wie sich solche Schnittstellen sauber absichern lassen, behandelt der Beitrag zu OAuth 2.0 und Token-Sicherheit für ERP-Schnittstellen. Und weil der Pass über Jahre hinweg fortgeschrieben wird, muss die Schnittstelle Änderungen versionssicher abbilden -- ein Aspekt, den der Beitrag zur API-Versionierung vertieft.
Der Produktpass wird fortgeschrieben, nicht einmalig erzeugt
Typische Fallstricke bei der Umsetzung
Aus Integrationsprojekten mit Produktdaten lassen sich wiederkehrende Stolpersteine ableiten (Projekterfahrung). Die meisten liegen nicht in der Technik der Schnittstelle, sondern in der Datenqualität der Quellsysteme und in der sauberen Abbildung auf das geforderte Modell.
- Lückenhafte Stammdaten: Fehlende Materialangaben oder Herkunftsdaten fallen erst auf, wenn der Pflichtdatensatz erzeugt werden soll. Ein früher Datencheck deckt Lücken auf, solange noch Zeit zum Nachpflegen bleibt.
- Uneindeutige Identifier: Ohne konsistente GTIN oder stabile Artikelkennung lässt sich der Pass nicht verlässlich auffinden. Die Kennung muss über alle Systeme hinweg dieselbe sein.
- Doppelte Datenhaltung: Wird der Pass in einer separaten Lösung manuell gepflegt, driften die Stände auseinander. Die führende Quelle bleibt im Fachsystem.
- Datenträger ohne Standardbezug: Ein QR-Code, der nicht als GS1 Digital Link aufgebaut ist, erschwert die branchenübergreifende Auflösung (GS1 Germany).
- Warengruppe zu spät geprüft: Wer erst mit Erscheinen des delegierten Rechtsakts beginnt, gerät unter Zeitdruck. Die betroffene Warengruppe und ihr Zeithorizont sollten früh geklärt sein (Europäische Kommission).
- Zugriffssteuerung nachgelagert: Werden Rollen und Sichten erst nachträglich ergänzt, muss die API aufwendig umgebaut werden. Die Rechte gehören ins Design.
Der Digitale Produktpass ist kein neues Datensilo, sondern eine Sicht auf vorhandene Produktdaten. Wer ihn aus ERP und PIM speist, erfüllt die Pflicht und verbessert zugleich die Qualität seiner Stammdaten.
Projektansatz: Frühzeitig aus den Bestandssystemen aufbauen
Ein DPP-Projekt lässt sich strukturiert angehen, wenn die Datenbasis früh im Mittelpunkt steht. Der erste Schritt ist keine Softwareauswahl, sondern eine Bestandsaufnahme: Welche der geforderten Angaben liegen bereits vor, wo, und in welcher Qualität? Erst danach folgt die technische Umsetzung.
1. Warengruppe und Datencheck
Klärung des Zeithorizonts für die eigene Warengruppe und Abgleich der geforderten Felder mit dem vorhandenen Datenbestand in ERP und PIM.
2. Datenmodell und Mapping
Abbildung der Felder auf das DPP-Modell nach CIRPASS und Festlegung der Identifier-Strategie mit GTIN und GS1 Digital Link.
3. Middleware und API
Aufbau der Aggregationsschicht, die ERP- und PIM-Daten zusammenführt, validiert und über eine rollenbasierte API bereitstellt.
4. Datenträger und Test
Erzeugung der QR-Codes, Prüfung der Auflösung auf den Datensatz und Parallelbetrieb vor dem jeweiligen Stichtag.
Wer die Produktpass-Schnittstelle in eine größere Integrationsstrategie einbetten möchte, findet weiterführende Ansätze im Beitrag zur Anbindung der Warenwirtschaft an den Shop sowie in der Übersicht unserer Integrationsleistungen. Der Digitale Produktpass reiht sich damit in dieselbe Logik ein wie andere Compliance-Themen -- etwa die E-Rechnungspflicht ab 2027, bei der ebenfalls strukturierte Daten aus den Bestandssystemen erzeugt werden.
Quellen und Studien