Kann ich den Produktpass mit meinem ERP- oder Bestandssystem verbinden?

Die Verknüpfung wird erst konkret, wenn es den technischen Standard gibt

Eine direkte Verknüpfung zwischen dem digitalen Produktpass und einem ERP- oder Bestandsverwaltungssystem ist derzeit nicht möglich, da die technischen Spezifikationen dafür noch nicht festgelegt wurden. Die ESPR (Verordnung (EU) 2024/1781) legt in Artikel 10 und Artikel 11 zwar die Grundlagen fest: Der Pass muss interoperabel sein, auf offenen Standards basieren und maschinenlesbar sein. Das bedeutet, dass der automatisierte Datenaustausch mit Unternehmenssystemen letztendlich der Standard sein wird, nicht eine Ausnahme. Aber wie dieser Austausch in der Praxis aussieht – welches Dateiformat, welche Schnittstelle, welche Zugriffsrechte – ergibt sich erst aus delegierten Rechtsakten pro Produktgruppe. Für Eisen und Stahl gibt es diesen Rechtsakt noch nicht.

Wofür dies gilt und wofür nicht

Dies betrifft die Frage, ob Systeme künftig automatisch Daten aus dem Pass abrufen oder in ihn schreiben können. Das betrifft die technische Ausgestaltung des Passes selbst, wie sie in der Verordnung beschrieben wird: wie er aufgebaut ist, wer Zugriff hat und in welcher Form die Daten verfügbar sind. Es geht nicht um die Frage, ob ein bestimmtes ERP-Paket geeignet ist, und auch nicht um eine konkrete API oder ein Datenformat – diese Entscheidungen sind noch nicht getroffen. Es geht auch nicht um die Verpflichtung selbst, einen Pass zu haben; das ist ein separates Thema, das pro Produktgruppe ausgefüllt wird. Was hier beschrieben wird, ist ausschließlich das Prinzip, dass der Pass maschinenlesbar und interoperabel sein muss – wie dieses Prinzip für Eisen und Stahl konkret umgesetzt wird, steht noch offen.

Noch kein festes Datum, noch kein fester technischer Standard

Es gibt noch kein Datum, an dem ein technischer Kopplungsstandard für Eisen und Stahl in Kraft tritt, da dieser Standard Teil des noch zu erlassenden delegierten Rechtsakts ist. Nach dem Aktionsplan der ESPR für den Zeitraum 2025-2030 wird der erste delegierte Rechtsakt 2026 erwartet, mit Verpflichtungen, die danach eine Anlaufzeit von achtzehn Monaten haben. Solange dieser Rechtsakt nicht vorliegt, ist klar, dass der Pass interoperabel und maschinenlesbar sein muss (Artikel 10 und 11), aber nicht, wie dies technisch umgesetzt wird. Bis dahin funktioniert der Pass in der Praxis als ein von Menschen zu konsultierendes Dokument über den QR-Datenträger, nicht als ein automatisierter Datenstrom zu einem externen System.

Was dies für den Ansatz bedeutet

Für diejenigen, die bereits über die Verknüpfung mit einem eigenen System nachdenken, ist die Reihenfolge wie folgt. Erstens: Es muss jetzt noch nichts gebaut werden, da es keinen Standard gibt, gegen den man entwickeln kann. Zweitens: Die eigenen Produktdaten in Ordnung zu bringen ist jetzt schon sinnvoll, unabhängig von der endgültigen technischen Form – ein übersichtlicher, konsistenter Satz von Daten pro Produkt (Herkunft, Zusammensetzung, Zertifikate) ist die Grundlage, auf die sich jeder zukünftige Kopplungsmechanismus stützen wird. Drittens: Sobald der delegierte Rechtsakt für Eisen und Stahl vorliegt, wird darin deutlich, welches Format und welche Zugangsweise gelten, und erst dann kann eine konkrete Verknüpfung geplant werden. Viertens: Bis dahin bleibt der Pass über den QR-Code, der am Produkt angebracht ist, einsehbar, was für die meisten alltäglichen Transaktionen im Stahlhandel und der Metallverarbeitung bereits ausreichend ist – die Verknüpfung mit einem ERP-System ist dann ein Effizienzgewinn für später, keine Voraussetzung, um jetzt mit dem Pass arbeiten zu können.

Woraus dies folgt: Artikel 10 und 11 der ESPR

