EDIFACT in der Spedition: DESADV, INVOIC und IFTMIN erklärt

EDIFACT ist der UN-Standard, in dem Verlader, Speditionen und Empfänger Transportdaten maschinenlesbar austauschen. Für eine Spedition zählen vor allem fünf Nachrichten: IFTMIN für den Auftrag, IFTSTA für den Status, IFCSUM für Sammelsendungen, DESADV als Lieferavis des Versenders und INVOIC für die Rechnung.

Welche EDIFACT-Nachrichten in einem Transportauftrag anfallen

Ein typischer Stückgut- oder Teilladungsauftrag erzeugt vier bis sechs EDIFACT-Nachrichten: Der Verlader schickt IFTMIN, die Spedition bestätigt technisch mit CONTRL, meldet den Fortschritt per IFTSTA und rechnet per INVOIC ab. DESADV und IFCSUM kommen je nach Branche und Netzwerk dazu.

Die Bezeichnungen wirken beliebig, folgen aber einem Schema. Das „IFT“ am Anfang steht für International Forwarding and Transport, also die Nachrichtengruppe für Spedition und Transport. Die Tabelle zeigt, wann welche Nachricht in einem normalen Auftrag fällig wird und was Ihr Transportmanagementsystem damit tun muss.

Schritt im Auftrag	Nachricht	Richtung	Was das TMS damit macht
Versender kündigt Ware beim Empfänger an	DESADV (Despatch Advice, Lieferavis)	Versender → Empfänger, teils in Kopie an die Spedition	Packstück-IDs (SSCC/NVE) übernehmen, damit Scans beim Umschlag zugeordnet werden
Transportauftrag erteilen	IFTMIN (Instruction)	Verlader → Spedition	Auftrag anlegen, Abhol- und Zustellfenster, Gewichte, Packstücke, Gefahrgut, Referenzen übernehmen
Empfang technisch bestätigen	CONTRL (Syntax and Service Report)	Empfänger der Nachricht → Absender	Automatisch erzeugen; meldet nur, ob die Datei formal lesbar war
Inhalt fachlich ablehnen oder bestätigen	APERAK (Application Error and Acknowledgement)	Spedition → Verlader	Meldet etwa eine unbekannte Empfängeradresse oder ein fehlendes Pflichtfeld zurück
Sendungen an Partner oder Hub übergeben	IFCSUM (Forwarding and Consolidation Summary)	Spedition → Netzwerkpartner, Hub oder Empfangsspediteur	Bordero aus den Sendungen einer Tour oder Linie erzeugen
Fortschritt melden	IFTSTA (Status Report)	Spedition → Verlader, Partner → Spedition	Eigene Ereignisse (Abholung, Umschlag, Zustellung, Abweichung) in die Codes des Partners übersetzen
Abrechnen	INVOIC (Invoice)	Spedition → Verlader	Rechnung aus Fracht, Zuschlägen und Nebenleistungen bilden; als Buchungsbeleg archivieren

Nicht jeder Auftraggeber nutzt alle Nachrichten. Viele kleinere Verlader schicken nur IFTMIN und wollen IFTSTA zurück, die Rechnung kommt weiter als PDF. Große Handelsketten und Automobilzulieferer verlangen dagegen oft das volle Paket, inklusive INVOIC. Welche Nachrichten Ihr Partner erwartet, steht in seinem Profil, oft Message Implementation Guideline oder kurz MIG genannt. Wie eine EDI-Anbindung organisatorisch abläuft, von der Anfrage bis zum Echtbetrieb, beschreibt der Ratgeber EDI-Anbindung: was der Datenaustausch mit Auftraggebern verlangt.

So ist eine EDIFACT-Datei aufgebaut

Eine EDIFACT-Datei ist reiner Text aus Segmenten. Jedes Segment beginnt mit einem dreistelligen Kürzel wie NAD oder DTM und endet mit einem Apostroph. Innerhalb eines Segments trennt ein Pluszeichen die Datenelemente und ein Doppelpunkt deren Bestandteile. Die Syntaxregeln stehen in der Norm ISO 9735.

