EDIFACT

EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) ist der von den Vereinten Nationen entwickelte internationale Standard fuer den elektronischen Austausch von Geschaeftsdokumenten zwischen Unternehmen. Im B2B-Einkauf ist EDIFACT seit Jahrzehnten das Rueckgrat fuer Bestellungen, Lieferavise und Rechnungen zwischen Grossunternehmen und ihren Lieferanten.

Detaillierte Erklaerung

UN/EDIFACT wurde ab 1987 unter der Schirmherrschaft der United Nations Economic Commission for Europe (UN/ECE) entwickelt und ist in der ISO-Norm 9735 verankert. Der Standard definiert eine strikt hierarchische Nachrichtenstruktur aus Segmenten, Datenelementen und Trennzeichen, die maschinenlesbar uebertragen werden koennen — urspruenglich per X.400-Mail oder Value Added Networks (VAN), heute vorwiegend ueber AS2, SFTP oder HTTPS.

Eine EDIFACT-Nachricht besteht aus:

• Interchange-Ebene (UNB/UNZ): Umschlag mit Absender, Empfaenger, Datum und Kontrollnummer.
• Functional Group (UNG/UNE): Optionale Gruppierung gleichartiger Nachrichten.
• Message-Ebene (UNH/UNT): Einzelne Geschaeftsnachricht mit Typenkennung.
• Segmente: Datenbloecke wie BGM (Belegart), DTM (Datum), NAD (Adressen), LIN (Positionen), MOA (Betraege).

Die wichtigsten Nachrichtentypen im Einkauf sind:

Im deutschsprachigen Raum sind branchenspezifische Subsets verbreitet: EANCOM (Handel, GS1-Standard), ODETTE (Automobilindustrie) und VDA-Nachrichten (ebenfalls Automotive). Diese Subsets schraenken den offenen EDIFACT-Standard auf eine verbindliche Teilmenge ein, um Interoperabilitaet innerhalb der Branche zu garantieren.

EDIFACT-Nachrichten sind fuer Menschen schwer lesbar. Ein typisches ORDERS-Segment sieht so aus:

UNB+UNOA:3+4012345000096:14+5412345000013:14+200101:1000+1+++++EANCOM'
BGM+220+PO-987654+9'
DTM+137:20250115:102'
NAD+BY+4012345000096::9'

Die Implementierung erfordert einen EDI-Konverter oder eine Middleware-Plattform (z. B. Seeburger, OpenText, Boomi), die zwischen dem internen ERP-Format und dem EDIFACT-Nachrichtenformat uebersetzt. Viele grosse Lieferanten im DACH-Raum sind bereits EDIFACT-faehig; kleinere Betriebe nutzen alternativ [[webedi]] oder [[punchout]]-Anbindungen.

Rechtlich relevant: Fuer die steuerliche Anerkennung einer EDIFACT-INVOIC als elektronische Rechnung in Deutschland gelten die Anforderungen des UStG §14 Abs. 1 und die GoBD. Seit dem Wachstumschancengesetz 2024 (Umsetzung ab 2025/2027 gestaffelt) ist die strukturierte E-Rechnung im B2B-Bereich Pflicht — EDIFACT INVOIC gilt dabei als anerkanntes strukturiertes Format neben XRechnung und ZUGFeRD, sofern die Uebertragung nachweisbar und unveraendert erfolgt (GoBD §146).

Praxisbeispiel (konkretes Einkaufsszenario)

Ein Automobilzulieferer in Bayern beliefert einen Tier-1-Konzern mit Press- und Stanzteilen. Der Konzern sendet taeglich automatisierte ORDERS-Nachrichten aus seinem SAP-System. Das System des Zulieferers empfaengt die Bestellung via AS2, konvertiert sie in ein internes Fertigungsauftrag-Format und sendet innerhalb von 30 Minuten eine ORDRSP-Bestaetigung zurueck. Nach dem Versand folgt automatisch ein DESADV mit genauen Packstuck- und Seriennummern, den der Konzern zur Eingangserfassung nutzt. Die INVOIC wird nach Wareneingang ausgeloest und direkt mit der offenen Bestellung im ERP des Konzerns abgeglichen — ohne manuelle Dateneingabe auf beiden Seiten.

Der gesamte Prozess laeuft ohne E-Mail oder Telefon. Fehler entstehen typischerweise nicht im Transport, sondern bei Initial-Mapping-Fehlern: falsche GLN (Global Location Number), fehlende Preiseinheit oder eine abweichende Segmentversion.

Typische Fehler & Verhandlungskontext

Technische Fallstricke:

• Versionsabweichungen: EDIFACT existiert in mehreren Release-Versionen (D93A, D96A, D01B u. a.). Sender und Empfaenger muessen dieselbe Version oder ein abwaertskompatibles Mapping verwenden. Branchensubsets wie EANCOM 2002 schreiben die Version fest vor.
• Falsches Trennzeichen-Escaping: Enthaelt ein Datenwert selbst ein Trennzeichen (Komma, Plus, Apostroph), muss es mit einem Release-Character escaped werden. Fehlt das Escaping, bricht der Parser den Satz falsch auf.
• GLN-Fehler: Sender- und Empfaenger-GLN muessen mit den im Handelsdaten-Pool hinterlegten Werten exakt uebereinstimmen. Tippfehler bei der 13-stelligen Nummer fuehren zu Silent-Rejects.
• Fehlende Pflichtfelder im INVOIC: Steuerrechtlich vorgeschriebene Felder (UStG §14 Abs. 4) — Steuernummer, Umsatzsteuer-Identifikationsnummer, Steuerbetrag — muessen vollstaendig und korrekt besetzt sein, sonst ist die Rechnung nicht vorsteuerabzugsfaehig.

Verhandlungskontext:

In der Lieferantenqualifizierung gilt EDIFACT-Faehigkeit bei Grosskonzernen oft als Onboarding-Voraussetzung. Kleinere Lieferanten, die kein eigenes EDI-System betreiben koennen, werden auf [[webedi]]-Portale verwiesen — was zwar die Anbindungshuerde senkt, aber manuellen Aufwand auf Lieferantenseite erzeugt. Beim Aufbau neuer Lieferantenbeziehungen lohnt es sich, fruehzeitig zu klaeren, welches EDIFACT-Subset und welche Uebertragungsmethode der Abnehmer vorschreibt, um spaetere Mapping-Projekte zu vermeiden.

Die Implementierungskosten fuer eine vollstaendige EDIFACT-Anbindung liegen je nach Komplexitaet zwischen wenigen tausend und mehreren zehntausend Euro; ein Middleware-Dienstleister amortisiert sich erfahrungsgemaess ab etwa 500 Belegen pro Monat.

Verwandte Begriffe

• [[edi]] — Oberbegriff fuer alle Formen des elektronischen Datenaustauschs
• [[webedi]] — browserbasierte EDIFACT-Anbindung fuer kleinere Lieferanten
• [[elektronische-rechnung]] — rechtliche Anforderungen an die E-Rechnung in Deutschland
• [[e-invoicing]] — internationales Pendant zur elektronischen Rechnung
• [[erp-integration]] — Systemintegration zwischen ERP und EDI-Middleware
• [[lieferantenintegration]] — Gesamtstrategie zur Lieferantenanbindung
• [[punchout]] — alternative B2B-Integrationsform ueber Katalogsysteme