Artikel 10 der ESPR (Verordnung (EU) 2024/1781) beschreibt die Anforderungen, denen das digitale Produktpass genügen muss, einschließlich Interoperabilität und der Verwendung offener Standards. Artikel 11 befasst sich mit dem technischen Design und der Funktionsweise des Passes, wie die Register, der Datenzugriff und die Art und Weise, wie der Pass funktioniert. Beide Artikel enthalten das Prinzip, dass der Pass für die maschinelle Verarbeitung geeignet sein muss, aber die Ausarbeitung — die tatsächliche technische Spezifikation pro Produktgruppe — wird an delegierte Rechtsakte überlassen, die noch erscheinen müssen. Für die genaue Formulierung ist der offizielle Text der Verordnung maßgeblich.

Wer jetzt schon vorausplanen möchte, kann am besten die eigenen Produktdaten bereits strukturiert und vollständig erfassen, damit diese in dem Moment, in dem der technische Standard veröffentlicht wird, ohne großen Aufwand an das angepasst werden kann, was dann festgelegt wird. Diese Seite wird aktualisiert, sobald die delegierte Handlung für Eisen und Stahl veröffentlicht wurde und die technischen Details bekannt sind.

Worauf dies basiert

Die Verordnung selbst befindet sich auf EUR-Lex. Wir verweisen je Aussage; Sie müssen uns nicht glauben.

Was Sie konkret tun müssen

Was von Ihnen erwartet wird

Daten müssen maschinenlesbar und übertragbar sein

Artikel 10 der ESPR (Verordnung (EU) 2024/1781) schreibt vor, dass die Daten im digitalen Produktpass in einem strukturierten, maschinenlesbaren Format verfügbar sein müssen. Das ist gleichzeitig der Ansatzpunkt für die Kopplung mit einem eigenen System: Daten, die maschinenlesbar sind, eignen sich grundsätzlich auch dazu, automatisch in oder aus einem ERP- oder Lagerverwaltungssystem zu fließen. Für ein Unternehmen mit 10 bis 100 Mitarbeitern bedeutet dies vor allem, dass die Frage "kann dies gekoppelt werden" in erster Linie keine rechtliche Frage ist, sondern eine technische: Welches Format nutzt der Pass, und kann die eigene Software dieses Format lesen oder schreiben. Siehe auch die Seite über in welchem Format muss ich die Daten für den Produktpass bereitstellen.

Der Pass muss sich an eine einheitliche technische Struktur anschließen

Artikel 11 der ESPR befasst sich mit der technischen Ausgestaltung und Funktionsweise des Passes und verweist auf technische Spezifikationen, die die Kommission weiter ausarbeitet. Für die Praxis der Kopplung bedeutet dies, dass nicht einfach "eine eigene Datei" bereitgestellt oder abgerufen werden kann: Darunter liegt eine standardisierte Struktur, wahrscheinlich basierend auf bestehenden Identifizierungssystemen. Wer bereits mit einem System für Artikelcodierung arbeitet, sollte überprüfen, wie es sich an die Art anpasst, wie später eindeutige Identifizierungscodes vergeben werden — siehe wie vergebe ich jedem Produkt einen eindeutigen Identifizierungscode. Ein ERP-System, das bereits mit eindeutigen, stabilen Produktcodes arbeitet, hat für die Kopplung bessere Voraussetzungen als ein System, bei dem Codes pro Auftrag oder pro Kunde unterschiedlich sind.

Die Kopplung erfolgt über einen Datenträger, nicht über eine direkte Datenbankverbindung

Artikel 11 beschreibt auch, dass der Pass über einen Datenträger auf dem Produkt zugänglich ist. Das ist ein wichtiger Punkt für die Erwartung, die ein Unternehmen an "Kopplung" haben darf: Es geht nicht um eine unmittelbare Datenbankverbindung zwischen zwei Unternehmen, sondern um eine Kette, in der der Datenträger (normalerweise ein QR-Code) auf einen gespeicherten Pass verweist. Die Kopplung mit einem ERP- oder Lagerverwaltungssystem findet also an zwei Stellen statt: bei der Bereitstellung von Produktdaten aus dem eigenen System an die Partei, die den Pass zusammenstellt, und beim Einlesen von Passdaten (beispielsweise beim Kauf von Stahl) in das eigene System. Mehr über diesen Datenträger finden Sie auf der Seite wie kommt der QR-Code für das Produktpaspoort auf meinen Stahl.

Daten müssen so lange aktuell bleiben, wie der Pass existiert

Aus Artikel 10 folgt auch, dass Daten im Pass korrekt und aktuell sein müssen, solange der Pass existiert. Für eine Kopplung mit einem Lagerverwaltungssystem bedeutet dies, dass eine einmalige Bereitstellung meist nicht ausreicht: Wenn sich Eigenschaften einer Stahlpartie ändern oder ein Fehler entdeckt wird, muss es eine Möglichkeit geben, dies der Stelle mitzuteilen, wo der Pass gehostet wird. Unternehmen, die ihr ERP-System koppeln, sollten dabei auch überprüfen, wie lange diese Aktualität aufrechterhalten werden muss — siehe wie lange muss ein Produktpass verfügbar bleiben.