Um die Nachricht liegen zwei Umschläge. Der äußere beginnt mit UNB und endet mit UNZ; er nennt Absender, Empfänger, Zeitstempel und eine Übertragungsnummer. Darin stecken eine oder mehrere Nachrichten, jede eingerahmt von UNH und UNT. Der folgende Ausschnitt zeigt einen stark gekürzten Transportauftrag. Absender, Empfänger und Auftragsnummer sind erfunden, die Struktur ist echt.

UNA:+.? '
UNB+UNOC:3+4012345000009:14+4098765000003:14+261030:0815+1001'
UNH+1+IFTMIN:D:04A:UN'
BGM+610+AUF-778812+9'
DTM+137:202610300815:203'
NAD+CZ+4012345000009::9'
NAD+CN+4098765000003::9'
GID+1+3:PX'
UNT+7+1'
UNZ+1+1001'

Segment	Bedeutung im Beispiel	Worauf Sie achten
UNA	Legt die Trennzeichen fest: Doppelpunkt, Plus, Punkt als Dezimalzeichen, Fragezeichen als Freigabezeichen, Apostroph als Segmentende	Fehlt UNA, gelten die Standardzeichen. Ein Apostroph im Firmennamen muss als ?‘ maskiert werden
UNB	Zeichensatz UNOC, Syntaxversion 3, Absender und Empfänger als GLN (Qualifier 14), Datum 30.10.26, 08:15 Uhr, Übertragungsnummer 1001	Zeichensatz klären: UNOA kennt keine Umlaute, UNOC schon
UNH	Nachricht Nr. 1 vom Typ IFTMIN, Verzeichnis D.04A der UN	Die Version muss zu dem passen, was Ihr Konverter für diesen Partner erwartet
BGM	Dokumentart (Code 610), Auftragsnummer, Funktion 9 = Original	Funktion 1 (Storno) oder 5 (Ersatz) muss Ihr TMS als Änderung eines bestehenden Auftrags erkennen
DTM	Qualifier 137 = Dokumentdatum, Format 203 = JJJJMMTTSSMM	Abholfenster stehen in eigenen DTM-Segmenten mit anderen Qualifiern
NAD	CZ = Versender, CN = Empfänger, jeweils per GLN (Codeverwalter 9 = GS1)	Kommt die Adresse nur als GLN, braucht Ihr TMS eine Stammdatentabelle GLN zu Adresse
GID	Warenposition 1: drei Packstücke vom Typ PX (Palette)	Packmittelcodes aus UN/ECE-Empfehlung 21 auf die eigenen Lademittel mappen
UNT, UNZ	7 Segmente in Nachricht 1; 1 Nachricht in Übertragung 1001	Stimmen die Zähler nicht, lehnt der Empfänger die Datei per CONTRL ab

Ein echter IFTMIN hat deutlich mehr Segmente: Abhol- und Zustellzeitfenster, Frankatur, Maße und Gewichte je Position, Gefahrgutangaben, Avisierungswünsche, Referenzen wie Lieferscheinnummer und Bestellnummer. Den Aufbau müssen Sie nicht auswendig kennen. Sie sollten aber ein Rohdatei-Beispiel lesen können, wenn ein Auftrag mit falschem Gewicht im System landet und geklärt werden muss, ob der Fehler beim Verlader oder im eigenen Mapping liegt.

IFTMIN: der Auftrag, an dem alles hängt

IFTMIN ist die Transportanweisung des Verladers. Sie enthält alles, was die Disposition braucht: wer, was, von wo, wohin, bis wann und mit welchen Auflagen. Läuft der IFTMIN sauber ins TMS, entfällt das Abtippen von Aufträgen aus Mails und Portalen vollständig.

In der Praxis entscheiden drei Details darüber, ob ein IFTMIN-Import entlastet oder Arbeit macht. Das erste sind Änderungen. Verlader schicken Korrekturen als neue Nachricht mit derselben Auftragsnummer und einem anderen Funktionscode im BGM. Legt das TMS dafür einen zweiten Auftrag an, fährt im schlimmsten Fall ein zweiter LKW. Testen Sie Storno und Änderung vor dem Echtstart ausdrücklich.

Das zweite Detail sind Zeitfenster. Manche Verlader liefern ein Abholdatum, andere ein Fenster mit Von- und Bis-Zeit, wieder andere nur ein Lieferdatum beim Empfänger. Das Mapping muss festlegen, welches Feld im TMS daraus wird, sonst plant die Disposition mit Mitternacht als Abholzeit.

