EDIFACT einfach erklärt: Format, Aufbau, SAP, EDI und E-Rechnung

EDIFACT gehört seit Jahrzehnten zu den wichtigsten Standards für den strukturierten elektronischen Austausch von Geschäftsdaten zwischen Unternehmen. Bestellungen, Auftragsbestätigungen, Lieferavise, Rechnungen, Zahlungsinformationen oder Bestandsmeldungen können damit automatisiert zwischen unterschiedlichen ERP-, Warenwirtschafts- und Logistiksystemen übertragen werden.

Die Abkürzung steht für Electronic Data Interchange for Administration, Commerce and Transport. UN/EDIFACT wird im Umfeld der Vereinten Nationen beziehungsweise UN/CEFACT gepflegt. Die grundlegenden Syntaxregeln sind mit ISO 9735 standardisiert. Ziel ist es, Geschäftspartnern unabhängig von ihrer jeweiligen Hard- und Software eine gemeinsame strukturierte Sprache für elektronische Geschäftsnachrichten bereitzustellen.

Das EDIFACT Format ist dabei nicht mit EDI selbst gleichzusetzen. EDI – Electronic Data Interchange – bezeichnet grundsätzlich den automatisierten elektronischen Austausch strukturierter Geschäftsdaten. EDIFACT ist dagegen ein konkreter internationaler Nachrichtenstandard innerhalb dieser EDI-Welt.

Gerade in etablierten B2B-Prozessen spielt der Standard weiterhin eine wichtige Rolle. Handel, Logistik, Fertigung, Automotive und Energie gehören zu den Bereichen, in denen EDIFACT beziehungsweise branchenspezifische Ausprägungen seit vielen Jahren verwendet werden. Wettbewerber wie SEEBURGER, Magic Software und TrueCommerce führen Nachrichtentypen wie ORDERS, ORDRSP, DESADV und INVOIC weiterhin als zentrale EDIFACT-Nachrichten.

Gleichzeitig verändert sich die Integrationslandschaft. XML-basierte Standards, APIs, Cloud-Integration, Peppol und gesetzliche E-Invoicing-Vorgaben ergänzen klassische EDI-Architekturen. Für Unternehmen stellt sich deshalb nicht die Frage, ob EDIFACT grundsätzlich „alt“ oder „modern“ ist. Entscheidend ist vielmehr, für welchen Geschäftsprozess, Handelspartner und regulatorischen Kontext welches Format sinnvoll ist.

Dieser Leitfaden beantwortet deshalb unter anderem: Was ist EDIFACT? Wie funktioniert das EDIFACT Format? Wie sind EDIFACT Dokumente aufgebaut? Welche Rolle spielen ORDERS, ORDRSP, DESADV und INVOIC? Wie funktioniert SAP IDoc EDIFACT? Was unterscheidet EDIFACT XML? Und kann eine EDIFACT Rechnung auch unter den aktuellen deutschen E-Rechnungsvorgaben eingesetzt werden?

---

Das Wichtigste zu EDIFACT in Kürze

EDIFACT ist ein international standardisiertes Regelwerk für den strukturierten elektronischen Austausch von Geschäftsnachrichten. Die Syntax ist unabhängig von konkreten ERP-Systemen und ermöglicht es Geschäftspartnern, beispielsweise Bestellung, Lieferung und Rechnung ohne erneute manuelle Datenerfassung auszutauschen.

Für die Einordnung sind insbesondere folgende Punkte wichtig:

• EDI bezeichnet das übergeordnete Konzept des elektronischen Datenaustauschs; EDIFACT ist ein konkreter EDI-Nachrichtenstandard.
• Ein EDIFACT Format besteht aus definierten Nachrichten, Segmenten, Datenelementen, Qualifiern und Code-Listen.
• Typische EDIFACT Dokumente sind ORDERS für Bestellungen, ORDRSP für Bestellantworten beziehungsweise Auftragsbestätigungen, DESADV für Lieferavise und INVOIC für Rechnungen.
• Eine EDIFACT Rechnung verwendet typischerweise den Nachrichtentyp INVOIC.
• Eine EDIFACT Auftragsbestätigung wird in vielen Szenarien mit ORDRSP abgebildet.
• SAP IDoc EDIFACT beschreibt kein einzelnes Format: Ein SAP IDoc wird vielmehr typischerweise über Middleware auf EDIFACT gemappt oder umgekehrt.
• EDIFACT XML sind unterschiedliche Syntaxwelten. Middleware kann jedoch zwischen beiden Darstellungen konvertieren.
• SAP Integration Suite unterstützt B2B-/EDI-Integrationen und bietet unter anderem Integration Advisor sowie einen EDI-to-XML-Konverter für EDIFACT.
• Eine EDIFACT-INVOIC-Nachricht ist nicht automatisch eine gesetzeskonforme deutsche E-Rechnung. Das BMF erlaubt aber weiterhin vereinbarte EDI-Verfahren wie EDIFACT, wenn die umsatzsteuerlich erforderlichen Angaben richtig und vollständig extrahiert werden können.

