EDIFACT-Anbindung an Spediteure: Schritt für Schritt

Warum EDIFACT trotz API-Trend Standard bleibt

Weil DB Schenker und andere große Speditionen von Verladern nach wie vor EDIFACT-Nachrichten verlangen, nicht REST-APIs. Wer eine EDIFACT IFTMIN Anbindung aufbauen will, um Transportaufträge maschinell an einen Frachtführer zu übergeben, landet fast immer bei denselben drei Nachrichtentypen: IFTMIN für die Buchung, IFTMCS als Eingangsbestätigung und IFTSTA für die Statusrückmeldung. DB Schenker listet diese Formate direkt in der eigenen API-Dokumentation: IFTMIN S93A dient als EDI für die Buchung von Sendungen, IFTMCS S93A als Empfangsbestätigung, dass die EDI-Nachricht angekommen ist, und IFTSTA D96A für Ereignisse, die während des Transports passiert sind.

Für Verlader mit gewachsener SAP- oder Microsoft-Dynamics-Landschaft ist das keine akademische Frage. Die IDoc- oder EDI-Schnittstelle im ERP muss am Ende exakt die Segmentstruktur produzieren, die der jeweilige Carrier erwartet. Und jede Spedition hat dabei ihre eigene Auslegung der Norm. Diese Anleitung führt Sie durch die technische Einrichtung, das Testen und die GoBD-konforme EDI-Archivierung einer solchen Anbindung – exemplarisch anhand von DB Schenker, aber übertragbar auf andere EDIFACT-Frachtführer.

Was Sie vor dem Start brauchen

Vier Dinge, ohne die Sie gar nicht anfangen sollten: eine bestätigte Übertragungsmethode, Testzugang beim Carrier, die richtigen Nachrichtenversionen und einen Ansprechpartner für die Qualifizierung.

• AS2-Zertifikate oder OFTP2-Zugangsdaten. Bei AS2 tauschen beide Seiten digitale Zertifikate aus; die Nachrichten werden verschlüsselt und signiert über das Internet geschickt, und der Empfänger bestätigt den Eingang mit einer MDN (Message Disposition Notification). OFTP2 ist in der deutschen Automobil- und Zulieferindustrie stark verbreitet; es garantiert über TLS/SSL eine sichere verschlüsselte Übertragung und signiert Daten zusätzlich mit einem Zertifikat. Der praktische Unterschied: bei AS2 können Nachrichten nur gepusht werden, während sie bei OFTP sowohl gepusht als auch gepullt werden können.
• Bestätigte AS2-ID oder VAN-Mailbox-Adresse Ihres Integrationskontakts beim Spediteur – ohne diese ID läuft keine Testnachricht durch.
• Zugang zur Zertifizierungsumgebung des Carriers und einen benannten Ansprechpartner für die Nachrichtenqualifizierung, nicht nur eine allgemeine Support-Mailadresse.
• Die konkreten Nachrichtenversionen des jeweiligen Carriers. Bei DB Schenker sind das IFTMIN S93A, IFTMCS S93A und IFTSTA D96A – andere Speditionen nutzen teils andere EANCOM- oder EDIFACT-Versionen, etwa D96A oder D01B.

Die Anbindung Schritt für Schritt einrichten

Sieben Schritte, vom Feldmapping bis zum GoBD-konformen Archiv. Überspringen Sie keinen davon – die meisten gescheiterten Projekte fallen nicht auf der Konzeptebene aus, sondern beim Testen oder bei der Archivierung.

