Rückverfolgbarkeit

Im Kern bezeichnet Rückverfolgbarkeit – im Englischen als Traceability bekannt – die Fähigkeit, den Weg eines Produkts, einer Charge oder eines Rohstoffs entlang der gesamten Lieferkette jederzeit nachvollziehen zu können. Das Konzept umfasst dabei die vollständige Produktgenealogie: Wer hat wann was von wem bezogen, weiterverarbeitet oder weitergegeben? Entscheidend ist, dass es sich um ein durchgehend gepflegtes Informationssystem über alle Stationen hinweg handelt – und keine einmalige Dokumentation.

Die Verordnung (EG) 178/2002, in Kraft getreten am 28. Januar 2002 und mit verbindlicher Anwendungspflicht ab dem 1. Januar 2005, regelt genau diesen Anspruch: Sie verpflichtet Unternehmen zur lückenlosen Nachvollziehbarkeit von der Urproduktion bis zur letzten Verkaufsstelle, dem sogenannten Point of Sale. Wichtig ist dabei die Abgrenzung zu bloßer Kennzeichnung: Losnummer, Chargennummer oder Mindesthaltbarkeitsdatum sind technische Voraussetzungen – Rückverfolgbarkeit ist das übergeordnete System, das diese Angaben in einem strukturierten Informationsfluss zusammenführt. Als international anerkannter Rahmen für den systematischen Aufbau solcher Traceability-Managementsysteme gilt die ISO 22005, erstveröffentlicht im Jahr 2007, ohne dass daraus eine allgemeine Zertifizierungspflicht folgt.

Innerhalb eines Traceability-Systems lassen sich zwei komplementäre Verfahren unterscheiden, die in der Praxis gemeinsam unter dem Begriff Tracking und Tracing zusammengefasst werden, operativ jedoch entgegengesetzte Richtungen adressieren. Tracking bezeichnet die Vorwärtsverfolgung entlang der Lieferkette – also die Fähigkeit, ausgehend von einem bekannten Ausgangspunkt zu ermitteln, wohin ein Produkt oder eine Charge weitergegeben wurde (downstream). Die umgekehrte Frage – woher stammt dieses Produkt, welcher Charge gehört es an, welcher Vorlieferant hat es bereitgestellt – beantwortet das Tracing als gezielte Rückwärtsverfolgung (upstream).

In diesem Kontext wird der Begriff Reverse Traceability bewusst als systematische Rückverfolgung zu Herkunft, Charge und Lieferant verstanden – ausdrücklich nicht als Retourenprozess. Beide Richtungen greifen auf dieselben strukturierten Datenpunkte zurück, die an jeder Station der Lieferkette sauber erfasst und weitergegeben werden müssen. Die gesetzlichen Mindestanforderungen an diesen Datenpfad sind im Abschnitt zum Rechtsrahmen ausgeführt (→ Rechtsrahmen).

Downstream-Tracking entfaltet seinen praktischen Nutzen nicht in der Richtungserklärung, sondern in der Präzision der je Stationstyp erfassten Datenpunkte. Am Produktionsstandort werden Chargennummer, GTIN und Produktionsdatum als Ausgangsereignis angelegt. Beim Übergang auf den Spediteur tritt der SSCC der Versandeinheit als Einheitenidentifikator hinzu (→ Abschnitt SSCC/NVE). Im Distributionszentrum werden Eingangsscan, Einlagerungsposition und gegebenenfalls eine Umlagerungscharge erfasst; beim Handelsempfänger schließt ein Wareneingangsscan den Datenpfad mit Empfangsdatum und Bestellreferenz ab.

Für besonders hochwertige oder sicherheitskritische Produkte bietet die SGTIN (Serialized GTIN) eine Erweiterungsoption: Sie ergänzt die chargenbasierte Verfolgung um eine eindeutige Seriennummer je Einzelstück und ermöglicht damit eine lückenlose Genealogie bis auf Stückebene, unabhängig vom Chargenkontext. Wo die SGTIN eingesetzt wird, kann jede Einheit als eigenständiges Verfolgungsobjekt behandelt werden – auch wenn sie im Verlauf der Lieferkette von einer Versandeinheit in eine andere wechselt. Ein regulatorisch verbindlicher Anwendungsfall ergibt sich im Bereich Medizinprodukte: Die EU-Verordnung 2017/745 (EU-MDR) schreibt für Medizinprodukte ab Klasse I eine Unique Device Identification (UDI) vor, die auf Trägerbasis der SGTIN-Logik folgt. Jedes Gerät muss mit einem maschinenlesbaren UDI-Träger versehen sein, der sowohl die Produktkennung (DI, entspricht der GTIN-Ebene) als auch die Produktionskennung (PI, entspricht der Seriennummer- bzw. Chargenebene) enthält. Die UDI-Daten sind in der europäischen EUDAMED-Datenbank zu hinterlegen – womit die stückgenaue Rückverfolgbarkeit in diesem Segment nicht mehr eine Optimierungsoption, sondern eine gesetzliche Mindestanforderung ist.