---

Inhaltsverzeichnis

---

EDIFACT Definition: Was ist EDIFACT?

Die EDIFACT Definition lautet ausgeschrieben:

Electronic Data Interchange for Administration, Commerce and Transport.

UN/EDIFACT stellt Regeln, Verzeichnisse und standardisierte Nachrichtentypen für den elektronischen Austausch strukturierter Geschäftsdaten bereit. Die UNECE verweist dabei unter anderem auf standardisierte Message Types, die Syntaxregeln nach ISO 9735 sowie Implementierungs- und Message-Design-Guidelines.

Vereinfacht formuliert beantwortet EDIFACT die Frage:

Wie müssen Geschäftsinformationen strukturiert werden, damit zwei unterschiedliche IT-Systeme dieselbe Nachricht eindeutig interpretieren können?

Eine Bestellung enthält beispielsweise Informationen zu Käufer und Verkäufer, Bestellnummer, Datum, Artikeln, Mengen und Lieferterminen.

Ohne Standard könnte jedes Unternehmen diese Informationen in einer eigenen Struktur übertragen. Der Empfänger müsste für jeden Partner ein individuelles Format interpretieren.

Das EDIFACT Format schafft dagegen eine gemeinsame technische Grundlage. Datenelemente, Segmente, Nachrichtentypen und Codewerte erhalten definierte Bedeutungen und Positionen.

Dadurch ist EDIFACT unabhängig davon einsetzbar, ob Sender und Empfänger dasselbe ERP-System verwenden.

---

Was ist der Unterschied zwischen EDI und EDIFACT?

Die Begriffe EDI und EDIFACT werden häufig synonym verwendet. Fachlich ist das nicht korrekt.

EDI steht für Electronic Data Interchange und bezeichnet allgemein den strukturierten elektronischen Austausch von Geschäftsinformationen zwischen Unternehmen beziehungsweise IT-Systemen.

EDIFACT ist ein standardisiertes Nachrichtenformat beziehungsweise Regelwerk, das für einen solchen EDI-Prozess eingesetzt werden kann.

Vereinfacht:

EDI = Methode beziehungsweise Integrationskonzept

EDIFACT = konkreter Nachrichtenstandard innerhalb von EDI

Neben EDIFACT existieren weitere EDI-Standards und strukturierte Formate, beispielsweise ANSI ASC X12 oder branchenspezifische Standards. Auch XML-basierte Geschäftsdokumente können Bestandteil einer EDI-Architektur sein. TrueCommerce und Magic Software grenzen EDI und EDIFACT ebenfalls auf diese Weise voneinander ab.

Für ein Integrationsprojekt ist diese Trennung wichtig.

Wenn ein Unternehmen sagt:

„Wir brauchen EDI“,

ist damit noch nicht festgelegt:

welche Nachrichtentypen eingesetzt werden, welches Format verwendet wird, welche Version gilt, welche Partneranforderungen existieren oder über welchen Kommunikationskanal die Nachrichten übertragen werden.

---

Wie funktioniert EDIFACT im elektronischen Datenaustausch?

Ein typischer EDIFACT-Prozess beginnt im ERP-System des Senders.

Nehmen wir eine Bestellung als Beispiel.

Ein Einkäufer erstellt in seinem ERP-System eine Bestellung. Die dort verwendete interne Datenstruktur entspricht zunächst dem Datenmodell des eigenen Systems. Anschließend übernimmt eine EDI- oder Integrationsplattform die relevanten Geschäftsdaten und mappt sie auf den EDIFACT-Nachrichtentyp ORDERS.

Die Nachricht wird validiert und anschließend über den vereinbarten technischen Kanal an den Lieferanten übertragen.

Auf Empfängerseite findet der umgekehrte Prozess statt:

ERP-Daten → Mapping → EDIFACT → Übertragung → EDIFACT → Mapping → Zielsystem

Der Empfänger muss die Nachricht damit nicht manuell abtippen. Das Zielsystem kann Bestellnummer, Artikel, Menge, Termine und weitere Informationen strukturiert übernehmen.

Auf diese Weise können komplette B2B-Prozessketten elektronisch abgebildet werden.

Ein typischer Ablauf könnte beispielsweise lauten:

ORDERS → ORDRSP → DESADV → RECADV → INVOIC → REMADV

Dabei repräsentiert jede Nachricht einen anderen Geschäftsvorgang.

---

Wie ist das EDIFACT Format aufgebaut?

Das EDIFACT Format basiert auf einer hierarchischen Struktur aus Datenelementen, Segmenten, Nachrichten und Interchanges.

Die Syntax folgt standardisierten Regeln. EDIFACT verwendet dabei in der klassischen Darstellung Trennzeichen anstelle ausführlicher XML-Tags. Das macht Nachrichten kompakt, für Menschen aber auf den ersten Blick vergleichsweise schwer lesbar.