Das dritte sind Gefahrgutangaben. Kommt die UN-Nummer im IFTMIN mit, sollte das TMS sie in die Tourenplanung übernehmen und die Beförderungspapiere daraus vorbelegen. Kommt sie nicht mit, obwohl die Ware Gefahrgut ist, muss das im Profil des Verladers geklärt werden, bevor die erste Sendung rollt.

IFTSTA: wo die meisten Anbindungen haken

IFTSTA meldet Sendungsereignisse an den Auftraggeber: abgeholt, im Umschlag, in Zustellung, zugestellt, Abweichung. Technisch ist die Nachricht einfach. Schwierig ist, dass jeder Verlader eigene Statuscodes und Abweichungsgründe vorgibt und Ihr TMS seine internen Ereignisse darauf übersetzen muss.

Als gemeinsame Basis gibt es die UN/CEFACT-Empfehlung Nr. 24, „Trade and Transport Status Codes“. Sie definiert eine Codeliste für Transportereignisse und Gründe. In der Praxis verwenden große Verlader und Netzwerke aber oft eigene Ausprägungen oder Teilmengen. GS1 Germany veröffentlicht für den Handel ein eigenes IFTSTA-Profil auf Basis von EANCOM.

Die Arbeit liegt im Mapping. Ihr Fahrer scannt „Annahme verweigert, Ware beschädigt“. Der eine Verlader will dafür einen Zustellstatus mit Abweichungsgrund, der nächste einen eigenen Ereigniscode, der dritte zusätzlich ein Foto per separater Schnittstelle. Wer diese Tabelle nicht vollständig mit dem Verlader durchgeht, merkt die Lücke erst, wenn dessen Kundenservice nachfragt, warum eine Sendung seit drei Tagen „in Zustellung“ steht.

DESADV und IFCSUM: zwei Nachrichten, die oft verwechselt werden

DESADV ist der Lieferavis des Versenders an den Warenempfänger und gehört eigentlich nicht der Spedition. IFCSUM ist die Sammelmeldung der Spedition an ihren Partner oder Hub. Beide beschreiben Sendungen und Packstücke, sie stehen aber an verschiedenen Stellen der Kette und werden von verschiedenen Parteien erzeugt.

Die DESADV wird für Speditionen interessant, wenn der Handel mit Packstück-IDs arbeitet. Jedes Packstück trägt dann eine SSCC, in Deutschland meist NVE (Nummer der Versandeinheit) genannt. Die SSCC ist nach den GS1-Spezifikationen 18 Stellen lang und weltweit eindeutig. Bekommt die Spedition die DESADV in Kopie oder die SSCCs im IFTMIN, kann sie jeden Scan an der Rampe der richtigen Sendung zuordnen. Fehlen diese Daten, scannt der Lagermitarbeiter Etiketten, die das TMS nicht kennt.

IFCSUM brauchen Sie, sobald Sendungen an Kooperationspartner übergeben werden, etwa im Stückgutnetz oder an einen Empfangsspediteur im Ausland. Die Nachricht ersetzt das Papierbordero: Sie listet alle Sendungen einer Linie mit Packstücken, Gewichten und Empfängern. In Stückgutkooperationen gibt meist die Systemzentrale das Profil vor, nicht der einzelne Partner.

INVOIC und die E-Rechnungspflicht: was bis Ende 2027 zu tun ist

EDI-Rechnungen per INVOIC bleiben auch unter der E-Rechnungspflicht erlaubt, wenn sich die Rechnungsangaben vollständig in ein Format nach der europäischen Rechnungsnorm überführen lassen. Für INVOIC-Profile, die das nicht schaffen, gilt eine Übergangsfrist: zulässig nur noch für Umsätze, die bis zum 31. Dezember 2027 ausgeführt werden.

Die Rechtslage steht in zwei Paragrafen des Umsatzsteuergesetzes. § 14 Abs. 1 Satz 6 UStG erlaubt neben XRechnung und ZUGFeRD auch ein zwischen Aussteller und Empfänger vereinbartes Format. Voraussetzung ist, dass es „die richtige und vollständige Extraktion der nach diesem Gesetz erforderlichen Angaben“ in ein Format ermöglicht, das der europäischen Norm entspricht oder mit ihr interoperabel ist. Die Norm ist die EN 16931, auf die die Richtlinie 2014/55/EU vom 16. April 2014 verweist.