1. Feldmapping erstellen. Bilden Sie die Felder aus TMS oder ERP auf die relevanten IFTMIN-Segmente ab: BGM für die Auftragskennung, NAD für Absender, Empfänger und Frachtführer, TDT für die Transportmittel-Segmentgruppe, LOC für Lokationen, DTM für Termine und RFF für Referenzen. Das NAD-Segment ist dabei zentral, denn es beschreibt in einer Segmentgruppe Name und Anschrift der beteiligten Parteien. Die GS1-Germany-Dokumentation zum Transport-/Speditionsauftrag IFTMIN gibt dafür die verbindliche deutsche Feldbeschreibung vor. Wichtig: ein Transport-/Speditionsauftrag sollte immer einer Sendung entsprechen – wer mehrere Sendungen in eine IFTMIN packt, produziert bei vielen Carriern Fehler.
2. AS2- oder OFTP2-Verbindung aufbauen. Tauschen Sie Zertifikate und IDs mit dem Integrationsteam des Spediteurs aus und richten Sie die MDN-Bestätigung als Zustellnachweis ein. Bei OFTP2 stellt in der Regel ODETTE die Zertifikate aus, üblicherweise für ein bis vier Jahre Laufzeit, danach müssen Sie sie verlängern. Klären Sie vorab, ob der Carrier Push- oder Pull-Betrieb erwartet – das bestimmt, ob Ihr Endpoint dauerhaft erreichbar sein muss.
3. Testnachricht in der Zertifizierungsumgebung senden. Schicken Sie eine reale, aber nicht-produktive Buchung und werten Sie die CONTRL-Antwort aus. Diese Syntax-Rückmeldung zeigt Ihnen, ob Segmente oder Qualifier nicht zur MIG (Message Implementation Guideline) des Carriers passen, bevor überhaupt eine echte Sendung betroffen ist.
4. IFTSTA-Statuscodes auf interne Meilensteine mappen. Legen Sie fest, welcher Statuscode welchem internen Ereignis entspricht – Abholung, Zustellung, Auslieferungsquittung (Proof of Delivery). Die DB-Schenker-Dokumentation zu IFTSTA D96A zeigt, wie granular das werden kann: bestimmte Segmente werden bei einzelnen Statuscodes wie IOD (Code 21) oder TEP (Code 901) gar nicht mitgesendet – ein Detail, das Sie im Mapping berücksichtigen müssen, sonst entstehen Lücken in der Statuskette.
5. Parallelbetrieb einführen. Lassen Sie den bisherigen Prozess – Fax, Portal, manuelle Eingabe – für einen definierten Zeitraum parallel weiterlaufen, bis die EDI-Nachrichten zuverlässig und vollständig ankommen. Erst danach schalten Sie den alten Weg ab.
6. Go-Live-Kriterien prüfen. Zwei Signale zählen: die CONTRL-Bestätigungsrate für ausgehende IFTMIN-Nachrichten und die Vollständigkeit der eingehenden IFTSTA-Kette bis zum Proof of Delivery. Erst wenn beide über mehrere Wochen stabil sind, ist der Parallelbetrieb beendet.
7. GoBD-konforme Archivierung einrichten. Dazu mehr im nächsten Abschnitt – das ist der Schritt, der in der Praxis am häufigsten unterschätzt wird.

Fehlerbild: Negative CONTRL-Rückmeldung

Eine negative CONTRL bedeutet fast nie, dass Ihre Sendung verloren ist. Sie bedeutet, dass ein Segment oder ein Qualifier nicht der Erwartung des Carriers entspricht – meist ein Feld, ein Code oder eine Segmentreihenfolge, die von der spezifischen MIG des Empfängers abweicht.

Der richtige Umgang: Identifizieren Sie das konkret beanstandete Segment aus der CONTRL-Antwort und gleichen Sie es mit der Mapping-Dokumentation des Carriers ab, nicht mit der generischen EANCOM-Norm. Erstellen Sie nicht reflexartig eine neue Sendung – korrigieren Sie das Mapping und senden Sie die betroffene Nachricht erneut. "EDIFACT-konform" heißt nicht, dass zwei Carrier identisch implementieren. Jeder Frachtführer hat seine eigene MIG, und selbst innerhalb derselben Nachrichtenversion – etwa IFTMIN S93A – können Feldbelegungen zwischen zwei Speditionen unterschiedlich strikt geprüft werden. Das GS1-Germany-Profil macht das an anderer Stelle deutlich: bestimmte Referenzqualifier wie AWB-Nummer, Konnossement- oder CMR-Frachtbriefnummer werden im RFF-Segment für den gesamten Transportauftrag angegeben – aber nicht jeder Carrier akzeptiert dieselben Qualifier-Codes in derselben Feldposition.

GoBD-Anforderungen an die EDI-Archivierung konkret

Die kurze Antwort: EDI-Nachrichten müssen im Originalformat, unveränderbar und über die gesetzliche Frist hinweg auffindbar aufbewahrt werden. Ausdrucken reicht nicht.

Rechtsgrundlage sind die GoBD, die als Ausführungsbestimmungen zur Abgabenordnung regeln, wie steuerlich relevante Daten zu Prüfungszwecken archiviert werden müssen. Für EDI-Verfahren ist die Vorgabe eindeutig: Grund(buch)aufzeichnungen und darin empfangene Daten aus EDI-Verfahren müssen im Ursprungsformat aufbewahrt werden. Das bedeutet konkret: Sie archivieren die rohe EDIFACT-Nachricht, nicht nur den daraus generierten PDF-Lieferschein oder den ERP-Datensatz.

Die Fristen orientieren sich an § 147 AO: zehn Jahre für Handelsbücher und Jahresabschlüsse, acht Jahre ab 2025 für Buchungsbelege wie Rechnungen und Kostenbelege, sechs Jahre für geschäftliche E-Mails und Geschäftsbriefe. Für IFTMIN- und IFTSTA-Nachrichten, die direkt mit dem Frachtvertrag und der Abrechnung verknüpft sind, sollten Sie sicherheitshalber die längere Frist ansetzen.