Datenelemente

Datenelemente sind die kleinsten fachlichen Informationseinheiten.

Beispiele sind:

eine Artikelnummer, ein Datum, eine Menge, eine Währung oder ein Preis.

Ihre Bedeutung ergibt sich aus ihrer definierten Position und gegebenenfalls einem Qualifier.

Composite Data Elements

Mehrere logisch zusammengehörige Datenelemente können zu einem zusammengesetzten Datenelement zusammengefasst werden.

Ein Datum kann beispielsweise zusätzlich ein Formatkennzeichen enthalten.

Segmente

Segmente gruppieren fachlich zusammengehörige Informationen.

Typische Segmentnamen sind beispielsweise:

BGM für Informationen zum Dokument,

DTM für Datum und Zeit,

NAD für beteiligte Parteien,

RFF für Referenzen,

LIN für Positionen,

QTY für Mengen und

MOA für Geldbeträge.

SEEBURGER beschreibt Segmente entsprechend als funktionale Zusammenfassungen logisch zusammengehöriger Datenelemente.

Nachrichten

Eine Nachricht fasst alle für einen Geschäftsvorgang relevanten Segmente zusammen.

Sie beginnt typischerweise mit UNH und endet mit UNT.

Ein Beispiel ist eine ORDERS-Nachricht für eine Bestellung.

Interchange

Der gesamte Datenaustausch wird von einem Interchange-Umschlag umgeben.

Typisch sind:

UNB als Beginn des Interchange und

UNZ als Ende.

Optional können unter anderem UNA zur Definition von Servicezeichen sowie Gruppenstrukturen verwendet werden.

---

EDIFACT Beispiel: Wie sieht eine Nachricht aus?

Ein bewusst vereinfachtes EDIFACT Beispiel für eine Bestellung könnte so aussehen:

UNA:+.? ' UNB+UNOC:3+BUYER+SUPPLIER+260915:1200+000001' UNH+1+ORDERS:D:96A:UN' BGM+220+PO12345+9' DTM+137:20260915:102' NAD+BY+123456789::9' NAD+SU+987654321::9' LIN+1++ABC123:SA' QTY+21:10:PCE' UNT+8+1' UNZ+1+000001'

Dieses EDIFACT Beispiel dient ausschließlich dazu, das Strukturprinzip zu verdeutlichen. Es ist keine vollständige produktive Partnernachricht.

UNB eröffnet den Interchange.

UNH startet die konkrete Nachricht und identifiziert sie hier als ORDERS.

BGM enthält zentrale Dokumentinformationen.

DTM transportiert Datumsinformationen.

NAD beschreibt beteiligte Parteien.

LIN eröffnet eine Position.

QTY enthält die zugehörige Menge.

UNT beendet die Nachricht.

UNZ beendet den Interchange.

In einem realen Projekt kommen deutlich mehr fachliche Regeln hinzu. Entscheidend sind beispielsweise die vereinbarte EDIFACT-Version, das verwendete Subset, Partner-Qualifier, Code-Listen, Muss-/Kann-Felder und die konkrete Message Implementation Guideline.

Eine technisch syntaktisch lesbare Nachricht ist deshalb noch nicht automatisch fachlich korrekt für einen bestimmten Handelspartner.

---

Welche EDIFACT Dokumente und Nachrichtentypen gibt es?

Unter EDIFACT Dokumente werden in der Praxis meist die standardisierten Message Types verstanden.

Zu den besonders verbreiteten gehören:

EDIFACT-Nachricht	Bedeutung	Typischer Geschäftsprozess
ORDERS	Bestellung	Einkauf / Vertrieb
ORDRSP	Bestellantwort	Auftragsbestätigung / Reaktion auf Bestellung
ORDCHG	Bestelländerung	Einkauf
DESADV	Lieferavis	Logistik
RECADV	Wareneingangsmeldung	Logistik / Einkauf
INVOIC	Rechnung	Finance / Billing
REMADV	Zahlungsavis	Finance
PRICAT	Preisliste / Katalog	Einkauf / Vertrieb
DELFOR	Lieferabruf / Forecast	Supply Chain
DELJIT	Just-in-Time-Abruf	Automotive / Supply Chain
CONTRL	Kontroll-/Bestätigungsnachricht	Technische EDI-Verarbeitung

SEEBURGER, Magic Software und TrueCommerce führen diese Nachrichtentypen weiterhin als typische Bestandteile von EDIFACT-basierten EDI-Prozessen.

Die konkrete Bedeutung innerhalb eines Projekts hängt jedoch immer vom vereinbarten Profil ab.

---

EDIFACT Auftragsbestätigung: Welche Nachricht wird verwendet?

Für das Neben-Keyword EDIFACT Auftragsbestätigung ist vor allem der Nachrichtentyp ORDRSP relevant.