Die Upstream-Verfolgung stellt in der Praxis höhere Anforderungen an die Rückverfolgbarkeit als das Vorwärts-Tracking, weil reale Produktionsprozesse selten eine lineare Eins-zu-eins-Zuordnung von Eingangs- zu Ausgangscharge erlauben. Drei Konstellationen erschweren die Chargenrückverfolgung strukturell:

Lot-Splitting bezeichnet die Aufteilung einer Eingangscharge auf mehrere Ausgangschargen – etwa wenn ein Rohstoffgebinde für zwei Produktionsläufe genutzt wird. Das Tracing muss in diesem Fall beide Ausgangschargen der gemeinsamen Ursprungscharge zuordnen können. Noch komplexer ist das Mischchargen-Problem (Multi-Ingredient-Problem): Wenn Zutaten aus unterschiedlichen Lieferchargen in einem Produktionsschritt zusammengeführt werden, entstehen Ausgangschargen, die auf mehrere Herkunftschargen zurückweisen. Ohne explizite Dokumentation dieser n-zu-m-Beziehungen im System lässt sich die Produktgenealogie rückwärts nicht mehr vollständig rekonstruieren. Drittens entstehen Lücken bei Chargenzusammenführungen in der Logistik, wenn Paletten mit unterschiedlichen Produktionschargen derselben GTIN gemeinsam umgelagert werden, ohne dass die Chargenreferenz je Handelseinheit erhalten bleibt.

Eine vierte Komplexitätskonstellation entsteht bei grenzüberschreitenden Chargen-Splits: Wird eine Eingangscharge auf Produktionsstätten in verschiedenen Ländern aufgeteilt – etwa EU und UK nach dem Brexit –, treffen unterschiedliche nationale Rückverfolgungsanforderungen und Aufbewahrungsfristen aufeinander. Im Vereinigten Königreich gelten seit 2021 eigenständige Retained-Law-Regelungen, die inhaltlich weitgehend mit EU-Recht übereinstimmen, jedoch national durchgesetzt werden und im Einzelfall abweichende Dokumentationspflichten begründen können. Ein Tracing-System muss diese Divergenz für jede Teilcharge kennen und die jeweils gültige Rechtsgrundlage hinterlegen.

Diese vier Komplexitätskonstellationen zeigen, dass Upstream-Tracing keine Frage der Datenverfügbarkeit allein ist, sondern eine der strukturellen Modellierungsentscheidungen. ISO 22005 Kapitel 5 verlangt ausdrücklich, dass die Transformationsbeziehungen zwischen Eingangs- und Ausgangseinheit als explizite Systemkomponente definiert werden – nicht als nachträgliche Rekonstruktion. Welche dieser Beziehungen das System von Beginn an abbilden kann, bestimmt, wie weit die Rückverfolgbarkeit im Ereignisfall tatsächlich reicht (→ Chargenkennzeichnung und Stammdaten).

Die gesetzliche Pflicht zur Rückverfolgbarkeit im Lebensmittelbereich fußt in der Europäischen Union auf Artikel 18 der Verordnung (EG) 178/2002 – dem sogenannten General Food Law. Diese Verordnung regelt die allgemeinen Grundsätze und Erfordernisse des Lebensmittelrechts und schreibt die Nachvollziehbarkeit von der Urproduktion bis zur letzten Verkaufsstelle, dem Point of Sale, verbindlich vor. Seit dem 1. Januar 2005 sind alle Unternehmen, die Lebensmittel, Lebensmittelzutaten, futtermittelrelevante Stoffe oder Tiere in den Verkehr bringen oder verarbeiten, verpflichtet, ein entsprechendes System einzurichten und dauerhaft aufrechtzuerhalten.