Wo es in der Praxis schiefgeht

Interne Artikelcodes werden mit der offiziellen Produktidentifikation verwechselt. Ein ERP-System kennt ein Produkt unter einer internen SKU, während der Pass einen anderen, eindeutigen Identifizierungscode benötigt. Ohne eine Übersetzungstabelle zwischen beiden entsteht Verwirrung beim Koppeln, besonders wenn ein interner Code mehrere Partien abdeckt.

Bestandsmutationen werden nicht in die Passdaten übertragen. Ein Lagerverwaltungssystem verzeichnet beispielsweise, dass eine Stahlpartie umgeschmolzen, aufgeteilt oder zusammengefasst wurde, aber diese Änderung erreicht den Pass nicht automatisch. Dies spielt eine große Rolle bei der Frage, ob Stahl pro Charge oder pro Stück erfasst wird — siehe erfasse ich Stahl pro Charge oder pro Stück — denn die Erfassungseinheit im ERP-System muss mit der Einheit übereinstimmen, auf der der Pass basiert.

Exportdateien aus dem ERP-System entsprechen nicht dem erforderlichen Format. Viele ERP-Pakete exportieren standardmäßig in Excel, CSV oder einer eigenen XML-Struktur. Ohne vorherige Abstimmung erweist sich eine solche Datei als inkompatibel mit dem für das Passierschein erforderlichen Format, was zu Verzögerungen und zusätzlicher manueller Arbeit führt.

Es wird davon ausgegangen, dass die Schnittstelle auch ohne Internetverbindung funktioniert. Einige Bestandssysteme auf der Werksebene laufen teilweise offline, beispielsweise auf einem Lagerterminal. Dies wirft die Frage auf, ob das Passierschein selbst auch ohne Verbindung abrufbar sein muss; dies ist eine separate Frage, die von der Schnittstelle zum ERP-System unabhängig ist. Siehe muss der Produktpass auch ohne Internetverbindung funktionieren.

Zugriffsrechte zwischen Systemen werden nicht geregelt. Eine Schnittstelle bedeutet, dass Daten zwischen zwei oder mehr Systemen fließen, häufig über einen Dritten, der das Passierschein hostet. Wenn nicht festgelegt ist, wer welche Daten einsehen, ändern oder weitergeben darf, entsteht Unklarheit über die Verantwortung im Fehlerfall — eine Frage, die sich auf die Sicherung der Daten während der Übertragung auswirkt, siehe wie stelle ich sicher, dass die Daten im Produktpass sicher sind.

Was Sie festhalten können

Eine Übersicht darüber, welche Felder im ERP- oder Bestandssystem welchen Feldern im Produktpass entsprechen, einschließlich einer Übersetzungstabelle zwischen internen Artikelnummern und dem eindeutigen Produktidentifizierungscode.
Eine Beschreibung des Exportformats, das das eigene System verwendet, und ein Vergleich mit dem Format, das für das Passierschein erforderlich ist.
Absprachen mit der Partei, die das Passierschein zusammenstellt oder hostet, über die Häufigkeit und Art des Datenaustausches: einmalig bei der Erstellung oder laufend bei Änderungen.
Ein Verfahren zur Mitteilung von Änderungen bei Bestandsverfügbarkeit, Chargeneinteilung oder Produkteigenschaften an die Passierschein-Daten, einschließlich der Verantwortung dafür.
Eine Übersicht darüber, wer im Unternehmen Zugriff auf die Schnittstelle zwischen dem eigenen System und dem Passierschein hat, und welche Rechte damit verbunden sind.
Eine vereinbarte Regelung darüber, was mit der Schnittstelle und dem Datenstrom geschieht, wenn das Passierschein für ein Produkt geändert, widerrufen oder ersetzt wird.

Dies ist keine Rechtsberatung. Diese Seite bietet allgemeine Informationen zur Regelung, die diese Plattform betrifft. Wir kennen Ihre Situation nicht. Im Zweifelsfall hinsichtlich Ihres speziellen Falls konsultieren Sie bitte einen Juristen oder die zuständige Überwachungsbehörde.

Mit KI geschrieben auf Grundlage der obigen Quellen, überprüft durch eine Person am 2026-08-22. Stimmt etwas nicht? Teilen Sie es uns mit — Korrektionen werden bevorzugt behandelt.