ORDRSP steht für Purchase Order Response beziehungsweise Order Response.

Die Nachricht dient dazu, auf eine zuvor empfangene Bestellung zu reagieren. Je nach vereinbarter Implementierung kann ein Lieferant damit beispielsweise bestätigen, ändern oder auf einzelne Inhalte einer Bestellung reagieren.

Ein typischer Prozess lautet:

Käufer → ORDERS → Lieferant

anschließend:

Lieferant → ORDRSP → Käufer

Wichtig ist dabei, eine EDIFACT Auftragsbestätigung nicht nur anhand des Nachrichtennamens zu implementieren.

Welche Qualifier verwendet werden, welche Abweichungen zulässig sind und wie Positionen bestätigt werden, muss zwischen den Geschäftspartnern beziehungsweise im verwendeten Branchenprofil eindeutig definiert sein.

Gerade bei automatisierten Prozessen ist dies entscheidend. Eine Auftragsbestätigung mit geänderter Menge oder verändertem Liefertermin darf nicht zwangsläufig genauso verarbeitet werden wie eine vollständige Bestätigung ohne Abweichungen.

---

EDIFACT Rechnung: Wie funktioniert INVOIC?

Eine EDIFACT Rechnung wird typischerweise über die Nachricht INVOIC abgebildet.

INVOIC kann strukturierte Rechnungsinformationen wie Dokumentidentifikation, Rechnungsdatum, Lieferant und Kunde, Währung, Referenzen, Positionen, Mengen, Preise, Steuern und Summen transportieren.

Dadurch kann eine Rechnung systemseitig verarbeitet werden, ohne dass die Informationen aus einem visuellen Dokument erneut manuell erfasst werden müssen.

Das typische Prinzip lautet:

ERP/Faktura → Mapping → EDIFACT INVOIC → Übertragung → Mapping → ERP/Accounts Payable

Das bedeutet allerdings nicht, dass jede INVOIC-Nachricht automatisch sämtliche gesetzlichen Anforderungen an eine E-Rechnung erfüllt.

Die regulatorische Bewertung muss getrennt von der rein technischen EDIFACT-Konformität vorgenommen werden.

Das ist insbesondere seit Einführung der deutschen B2B-E-Rechnung wichtig.

---

Welche Rolle spielen EDIFACT-Versionen, Directories und Subsets?

Das EDIFACT Format ist kein statisches Schema, das für alle Unternehmen identisch aussieht.

UN/EDIFACT arbeitet mit Verzeichnissen beziehungsweise Directory Releases. Ein häufig anzutreffender Bezeichner ist beispielsweise D.96A.

Zusätzlich werden in verschiedenen Branchen definierte Subsets oder Implementierungsrichtlinien verwendet.

Ein bekanntes Beispiel ist EANCOM, das den umfangreichen EDIFACT-Standard für Anforderungen der Konsumgüter- und Handelswelt konkretisiert. Im deutschen Energiemarkt existieren wiederum EDIFACT-basierte Prozesse im Umfeld von Edi@Energy. SEEBURGER und Magic Software beschreiben solche branchenspezifischen Ausprägungen als wichtigen Bestandteil der praktischen Nutzung.

Für ein Unternehmen reicht die Aussage

„Wir unterstützen ORDERS“

deshalb nicht aus.

Für eine belastbare Integration sollten mindestens folgende Punkte eindeutig feststehen:

Nachrichtentyp + Directory/Version + Subset/Profil + Partner-MIG + Code-Listen + Kommunikationsweg

Ein Handelspartner kann beispielsweise ORDERS erwarten, jedoch nur in einer bestimmten Directory-Version und mit individuell vorgegebenen Pflichtfeldern.

---

EDIFACT XML: Was ist der Unterschied?

Die Suche nach EDIFACT XML führt häufig zu einem Missverständnis:

EDIFACT ist nicht XML.

Beide Ansätze können strukturierte Geschäftsinformationen übertragen, verwenden jedoch unterschiedliche Syntaxkonzepte.

Merkmal	EDIFACT	XML
Grundprinzip	Segmente, Positionen, Trennzeichen	Elemente und Tags
Darstellung	kompakt	vergleichsweise ausführlich
Lesbarkeit	für Menschen schwieriger	meist leichter nachvollziehbar
Standardisierung	EDIFACT Directories / Messages	XML-Schemas und darauf basierende Standards
Typische Beispiele	ORDERS, DESADV, INVOIC	UBL, CII, proprietäre XML-Formate
Einsatz	klassisches B2B-/EDI-Umfeld	APIs, E-Invoicing, B2B, moderne Integrationen

XML ist eine allgemeine Markup-Sprache. Standards wie UBL oder UN/CEFACT Cross Industry Invoice verwenden XML als technische Syntax.

EDIFACT verwendet dagegen seine eigene kompakte Syntax nach den UN/EDIFACT-Regeln.

Beide Welten können technisch miteinander verbunden werden.