Das operative Kernprinzip lautet dabei „one step back – one step forward": Jedes Unternehmen muss seinen unmittelbaren Vorlieferanten identifizieren und dokumentieren können sowie wissen, an wen es geliefert hat. Diese Pflicht gilt stufenübergreifend – von der Landwirtschaft über Verarbeitung, Lagerung und Handel bis zur Logistik.

Bemerkenswert ist dabei der normative Charakter von Art. 18: Die Verordnung schreibt das Ergebnis vor – lückenlose Nachvollziehbarkeit –, nicht die technische Methode, mit der dieses Ergebnis erreicht wird. Ob Barcode, RFID, papierbasierende Chargenliste oder EPCIS-Integration: Der Gesetzgeber überlässt die Wahl des Systems den Unternehmen. Diese Gestaltungsfreiheit bedeutet jedoch zugleich, dass die Beweislast vollständig beim Unternehmen liegt. Wer im Ernstfall keine lückenlose Auskunft geben kann, kann sich nicht auf eine fehlende technische Vorgabe berufen – sondern hat schlicht das normierte Ergebnis nicht erreicht. Ergänzend greift auf nationaler Ebene das Lebensmittel- und Futtermittelgesetzbuch (LFGB), das die europäischen Vorgaben in deutsches Recht überführt. Eingebettet ist dieser Rechtsrahmen systematisch in das HACCP-Konzept als präventiven Steuerungsrahmen für Lebensmittelsicherheit.

In der Praxis entstehen Lücken in der Rückverfolgbarkeit häufig an denselben Stellen – unabhängig davon, wie gut das zugrundeliegende Konzept auf dem Papier ausgearbeitet ist. Fehlt die bidirektionale ERP-Schnittstelle zum Warehouse-Management-System, entstehen stille Chargenbrüche: Eine Palette wird physisch korrekt umgelagert und im WMS verbucht, doch die zugehörige Bestellreferenz verbleibt im ERP auf dem Status der Eingangscharge. Der Abgleich im Rückruffall erfordert dann die manuelle Überbrückung zweier Systeme – ein Aufwand, der im laufenden Rückrufbetrieb die behördlich geforderte Reaktionsfähigkeit strukturell gefährdet.

Eine durchdachte Nachschubsteuerung, die Chargengrenzen als Dispositionsparameter berücksichtigt, verhindert zudem, dass Mischbestände unterschiedlicher Produktionslose im Lager entstehen, die die Upstream-Verfolgung nachträglich erschweren. Wie einzelne Ereignistypen durch Systembrüche korrumpiert werden und welche technischen Gegenmaßnahmen greifen, ist im Abschnitt zur Digitalisierung und Systemintegration ausgeführt (→ Digitalisierung und Systemintegration). PackageHERO® unterstützt Unternehmen dabei, Kennzeichnungs- und Logistiklösungen so zu gestalten, dass physische Etikettierung und digitale Datenerfassung von Beginn an aufeinander abgestimmt sind.

Eine belastbare Rückverfolgbarkeit steht und fällt mit der Qualität der zugrundeliegenden Stammdaten. ISO 22005 Kapitel 5 konkretisiert die erforderliche Systemtiefe: Es legt fest, dass die Rückverfolgbarkeitseinheit – also die kleinste nachverfolgbare Einheit – explizit definiert sein muss und dass für jede Verarbeitungsstufe die Transformation von Eingangs- zu Ausgangseinheit dokumentiert wird. Kapitel 6 ergänzt, welche Attribute dieser Einheit eindeutig zugeordnet sein müssen – von der Chargennummer über den Lieferanten bis hin zu Produktionsdatum und Mengenangabe. Diese Festlegungen bestimmen, wie granular das System im Ereignisfall Auskunft geben kann. Zur praktischen Umsetzung der Stammdatenerfassung über alle beteiligten Systeme hinweg müssen diese Definitionen nicht nur vollständig, sondern auch konsistent gepflegt werden.

Fehlerhafte Stammdaten transformieren jede Chargenabfrage in eine manuelle Recherche – mit direktem Einfluss auf die Auskunftsfähigkeit gegenüber Behörden innerhalb gesetzlicher Fristen. In der Praxis treten typische Stammdatenfehler auf, die den Informationsfluss strukturell unterbrechen:

• Nicht eindeutige Chargennummern bei mehreren Lieferanten: Vergeben unterschiedliche Vorlieferanten dieselbe Chargennummer für verschiedene Produktionen, lässt sich im Rückruffall keine eindeutige Herkunftszuordnung mehr herstellen – die Auskunftspflicht gegenüber Behörden kann nicht fristgerecht erfüllt werden.
• Fehlende GLN-Verknüpfung bei Standortwechseln: Wird ein Lager- oder Produktionsstandort in das System neu aufgenommen, ohne ihm eine GLN zuzuweisen, entstehen anonyme Übergabepunkte im Prozessfluss – Bewegungen können keinem definierten Akteur zugeordnet werden.
• Inkonsistente Artikelstammdaten: Abweichende GTIN-Zuordnungen zwischen ERP und WMS führen dazu, dass Chargenbewegungen nicht konsistent einem Artikel folgen und Rückverfolgungsabfragen ins Leere laufen.

Jeder dieser Fehlertypen wirkt sich unmittelbar auf die Auskunftsfähigkeit im Rückruffall aus: Wer eine Übergabestation nicht eindeutig einer erfassten Einheit zuordnen kann, verliert genau dort die Rückverfolgbarkeit – und damit die Grundlage für eine rechtssichere Reaktion.

Für ein belastbares Traceability-System entscheidet die Digitalisierung nicht allein über Effizienz, sondern über die grundsätzliche Funktionsfähigkeit der Rückverfolgbarkeit – gerade dann, wenn Daten über Unternehmensgrenzen hinweg ausgetauscht werden müssen. In der Praxis verlaufen die Umsetzungsstufen typischerweise von strukturierten Lieferscheinen und tabellenbasierten Templates über Barcode- und scannergestützte Lagererfassung bis hin zu vollintegrierten ERP- und WMS-Systemen mit EPCIS-Datenanbindung als Integrationsziel.

Doch selbst ausgereifte interne Systeme stoßen an Grenzen, sobald heterogene IT-Landschaften an Schnittstellen zu Zulieferern oder Abnehmern aufeinanderprallen. Genau hier entstehen die häufigsten Lücken. Der größte Hebel liegt daher in standardisierten Datenaustauschformaten, die alle Stufen verbinden. EPCIS definiert dafür konkrete Ereignistypen: ObjectEvent beschreibt die Statusänderung eines einzelnen Objekts – etwa den Scan einer Palette beim Warenausgang. AggregationEvent dokumentiert die Zusammenführung von Einheiten, beispielsweise wenn Kartons auf einer Palette konsolidiert werden. TransactionEvent verknüpft ein Objekt mit einem konkreten Geschäftsvorgang, etwa einer Bestellung oder einem Lieferschein.

Jeder dieser Ereignistypen hat eine spezifische Fehleranfälligkeit, die aus bestimmten Systembrüchen resultiert: Eine fehlende ERP-Rückkopplung im WMS korrumpiert primär TransactionEvents – Lagerbewegungen werden physisch korrekt verbucht, ohne dass der zugehörige Geschäftsvorgang im kaufmännischen System gespiegelt wird, sodass eine Divergenz zwischen logistischem Ereignis und kaufmännischer Charge entsteht. Manuelle Chargeneingaben an Scanpunkten hingegen korrumpieren bevorzugt ObjectEvents: Tippfehler oder Verwechslungen bei der Chargennummer erzeugen falsche Objektidentitäten, die sich durch alle nachfolgenden Ereignisse fortpflanzen und eine spätere Upstream-Auflösung strukturell unmöglich machen. Für die Multi-Channel-Logistik bedeutet das: Auch wenn dieselbe Charge über verschiedene Fulfillment-Wege ausgeliefert wird, bleiben alle Ereignisse nur dann einem gemeinsamen Datenstrang zugeordnet, wenn ObjectEvents und TransactionEvents lückenlos und konsistent erfasst werden.

Ein struktureller Vorteil von EPCIS gegenüber nachträglich editierbaren ERP-Chargenaufzeichnungen liegt in der Architektur der Ereignisprotokollierung: EPCIS-Logs sind als append-only-Ereignisketten konzipiert – einmal geschriebene Ereignisse können nicht überschrieben, sondern nur durch neue Ereignisse ergänzt werden. Das macht sie strukturell revisionsresistenter als ERP-Einträge, die im Tagesgeschäft korrigiert, umdatiert oder überschrieben werden können. Im Behördenfall bedeutet das einen konkreten Unterschied bei der Beweislast: Ein lückenloser, unveränderlicher EPCIS-Log dokumentiert den tatsächlichen Zustand zum Zeitpunkt des Ereignisses – während ein nachträglich angepasster ERP-Datensatz im Zweifel erklärungsbedürftig bleibt.