Für EDI-Verfahren, die diese Hürde nicht nehmen, enthält § 27 Abs. 38 Nr. 3 UStG eine eigene Übergangsregel. Rechnungen per elektronischem Datenaustausch im Sinne der EU-Empfehlung 94/820/EG vom 19. Oktober 1994 dürfen danach bis zum 31. Dezember 2027 für Umsätze aus dem Jahr 2027 weiter im bisherigen Format ausgestellt werden, mit Zustimmung des Empfängers. Unabhängig davon dürfen Rechnungsaussteller mit einem Vorjahresumsatz bis 800.000 Euro nach Nr. 2 derselben Vorschrift 2027 noch Papier- und sonstige Rechnungen verschicken.

Ihre Situation	Was daraus folgt
Sie rechnen per INVOIC ab, und der Verlader bestätigt, dass sein Profil alle Pflichtangaben nach § 14 Abs. 4 UStG trägt und in EN 16931 überführbar ist	Die Bestätigung schriftlich ablegen. Das Verfahren kann über 2027 hinaus laufen
Sie rechnen per INVOIC ab, aber im Profil fehlen Pflichtangaben, etwa der Leistungszeitraum oder die Steuernummer	Bis Ende 2027 zulässig. Mit dem Verlader bis spätestens Mitte 2027 ein erweitertes Profil oder den Wechsel auf XRechnung oder ZUGFeRD vereinbaren
Der Verlader will INVOIC, Sie schicken heute PDF	Gleich ein normkonformes Profil vereinbaren. Ein neues Verfahren auf ein auslaufendes Format zu bauen, lohnt nicht
Sie empfangen INVOIC von Subunternehmern oder Partnern	Die empfangene Nachricht ist Ihr Buchungsbeleg und bleibt nach § 147 Abs. 3 AO acht Jahre aufbewahrungspflichtig, im empfangenen Format und maschinell auswertbar

Welche Formate und Fristen außerhalb von EDI gelten, erklärt der Ratgeber E-Rechnungspflicht: was Betriebe umstellen müssen.

CONTRL und APERAK: zwei Quittungen mit verschiedener Aussage

CONTRL quittiert, dass eine EDIFACT-Datei formal korrekt angekommen ist, also Syntax, Zähler und Umschläge stimmen. APERAK meldet, ob der Inhalt fachlich verarbeitet werden konnte. Eine positive CONTRL heißt deshalb nicht, dass der Auftrag im System des Partners angelegt wurde.

Diese Unterscheidung wird regelmäßig unterschätzt. Ein Verlader sieht eine positive CONTRL und geht davon aus, dass die Spedition den Auftrag hat. Im TMS ist der Import aber gescheitert, weil die Empfänger-GLN unbekannt war. Ohne APERAK oder einen anderen Rückkanal erfährt der Verlader davon erst, wenn die Ware nicht abgeholt wird.

Klären Sie deshalb mit jedem Partner, welche Quittungen er erwartet und welche er selbst schickt. Und richten Sie im eigenen System eine Fehlerliste ein, die jemand in der Disposition täglich ansieht. Ein EDI-Fehler, der nur im Logfile des Konverters steht, ist für den Betrieb unsichtbar.

Versionen: warum D.96A und D.01B nicht dasselbe sind

Jede EDIFACT-Nachricht nennt im UNH-Segment das Verzeichnis, nach dem sie aufgebaut ist, etwa D.96A oder D.01B. UN/CEFACT veröffentlicht neue Verzeichnisse in der Regel zweimal pro Jahr. Zwischen den Versionen ändern sich Segmente, Qualifier und Codelisten. Ihr Konverter braucht für jeden Partner die passende Version.

In der Logistik sind ältere Verzeichnisse weit verbreitet, weil laufende Anbindungen selten umgestellt werden. Im Handel ist EANCOM 2002 Syntax 4 der übliche Rahmen; GS1 hat diesen Teilstandard auf Basis des Verzeichnisses D.01B entwickelt. In Stückgutnetzen geben die Systemzentralen eigene Profile vor, die Automobilindustrie arbeitet teils mit VDA-Empfehlungen.