SAP Cloud Integration stellt beispielsweise einen EDI-to-XML-Converter bereit, der unter anderem EDIFACT-Nachrichten in XML transformieren kann.

Eine Konvertierung löst allerdings nicht automatisch die fachliche Mappingfrage.

Ein EDIFACT-Datenelement und ein XML-Element können unterschiedliche Semantik, Kardinalität oder Code-Listen besitzen. Deshalb muss zusätzlich ein fachlich korrektes Mapping definiert werden.

Weiterführend zum XML-basierten Geschäftsdokumentenstandard UBL:

UBL Format einfach erklärt: Aufbau, E-Rechnung, XML, Peppol und SAP

---

SAP IDoc EDIFACT: Wie funktioniert EDIFACT in SAP?

Beim Neben-Keyword SAP IDoc EDIFACT ist eine klare Abgrenzung besonders wichtig:

Ein SAP IDoc ist kein EDIFACT-Dokument.

Ein IDoc ist ein SAP-eigenes Nachrichtenformat. EDIFACT ist dagegen ein externer internationaler B2B-Nachrichtenstandard.

Der vorhandene Ausgangstext beschreibt deshalb korrekt folgendes Architekturprinzip:

SAP → IDoc → Middleware → Mapping → EDIFACT → Geschäftspartner

Inbound entsprechend:

Geschäftspartner → EDIFACT → Middleware → Mapping → SAP IDoc → SAP-Anwendung

Die Integrationsschicht übernimmt dabei die Transformation zwischen beiden Datenmodellen.

Ein Beispiel:

Ein SAP-System erzeugt für einen Geschäftsvorgang ein internes IDoc. Dieses kann beispielsweise Daten aus einem Bestell-, Rechnungs- oder Lieferprozess enthalten.

Die Middleware transformiert die SAP-Struktur anschließend auf den vereinbarten EDIFACT-Nachrichtentyp.

Auf Empfängerseite geschieht das Gleiche in umgekehrter Richtung.

Der bereits veröffentlichte Fink-Artikel zu SAP IDoc erläutert genau diese Abgrenzung zwischen EDI, EDIFACT und SAP IDoc und beschreibt IDocs weiterhin als relevant für etablierte B2B- und EDI-Szenarien.

Weiterführend:

SAP IDoc einfach erklärt: Aufbau, Verarbeitung, EDI und Monitoring

---

Welche Rolle spielt SAP Integration Suite bei EDIFACT?

Für moderne SAP-Integrationsarchitekturen kann die SAP Integration Suite eine zentrale Integrationsschicht bilden.

SAP Integration Advisor unterstützt B2B-, A2A- und B2G-Integrationen und arbeitet mit sogenannten Type Systems. SAP beschreibt UN/EDIFACT ebenso wie SAP IDoc als unterstützte beziehungsweise modellierbare Nachrichtenwelten innerhalb dieser B2B-Integrationslogik. Message Implementation Guidelines und Mapping Guidelines dienen dazu, konkrete Partneranforderungen zu dokumentieren und Mappings aufzubauen.

Cloud Integration kann anschließend die technische Laufzeit übernehmen.

Dazu gehören beispielsweise:

Transformation, Routing, Validierung, technische Konnektivität, Fehlerbehandlung und Monitoring.

Damit können Unternehmen klassische SAP IDoc EDIFACT-Szenarien in eine moderne Cloud-Integrationsarchitektur überführen, ohne die fachliche EDIFACT-Kommunikation mit ihren Geschäftspartnern zwangsläufig ersetzen zu müssen.

Weiterführend:

SAP Integration Suite – Fink IT-Solutions

SAP Integration Suite: APIs, EDI und Events für hybride IT-Landschaften

---

Wie werden EDIFACT Dokumente technisch übertragen?

EDIFACT definiert in erster Linie die Struktur der Nachricht, nicht automatisch den Übertragungskanal.

Das ist eine wichtige Unterscheidung.

Eine EDIFACT-Nachricht kann abhängig von Partnervereinbarung und Architektur beispielsweise über AS2, SFTP, FTPS, ein Value Added Network oder andere abgesicherte Übertragungswege transportiert werden. TrueCommerce nennt AS2, SFTP und FTPS sowie VANs als typische EDI-Übertragungsmechanismen.

Für ein Integrationsprojekt müssen deshalb zwei Fragen getrennt beantwortet werden:

Wie sieht die Nachricht aus?

und

Wie gelangt die Nachricht sicher von A nach B?

Das EDIFACT Format beantwortet primär die erste Frage.

Der Kommunikationskanal beantwortet die zweite.

---

Ist eine EDIFACT Rechnung eine E-Rechnung in Deutschland?

Hier ist eine differenzierte Antwort notwendig.