Unveränderbarkeit ist dabei keine reine Frage der Absichtserklärung. Eine zentrale Anforderung der GoBD betrifft die Unveränderbarkeit, wobei eine bloße Ablage im Dateisystem die Anforderungen ohne zusätzliche Maßnahmen nicht erfüllt. Praktisch heißt das: Ihr EDI-Gateway oder Archivsystem muss technisch verhindern, dass eine einmal empfangene IFTMIN- oder IFTSTA-Nachricht nachträglich verändert werden kann – Rechteentzug per Policy reicht nicht, das System selbst muss es sperren. Zusätzlich verlangen die GoBD einen nachvollziehbaren Index: alle Archivierungsobjekte müssen mit einem eindeutigen Index versehen werden, etwa Dokumenten-ID, Dokumentenart, Zuordnung zu Stammdaten, Belegnummer oder zeitliche Zuordnung.

Der Praxistipp aus vielen Betriebsprüfungen: Es scheitert seltener an fehlenden Dokumenten als an nicht auffindbaren oder falsch zugeordneten. Eine CONTRL-Bestätigung ohne Zuordnung zur passenden IFTMIN-Nachricht ist bei einer Prüfung wertlos, selbst wenn sie physisch vorliegt. Legen Sie deshalb von Anfang an eine feste Indexierungslogik fest – Auftragsnummer, Carrier, Nachrichtentyp, Zeitstempel – und dokumentieren Sie diese in Ihrer Verfahrensdokumentation.

Wie Sie wissen, dass die Anbindung funktioniert

Zwei KPIs genügen als Nachweis: die CONTRL-Bestätigungsrate für ausgehende IFTMIN-Nachrichten und die IFTSTA-Vollständigkeit bis zum Proof of Delivery. Liegt die CONTRL-Bestätigungsrate konstant nahe 100 Prozent und kommen für jede gebuchte Sendung auch die erwarteten Statusmeldungen bis zur Zustellquittung an, ist die Anbindung produktionsreif.

Ein Punkt, der in der Praxis oft übersehen wird: Die erste Carrier-Anbindung ist die aufwändigste. Sie bauen dabei nicht nur die technische Verbindung, sondern auch internes Wissen über Mapping-Fallstricke, MIG-Eigenheiten und Testzyklen auf. Die zweite und dritte Anbindung an einen weiteren EDIFACT-Frachtführer gehen deutlich schneller, weil Zertifikatsmanagement, Archivierungsprozess und Testmethodik bereits stehen – nur das carrierspezifische Feldmapping muss neu erstellt werden.

EDI-first vs. Multi-Carrier-TMS mit nativer Konnektivität

Wer nur einen oder zwei Carrier anbindet, kommt mit einer eigenen AS2/OFTP2-Infrastruktur und manuellem Mapping gut zurecht. Bei mehr als drei oder vier EDIFACT-Frachtführern skaliert der Aufwand pro Carrier nicht linear – jede neue Spedition bringt eine eigene MIG, eigene Testzyklen und eigene Statuscode-Logik mit.

Genau hier setzen Multi-Carrier-TMS-Plattformen mit bereits bestehenden Carrier-Integrationen an. Sie übernehmen das Feldmapping und die Protokollverbindung für eine wachsende Zahl von Frachtführern zentral, sodass Sie als Verlader nicht bei jedem neuen Carrier wieder von Null anfangen.

Die Entscheidung zwischen Eigenbau und Plattform ist letztlich eine Frage der Carrier-Anzahl und der internen EDI-Kompetenz. Wer bereits ein SAP- oder Dynamics-EDI-Modul betreibt und nur ein oder zwei zusätzliche Frachtführer wie DB Schenker anbinden muss, spart mit der direkten AS2/OFTP2-Route mittelfristig Lizenzkosten. Wer dagegen regelmäßig neue Carrier hinzunimmt, zahlt bei der Eigenbau-Variante mit jedem neuen Mapping-Projekt erneut Zeit und Beraterstunden.

Nächste Schritte

Bevor Sie mit dem technischen Setup beginnen: Fordern Sie beim Carrier die aktuelle MIG-Dokumentation und die Zugangsdaten zur Zertifizierungsumgebung an, nicht erst nach dem ersten Testversuch. Klären Sie parallel intern, wer die GoBD-Verfahrensdokumentation für die EDI-Archivierung schreibt – das ist juristisch genauso wichtig wie die technische Nachrichtenqualität, wird aber in vielen Projekten erst kurz vor dem Go-Live nachgezogen.