Für Sie heißt das: Fragen Sie nicht nur „Können Sie IFTMIN?“, sondern „IFTMIN in welchem Verzeichnis, nach welchem Profil, mit welchen Pflichtsegmenten?“. Ein TMS-Anbieter, der „EDIFACT-fähig“ ist, kann trotzdem für eine bestimmte Version keine fertige Vorlage haben. Wie sich TMS-Systeme bei den Anbindungen unterscheiden, zeigt der Pillar-Beitrag Transportmanagement für Speditionen: welche Anbindungen zählen.

Checkliste für die Anbindung eines neuen Partners

Bevor die erste echte Nachricht fließt, sollten Format, Inhalt, Übertragungsweg, Fehlerbehandlung und Testabnahme schriftlich geklärt sein. Die folgende Liste deckt die Punkte ab, an denen Anbindungen in der Praxis am häufigsten nachgebessert werden müssen.

Sechs Fehler, die im Echtbetrieb immer wieder auftauchen

Die meisten EDIFACT-Probleme zeigen sich nicht im Test, sondern in den ersten Wochen danach, wenn Sonderfälle auftreten. Diese sechs Muster lassen sich mit etwas Vorbereitung fast vollständig vermeiden.

1. Nur der Normalfall getestet. Ein einzelner Testauftrag mit einer Palette beweist wenig. Testen Sie Storno, Änderung, Gefahrgut, mehrere Positionen und Abweichungen.
2. Doppelte Aufträge nach Korrekturen. Das TMS erkennt eine geänderte Nachricht nicht als Änderung und legt einen neuen Auftrag an.
3. Status fehlt oder kommt zu spät. Ereignisse werden zwar gescannt, aber nicht gemappt oder nur einmal am Tag gesammelt verschickt, obwohl der Verlader zeitnahe Meldungen erwartet.
4. Sonderzeichen zerlegen die Datei. Ein Apostroph in „Müller’s Backstube“ beendet das Segment, wenn er nicht maskiert ist. Umlaute gehen verloren, wenn der Zeichensatz nicht passt.
5. Fehler landen im Nirwana. Der Konverter verwirft eine Nachricht, aber niemand im Betrieb sieht es.
6. Profiländerungen bleiben unbemerkt. Der Verlader stellt sein Profil um und informiert nur die IT-Abteilung, die es nicht mehr gibt. Halten Sie einen festen Ansprechpartner für EDI-Themen auf beiden Seiten aktuell.

Für wen sich eigenes EDIFACT-Wissen lohnt und für wen nicht

Eigenes EDIFACT-Wissen mit eigenem Konverter lohnt sich für Speditionen mit vielen EDI-Partnern und häufigen Profiländerungen. Wer zwei oder drei Verlader anbindet, fährt mit einem EDI-Dienstleister oder dem EDI-Modul des TMS-Anbieters meist besser und braucht nur das Wissen, um Profile und Fehler zu verstehen.

Ein paar Faustregeln helfen bei der Entscheidung. Wenn ein einzelner Großkunde EDI verlangt und sonst niemand, ist ein Webportal oder Mapping-Service des Dienstleisters fast immer die wirtschaftlichere Lösung. Wenn Sie in einer Stückgutkooperation sind, nutzen Sie das, was die Systemzentrale für IFCSUM und IFTSTA bereitstellt, statt eigene Wege zu bauen. Wenn regelmäßig neue Verlader mit EDI dazukommen und Ihr TMS-Anbieter jede Anbindung als Einzelprojekt abrechnet, lohnt der Blick auf einen eigenen Konverter oder eine Integrationsplattform, und mindestens eine Person im Haus sollte Rohdateien lesen können.

Nicht lohnend ist es, eine neue INVOIC-Anbindung jetzt noch auf ein Profil aufzusetzen, das die Extraktionsanforderung nicht erfüllt. Die Übergangsfrist endet mit dem Jahr 2027, und der Umbau kostet dann ein zweites Mal. Welche TMS- und EDI-Lösungen es für Speditionen gibt, zeigt die Übersicht EDI und Schnittstellen für Spedition & Logistik; für den gesamten Auswahlprozess hilft der Leitfaden Branchensoftware auswählen: ein Leitfaden in sieben Schritten.