Seit dem 1. Januar 2025 gelten in Deutschland neue umsatzsteuerliche Regeln für elektronische Rechnungen zwischen inländischen Unternehmen. Das BMF beschreibt eine E-Rechnung insbesondere als Rechnung in einem strukturierten elektronischen Format, das eine elektronische Weiterverarbeitung ermöglicht. XRechnung und geeignete ZUGFeRD-Profile gehören zu den typischen Beispielen.

Das BMF stellt jedoch ausdrücklich klar, dass Rechnungsaussteller und Rechnungsempfänger auch ein anderes Format vereinbaren können.

Voraussetzung ist, dass das verwendete Format die richtige und vollständige Extraktion der nach dem Umsatzsteuergesetz erforderlichen Angaben ermöglicht.

Das BMF nennt in diesem Zusammenhang ausdrücklich EDI-Verfahren wie EDIFACT als weiterhin nutzbar, wenn diese Voraussetzungen erfüllt sind.

Damit gilt:

Eine EDIFACT INVOIC kann in Deutschland eine zulässige E-Rechnung darstellen – aber nicht allein deshalb, weil sie EDIFACT ist.

Entscheidend sind die konkrete Implementierung, die enthaltenen Rechnungsdaten und die gesetzlichen Voraussetzungen.

Weiterführend:

E-Rechnung mit SAP – Fink IT-Solutions

---

Ist EDIFACT mit EN 16931 kompatibel?

Auch hier ist eine präzise Einordnung erforderlich.

Für die europäische E-Rechnungsnorm EN 16931 werden im öffentlichen Beschaffungsumfeld vor allem zwei verpflichtend zu unterstützende Syntaxen geführt:

UBL 2.1 und UN/CEFACT Cross Industry Invoice (CII).

Die Europäische Kommission führt zusätzlich ein Syntax Binding für UN/EDIFACT INVOIC D16B in CEN/TS 16931-3-4:2017 auf. EDIFACT gehört jedoch nicht zu den beiden Syntaxen, die öffentliche Auftraggeber aufgrund der Richtlinie zwingend unterstützen müssen.

Der Unterschied ist wesentlich:

EDIFACT besitzt eine definierte EN-16931-Syntaxbindung.

Aber:

EDIFACT ist nicht eine der beiden verpflichtend zu akzeptierenden Standard-Syntaxen für öffentliche Auftraggeber.

Zusätzlich wurde im Mai 2026 eine neue Version EN 16931-1:2026 veröffentlicht. Die vorherige Version von 2017 wurde formal zurückgezogen, bleibt nach Angaben der Europäischen Kommission während einer Migrationsphase jedoch weiterhin compliant. Die Umstellung der technischen Komponenten und nationalen Implementierungen erfolgt schrittweise.

Für ein aktuelles Projekt bedeutet das:

Eine bestehende EDIFACT Rechnung sollte nicht pauschal als „EN-16931-konform“ bezeichnet werden. Entscheidend sind konkrete Syntaxbindung, Version, Profil, Empfängeranforderung und nationale Vorgaben.

---

Welche Vorteile bietet EDIFACT?

Automatisierter Datenaustausch

Geschäftsinformationen können direkt zwischen IT-Systemen übertragen und verarbeitet werden.

Weniger manuelle Erfassung

Bestellungen, Lieferavise oder Rechnungen müssen nicht erneut abgetippt werden.

Standardisierte Kommunikation

Geschäftspartner können trotz unterschiedlicher ERP-Systeme auf eine gemeinsame Struktur zurückgreifen.

Hohe Prozessgeschwindigkeit

Elektronische Nachrichten können unmittelbar nach ihrer Erzeugung übertragen und weiterverarbeitet werden.

Weniger Eingabefehler

Eine durchgängige elektronische Verarbeitung reduziert typische Fehler manueller Datenerfassung.

Etablierte B2B-Prozesse

EDIFACT ist in zahlreichen Branchen seit vielen Jahren etabliert. Dadurch existieren umfangreiche Partnernetzwerke, Branchenprofile und operative Erfahrungen.

Kompakte Nachrichtenstruktur

Im Vergleich zu ausführlichen XML-Dokumenten kann die EDIFACT-Syntax sehr kompakt sein.

Diese Vorteile erklären, warum EDIFACT trotz APIs, XML und Cloud-Integration weiterhin in vielen produktiven Lieferketten eingesetzt wird.

---

Welche Herausforderungen gibt es bei EDIFACT?

Standardisierung bedeutet nicht automatisch, dass zwei EDIFACT-Systeme ohne Abstimmung miteinander kommunizieren können.

Genau hier liegt eine der wichtigsten Herausforderungen.

Unterschiedliche Versionen

Geschäftspartner können verschiedene EDIFACT-Directories verwenden.

Branchenspezifische Subsets

Ein Handelsunternehmen kann beispielsweise andere Vorgaben nutzen als ein Energie- oder Automotive-Unternehmen.

Partnerindividuelle Guidelines

Auch innerhalb desselben Nachrichtentyps können Unternehmen unterschiedliche Pflichtfelder, Qualifier und Codewerte verlangen.

