TL;DR. Ein digitaler Produktpass (DPP) wird ab 2027 für viele Produktgruppen zur EU-Pflicht. Welche Daten in einen digitaler Produktpass müssen, wie die technische Architektur aussieht und was die Umsetzung in PIM, ERP und Shop kostet, klären wir hier. Ein digitaler Produktpass ist kein QR-Code-Projekt, sondern ein Datenmodell-Projekt.
Der Digitale Produktpass ist keine ferne EU-Idee mehr, sondern beschlossenes Recht. Die Verordnung steht, die ersten Produktgruppen sind definiert, die Fristen laufen. Wer 2026 erst anfängt darüber nachzudenken, ist spät dran. Wir bauen seit Jahren Shops und Headless-Integrationen für Hersteller und Händler, die genau jetzt die Frage stellen: Was müssen wir wirklich tun, was ist Hype und wo fängt man technisch an? Dieser Artikel gibt die ehrliche Antwort.
Inhalt
- Was ist der Digitale Produktpass?
- Wer ist wann betroffen?
- Welche Daten muss der DPP enthalten?
- Wo liegt das eigentliche Problem? Nicht der QR-Code.
- Wie sieht die technische Architektur aus?
- PIM, ERP, Shop: Wer liefert was?
- Was kostet die DPP-Umsetzung?
- Was wir gerade in Projekten sehen
Was ist der Digitale Produktpass?
Der Digitale Produktpass (DPP, englisch Digital Product Passport) ist ein strukturierter, maschinenlesbarer Datensatz, der einem physischen Produkt eindeutig zugeordnet ist. Zugriff erfolgt über einen Datenträger am Produkt, meist einen QR-Code oder RFID-Chip, der auf eine standardisierte URL oder API führt. Der Datensatz enthält Informationen zu Material, Herkunft, Reparierbarkeit, Recyclingfähigkeit und CO₂-Fußabdruck.
Rechtliche Grundlage ist die EU-Ökodesign-Verordnung für nachhaltige Produkte (ESPR), die 2024 verabschiedet wurde. ESPR ist der Rahmen. Die konkreten Anforderungen pro Produktgruppe werden über delegierte Rechtsakte festgelegt. Parallel dazu gibt es produktspezifische Regelungen, etwa die EU-Batterieverordnung, die einen eigenen Battery Passport vorschreibt.
Der Kern in einem Satz: Jedes Produkt bekommt eine digitale Akte, die über seinen gesamten Lebenszyklus konsistent bleibt und für Behörden, Handel, Reparaturbetriebe, Recycler und Endkunden abrufbar ist.
Wer ist wann betroffen?
Das ist die Frage, die in jedem Workshop zuerst kommt. Und wo im Netz die meiste Verwirrung herrscht. Deshalb die nüchterne Einordnung:
- Batterien (Industrie- und EV-Batterien über 2 kWh): Battery Passport ab Februar 2027. Das ist die erste harte Frist und läuft über die Batterieverordnung, nicht über ESPR.
- Textilien: In der ersten Welle des ESPR-Arbeitsplans. Delegierter Rechtsakt wird vorbereitet, Pflicht voraussichtlich 2027 bis 2028.
- Eisen, Stahl, Aluminium: Ebenfalls erste Welle. Für B2B-Hersteller besonders relevant.
- Möbel, Reifen, Waschmittel: In Vorbereitung.
- Elektronik, Bauprodukte: Eigene Regelwerke, Details noch in Arbeit.
- Spielzeug: Neue Toy Safety Regulation verlangt DPP bis spätestens 2028.
Was du nicht liest: Eine pauschale Pflicht für "alle Produkte ab 2027". Diese Aussage geistert durch viele Artikel, ist aber falsch. ESPR wird produktgruppenweise ausgerollt. Bis alle priorisierten Gruppen abgedeckt sind, sind wir realistisch bei 2030.
Bedeutet für dich: Schau dir dein Sortiment an und ordne jede Produktkategorie einer Welle zu. Daraus ergibt sich dein interner Fahrplan. Wer Batterien oder Textilien verkauft, muss jetzt liefern. Wer Hundefutter verkauft, hat mehr Zeit.
Welche Daten muss der DPP enthalten?
Die genaue Datenstruktur wird pro Produktgruppe festgelegt, aber es gibt einen Kern, der in allen Entwürfen auftaucht:
- Produktidentifikation: Eindeutige ID (meist GS1 Digital Link), Modell, Seriennummer bei relevanten Produkten
- Materialzusammensetzung: Rohstoffe, chemische Zusammensetzung, Anteil recycelter Materialien
- Herkunft und Lieferkette: Herstellungsort, Lieferanten bei kritischen Komponenten
- Umweltdaten: CO₂-Fußabdruck, Energieverbrauch in der Nutzung, Wasserverbrauch
- Reparatur und Ersatzteile: Reparaturanleitungen, Ersatzteilverfügbarkeit, Reparierbarkeitsindex
- Recyclingfähigkeit: Demontagehinweise, Sortierhinweise, Entsorgungswege
- Compliance-Dokumente: Konformitätserklärungen, Zertifikate, Prüfberichte
Zugriffsrechte sind dabei granular. Endkunden sehen eine vereinfachte Ansicht. Behörden, Recycler und Reparaturbetriebe bekommen tiefere Daten. Lieferanten-sensible Informationen bleiben geschützt. Das ist ein eigenes Rollen- und Rechtekonzept, das in der Architektur frühzeitig mitgedacht werden muss.
Unser Hinweis: Die meisten Hersteller haben diese Daten schon, aber verstreut über Excel, PIM, ERP, PDF-Datenblätter und Mails mit Lieferanten. Das Datenmodell zusammenzuführen ist 80 Prozent der Arbeit. Der QR-Code am Produkt ist die letzten 5 Prozent.
Wo liegt das eigentliche Problem? Nicht der QR-Code.
Viele DPP-Angebote im Markt lösen das falsche Problem. Sie generieren einen QR-Code, legen eine hübsche Landingpage darunter und verkaufen das als "DPP-ready". Technisch ist das in zwei Tagen gebaut. Praktisch löst es null deiner echten Probleme.
Das echte Problem ist die Datenkonsistenz über Systeme und Zeit hinweg. Konkret:
- Daten-Herkunft: Wer ist Source of Truth für welches Attribut? PIM für Marketing-Daten, ERP für Lieferanten-IDs, Labor für Materialdaten, externes Tool für CO₂-Bilanz. Ohne klare Datenherkunft baust du ein Kartenhaus.
- Versionierung: Der DPP muss den Zustand zum Zeitpunkt des Inverkehrbringens dokumentieren. Wenn du dein Produkt 2028 änderst, muss der Pass für 2027-Produkte unverändert abrufbar bleiben. Zehn Jahre lang. Mindestens.
- Lieferanten-Daten: Deine CO₂-Daten sind oft nur so gut wie die Daten deiner Lieferanten. Die liefern aber heute Excel per Mail. Du brauchst einen Prozess und eine Schnittstelle, um das zu automatisieren.
- Multi-Language und Multi-Market: Pflichtangaben je nach Zielmarkt, Sprache, Produktvariante. Skaliert nur, wenn es strukturiert aus einem zentralen System kommt.
- Endpunkt-Stabilität: Die URL hinter dem QR-Code muss Jahrzehnte stabil sein. Kein Shop-Replatforming, kein Domain-Wechsel, kein CMS-Umbau darf den Zugriff brechen.
Wer den DPP als Marketing-Feature denkt, wird die Compliance-Seite unterschätzen. Und wer ihn rein als Compliance-Thema denkt, verschenkt das Business-Potential: Reparaturservice, Second-Life-Markt, Kundenbindung nach dem Kauf.
Wie sieht die technische Architektur aus?
In unseren Projekten läuft es auf drei Muster hinaus, je nach Ausgangslage und Sortiment.
Muster 1: PIM-zentriert
Das PIM ist Hub für alle produktbezogenen Daten. DPP-Daten werden als eigene Attributgruppen modelliert. Ausleitung über eine stabile API an einen separaten DPP-Service, der die öffentlichen Endpunkte bereitstellt. Shop bleibt konsumierender Layer.
Passt für: Hersteller mit ausgebautem PIM, mittlere bis große Sortimente, viel Produktvarianz.
Muster 2: Dedizierter DPP-Service neben dem Shop
Eigener Microservice, der die DPP-Endpunkte hostet. PIM und ERP schieben Daten via Event-Bus oder Batch in den Service. Datenträger-URL zeigt nicht auf den Shop, sondern auf den DPP-Service. Vorteil: Shop-Replatforming oder Domain-Wechsel brechen den Pass nicht.
Passt für: Unternehmen mit mehreren Vertriebskanälen, Marken-Setup mit mehreren Shops, Zukunftssicherheit im Vordergrund.
Muster 3: Plattform-Integration
Nutzung einer DPP-Plattform wie CIRCULARISE, Madaster, Circulor oder Aware. Eigene Systeme liefern Daten per API rein, die Plattform übernimmt öffentliche Bereitstellung, Versionierung und Zugriffssteuerung.
Passt für: Unternehmen, die schnell loslegen müssen und keine eigene Architektur aufbauen wollen. Nachteil: Abhängigkeit vom Anbieter.
In allen drei Mustern bauen wir den DPP Headless. Die öffentliche Ansicht ist ein minimaler Frontend-Layer, der rein eine API konsumiert. Das hält die Architektur austauschbar und skalierbar. Wenn du deinen Shop auf Shopware Headless oder commercetools betreibst, ist die Anschlussstelle sowieso schon da.
PIM, ERP, Shop: Wer liefert was?
Eine der häufigsten Fragen im Scoping. Faustregel:
- ERP: Artikelstamm, Lieferanten-IDs, Chargen, Seriennummern, interne IDs
- PIM: Marketing- und Produktattribute, Sprachvarianten, Medien, Varianten, Materialdaten, Klassifizierungen
- LCA-Tools / CO₂-Rechner: Umweltbilanz, Impact-Daten (z.B. über ecoinvent, SimaPro, externe Dienstleister)
- Dokumenten-Management: Konformitätserklärungen, Zertifikate, Testberichte
- Lieferantenportal / SRM: Upstream-Daten für Materialherkunft, Compliance-Statements
- Shop: Endkunden-Ansicht, Übergabe an Checkout, Nutzererlebnis. Nicht Source of Truth für DPP-Pflichtdaten.
Wenn du noch kein ausgebautes PIM-Setup hast, ist DPP genau der Auslöser, der das jetzt erzwingt. Wer versucht, DPP direkt im Shop zu modellieren, baut sich Altlasten fürs nächste Replatforming.
Was kostet die DPP-Umsetzung?
Pauschalpreise nennen wir bewusst nicht, weil die Spannweite riesig ist und vom Ausgangsstack abhängt. Aber als Orientierung, was wir in unseren Projekten sehen:
- Datenmodell-Audit und Gap-Analyse: ab 10.000+ EUR. Inventur deiner Daten, Mapping auf DPP-Anforderungen, Lücken identifizieren.
- PIM-Erweiterung um DPP-Attribute: ab 15.000+ EUR. Hängt stark davon ab, ob ein PIM existiert und wie sauber es gepflegt ist.
- DPP-Service als eigener Microservice: 40.000+ EUR, bei komplexen Sortimenten schnell 100.000+ EUR. Öffentliche API, Versionierung, Zugriffsrollen, Admin-UI.
- Lieferanten-Anbindung: 20.000+ EUR, bei vielen Lieferanten und tiefer Integration Richtung 100.000+ EUR.
- QR-Code-Integration in Produktkennzeichnung: Verpackungs- und Produktionsseitig, oft über bestehende Etiketten-Prozesse, niedrig fünfstellig.
- Laufende Pflege: ab 2.000+ EUR monatlich, abhängig von Sortiment und Update-Frequenz.
Kostentreiber Nummer eins ist in jedem Projekt die Datenqualität. Wer saubere Stammdaten und ein gepflegtes PIM hat, kommt deutlich günstiger weg. Wer sein Sortiment noch in Excel verwaltet, hat einen unsichtbaren Zusatzposten für das Aufräumen.
Was wir gerade in Projekten sehen
Drei Muster, die in unseren DPP-Workshops immer wieder auftauchen:
1. "Das lösen wir später." Die Batterieverordnung ist bereits in Kraft und greift Anfang 2027. Wer jetzt noch nicht weiß, wie sein digitaler Produktpass strukturiert sein muss, wird nicht rechtzeitig fertig. Ein sauberes DPP-Projekt dauert in unseren Projekten 6 bis 12 Monate, abhängig vom Ausgangsstack.
2. "Das macht unser Shopsystem." Shopsysteme sind keine DPP-Plattformen. Shopware, Shopify, commercetools können DPP-Daten anzeigen und einen QR-Code ausspielen, aber sie sind nicht der richtige Ort für die dauerhafte Datenhaltung und Versionierung. Wer DPP im Shop zentralisiert, baut Altlasten. Deshalb: Datenhaltung separat, Shop konsumiert.
3. "Wir kaufen eine Plattform und sind fertig." DPP-Plattformen sind ein sinnvoller Baustein, aber kein Komplettpaket. Die Daten müssen trotzdem sauber aus PIM, ERP und Lieferanten-Systemen kommen. Die Plattform liefert das Dach, nicht das Fundament.
In einem aktuellen Projekt bauen wir für einen Textilhersteller den DPP als eigenen Service neben dem Shopware 6 Shop. Daten kommen aus Storyblok für redaktionelle Inhalte, aus dem PIM für Stammdaten und aus einem externen LCA-Tool für Umweltdaten. Der Pass ist über eine eigene Subdomain abrufbar, stabil und vom Shop entkoppelt. Das ist der Ansatz, der auch Replatforming in fünf Jahren überlebt.
Fazit: DPP ist ein Datenprojekt mit einem kleinen Frontend
Der Digitale Produktpass wird gerne als neues Feature für den Online-Shop verkauft. In Wahrheit ist er ein Datenprojekt. Das Frontend, also der QR-Code und die Detailseite, ist der einfachste Teil. Die Arbeit liegt in Datenmodell, Systemintegration, Lieferanten-Anbindung und Versionierung. Wer das jetzt sauber aufsetzt, hat in fünf Jahren ein Asset. Wer abkürzt, baut Technical Debt, die spätestens beim nächsten Replatforming schmerzt.
Unser Rat: Fang nicht mit dem QR-Code an, fang mit dem Datenmodell an. Mach eine ehrliche Gap-Analyse. Bau die Architektur austauschbar. Und halte den Shop raus aus der Rolle der Source of Truth.