Die Kurzdefinitionen der Grundbegriffe finden Sie im Glossar unter EDI (Electronic Data Interchange) und Transportmanagementsystem (TMS).

Häufige Fragen zu EDIFACT in der Spedition

Was ist der Unterschied zwischen EDI und EDIFACT?

EDI ist der Oberbegriff für den elektronischen Austausch strukturierter Geschäftsdaten zwischen Unternehmen. EDIFACT ist ein bestimmter Standard dafür, entwickelt unter dem Dach der Vereinten Nationen. Daneben gibt es andere EDI-Formate, etwa XML-basierte Profile, ANSI X12 in Nordamerika oder VDA-Formate in der Automobilindustrie.

Was ist der Unterschied zwischen EDIFACT und EANCOM?

EANCOM ist ein Teilstandard von EDIFACT, den GS1 für Handel und Konsumgüter festgelegt hat. Er nutzt nur einen Teil der Segmente und schreibt GS1-Identifikatoren wie GLN und SSCC vor. Jede EANCOM-Nachricht ist eine gültige EDIFACT-Nachricht, aber nicht umgekehrt.

Kann ich EDIFACT-Dateien ohne Spezialsoftware lesen?

Ja, mit jedem Texteditor. Hilfreich ist, die Datei an jedem Apostroph umzubrechen, dann steht ein Segment pro Zeile. Für die Bedeutung der Qualifier brauchen Sie das Profil des Partners oder das passende UN-Verzeichnis.

Gilt eine INVOIC-Nachricht als E-Rechnung?

Ja, wenn Aussteller und Empfänger das Format vereinbart haben und sich alle umsatzsteuerlichen Pflichtangaben vollständig in ein Format nach EN 16931 überführen lassen (§ 14 Abs. 1 Satz 6 Nr. 2 UStG). Ist das nicht der Fall, ist das Verfahren nur noch für Umsätze bis Ende 2027 zulässig.

Wie lange muss ich empfangene EDIFACT-Nachrichten aufbewahren?

Rechnungen sind Buchungsbelege und nach § 147 Abs. 3 AO acht Jahre aufzubewahren. Transportaufträge zählen als Handels- oder Geschäftsbriefe und sind sechs Jahre aufzubewahren; ob reine Statusmeldungen steuerlich relevant sind, klären Sie mit Ihrem Steuerberater. Archivieren Sie die Nachricht im empfangenen Format und so, dass sie maschinell auswertbar bleibt.

Quellen und weiterführende Literatur

• Umsatzsteuergesetz, § 14 Abs. 1 Satz 3 bis 6 (Definition und Format der E-Rechnung), gesetze-im-internet.de, abgerufen am 31. Oktober 2026
• Umsatzsteuergesetz, § 27 Abs. 38 Nr. 1 bis 3 (Übergangsregeln, EDI-Verfahren bis 31. Dezember 2027, Umsatzgrenze 800.000 Euro), gesetze-im-internet.de, abgerufen am 31. Oktober 2026
• Empfehlung 94/820/EG der Kommission vom 19. Oktober 1994 über die rechtlichen Aspekte des elektronischen Datenaustausches, ABl. L 338 vom 28.12.1994, S. 98
• Richtlinie 2014/55/EU vom 16. April 2014 über die elektronische Rechnungsstellung bei öffentlichen Aufträgen, ABl. L 133 vom 6.5.2014, S. 1, mit Verweis auf die Norm EN 16931
• Abgabenordnung, § 147 Abs. 3 (Aufbewahrungsfristen, acht Jahre für Buchungsbelege seit 1. Januar 2025)
• ISO 9735, Electronic data interchange for administration, commerce and transport (EDIFACT), Syntaxregeln
• UN/CEFACT, Recommendation No. 24, Trade and Transport Status Codes, UNECE
• UN/ECE Recommendation No. 21, Codes for Types of Cargo, Packages and Packaging Materials
• GS1, EANCOM 2002 Syntax 4 (Teilstandard auf Basis von UN/EDIFACT D.01B), Nachrichtenprofile IFTMIN, IFTSTA, IFCSUM, DESADV, INVOIC; GS1 General Specifications zur SSCC