Komplexes Mapping

ERP-Daten müssen fachlich korrekt auf Segmente und Datenelemente abgebildet werden.

Fehleranalyse über mehrere Systeme

Ein Problem kann im Quellsystem, Mapping, Transport, EDIFACT-Parser oder Zielsystem entstehen.

Regulatorische Anforderungen

Insbesondere bei einer EDIFACT Rechnung genügt technische Nachrichtenkonformität nicht. Zusätzlich müssen die jeweils geltenden steuerlichen und E-Invoicing-Regeln erfüllt werden.

Legacy-Abhängigkeiten

Über Jahre gewachsene EDI-Landschaften enthalten häufig viele partnerindividuelle Mappings. Eine Änderung eines ERP-Systems kann deshalb größere Auswirkungen auf bestehende Integrationen haben.

---

Wo wird EDIFACT eingesetzt?

EDIFACT ist besonders für volumenstarke, wiederkehrende und strukturierte B2B-Prozesse geeignet.

Typische Bereiche sind:

Handel: Bestellungen, Bestellbestätigungen, Preiskataloge, Lieferavis und Rechnungen.

Automotive: Lieferabrufe, Feinabrufe, Versandinformationen und Supply-Chain-Kommunikation.

Logistik: Transportaufträge, Versand- und Empfangsinformationen.

Produktion: Materialversorgung und Lieferkettenintegration.

Energie: Stammdaten-, Zähler- und Marktkommunikation in EDIFACT-basierten Branchenprozessen.

Finance: Rechnungen und Zahlungsavise.

Damit unterstützt EDIFACT sowohl Procure-to-Pay- als auch Order-to-Cash-Prozesse.

---

EDIFACT oder API – welcher Ansatz ist besser?

Auch diese Frage lässt sich nicht pauschal beantworten.

EDIFACT eignet sich besonders für:

etablierte asynchrone B2B-Nachrichten, hohe Transaktionsvolumina und Geschäftsprozesse mit klar definierten Dokumenten.

APIs eignen sich häufig besser für:

gezielte synchrone Kommunikation, Echtzeitabfragen oder digitale Services.

Ein Unternehmen kann deshalb gleichzeitig APIs und EDIFACT verwenden.

Beispielsweise:

Ein Webshop fragt über eine API einen aktuellen Bestand ab.

Die daraus entstehende Bestellung wird anschließend über einen etablierten EDIFACT-ORDERS-Prozess an einen Lieferanten übertragen.

Die SAP Integration Suite unterstützt genau solche hybriden Integrationsmuster aus APIs, EDI und Events.

---

Best Practices für EDIFACT

Nachrichtentyp und Geschäftszweck zuerst definieren

Beginnen Sie nicht mit dem Mapping, bevor klar ist, welcher Geschäftsvorgang abgebildet werden soll.

Version und Partnerprofil eindeutig festhalten

Dokumentieren Sie Directory, Nachrichtentyp, Subset und Partner-MIG.

Standard vor Sonderlösung

Nutzen Sie etablierte Segmente, Qualifier und Branchenprofile, bevor proprietäre Erweiterungen entstehen.

Eingehend und ausgehend validieren

Eine Nachricht sollte sowohl vor dem Versand als auch nach dem Empfang technisch und fachlich geprüft werden.

End-to-End-Monitoring etablieren

Überwachen Sie nicht nur die Middleware. Auch SAP-IDoc-Status, Transport und fachliche Verarbeitung gehören zur Prozessüberwachung.

Fachliche Bestätigungen berücksichtigen

Eine technisch erfolgreich übertragene Nachricht bedeutet nicht automatisch, dass der Geschäftsvorgang fachlich akzeptiert wurde.

E-Invoicing getrennt prüfen

Bewerten Sie eine EDIFACT Rechnung zusätzlich gegen die regulatorischen Anforderungen des betreffenden Landes und Empfängers.

---

Do’s & Don’ts bei EDIFACT

Do

Definieren Sie Geschäftspartner, Message Type, Version und Implementierungsrichtlinie eindeutig. Dokumentieren und versionieren Sie Mappings. Testen Sie nicht nur Standardfälle, sondern auch Änderungen, Ablehnungen und fehlerhafte Nachrichten. Etablieren Sie Monitoring über den kompletten Datenfluss und prüfen Sie Rechnungsprozesse zusätzlich auf E-Invoicing-Konformität.

Don’t

Setzen Sie EDI und EDIFACT nicht gleich. Gehen Sie nicht davon aus, dass zwei ORDERS-Nachrichten automatisch identisch aufgebaut sind. Verwenden Sie nicht ungeprüft eine neuere Directory-Version, wenn der Partner eine andere Version erwartet. Bezeichnen Sie INVOIC nicht automatisch als gesetzeskonforme E-Rechnung und behandeln Sie ein erfolgreiches technisches Mapping nicht als Beweis für einen fachlich erfolgreichen Geschäftsprozess.

---

Schritt für Schritt EDIFACT im Unternehmen einführen

Schritt 1 – Geschäftsprozess auswählen

Definieren Sie zunächst, ob Bestellung, Auftragsbestätigung, Lieferung, Rechnung oder ein anderer Prozess digitalisiert werden soll.

Schritt 2 – Geschäftspartner abstimmen

Klären Sie, welche Nachrichten der Partner senden beziehungsweise empfangen kann.

Schritt 3 – Nachrichtentyp und Version definieren

Legen Sie beispielsweise ORDERS, ORDRSP, DESADV oder INVOIC sowie das konkrete Directory fest.

Schritt 4 – Subset und MIG festlegen

Definieren Sie die fachlichen Pflichtfelder, Code-Listen, Qualifier und Partnerregeln.

Schritt 5 – Internes Datenmodell analysieren

Prüfen Sie, wie die erforderlichen Daten im ERP-System vorhanden sind.

Bei SAP kann dies beispielsweise eine IDoc-basierte Struktur sein.

Schritt 6 – Mapping entwickeln

Ordnen Sie Quellfelder fachlich den EDIFACT-Segmenten und Datenelementen zu.

Schritt 7 – Kommunikationsweg einrichten

Definieren Sie beispielsweise AS2, SFTP oder den vereinbarten EDI-Service.

Schritt 8 – Validierung und Tests durchführen

Testen Sie Syntax, Mapping, Business Rules und Partneranforderungen.

Berücksichtigen Sie auch fehlerhafte und unvollständige Nachrichten.

Schritt 9 – Monitoring definieren

Legen Sie Verantwortlichkeiten, Alerts, Fehlerbehandlung und Wiederanlaufverfahren fest.

Schritt 10 – Kontinuierlich pflegen

EDIFACT-Schnittstellen sind keine einmalige Entwicklung.

Neue Geschäftspartner, geänderte Code-Listen, ERP-Migrationen, E-Invoicing-Regeln oder neue Partner-Guidelines erfordern kontinuierliche Governance.

---

Fazit – Warum EDIFACT weiterhin relevant ist

EDIFACT gehört zu den etabliertesten Standards für den automatisierten B2B-Datenaustausch.

Seine Stärke liegt in der klaren, standardisierten und maschinenlesbaren Abbildung von Geschäftsnachrichten. Mit ORDERS, ORDRSP, DESADV, INVOIC und zahlreichen weiteren Nachrichtentypen lassen sich komplette Lieferketten elektronisch verbinden.

Gleichzeitig darf EDIFACT nicht isoliert betrachtet werden.

EDI ist das übergeordnete Integrationskonzept. EDIFACT ist ein möglicher Nachrichtenstandard darin. SAP IDoc EDIFACT erfordert in der Regel ein Mapping zwischen SAP-interner und externer Struktur. XML-basierte Standards wiederum verfolgen ein anderes Syntaxmodell, können jedoch über moderne Middleware mit EDIFACT verbunden werden.

Für SAP-Unternehmen bedeutet das: Bestehende EDIFACT-Prozesse müssen mit der Einführung von SAP S/4HANA oder SAP Integration Suite nicht automatisch ersetzt werden.

SAP Integration Suite kann vielmehr dazu genutzt werden, etablierte EDI-Partnerprozesse in eine modernere Integrationsarchitektur einzubetten.

Die größte Aufmerksamkeit erfordert aktuell die EDIFACT Rechnung.

Nach den deutschen B2B-E-Rechnungsvorgaben können vereinbarte EDI-Verfahren wie EDIFACT weiterhin zulässig sein, wenn die erforderlichen Rechnungsangaben richtig und vollständig extrahiert werden können. Eine EDIFACT-INVOIC ist deshalb jedoch nicht automatisch eine gesetzeskonforme E-Rechnung.

Auch die europäische Norm EN 16931 muss differenziert betrachtet werden. Für öffentliche Auftraggeber bilden UBL und CII die verpflichtend unterstützten Syntaxen; für EDIFACT INVOIC existiert zwar eine CEN-Syntaxbindung, EDIFACT gehört jedoch nicht zur verpflichtenden Syntaxliste. Gleichzeitig befindet sich das EN-16931-Ökosystem seit Veröffentlichung von EN 16931-1:2026 in einer Übergangsphase.

Für Unternehmen lautet die entscheidende Frage daher nicht:

„Ist EDIFACT noch modern?“

Sondern:

„Ist EDIFACT für diesen Geschäftspartner, diesen Prozess, dieses ERP-System und diese regulatorische Anforderung weiterhin das richtige Integrationsformat?“

In vielen etablierten B2B-Szenarien lautet die Antwort auch 2026: Ja – sofern Architektur, Mapping, Monitoring und Compliance professionell umgesetzt sind.

---

Häufig gestellte Fragen zu EDIFACT