Die Bestellung eines Großkunden landet 2026 immer seltener im Warenkorb Ihres Shops -- sie kommt als strukturiertes Dokument direkt aus dem Beschaffungssystem des Kunden. Bereits über 90 Prozent (Digital Commerce 360) der B2B-Transaktionen laufen elektronisch, und ein großer Teil davon über EDI, den elektronischen Datenaustausch. Der zugrundeliegende Standard UN/EDIFACT umfasst über 200 (UN/CEFACT) Nachrichtentypen für Bestellungen, Lieferavise und Rechnungen. Wer als Lieferant für Konzern-Einkauf und öffentliche Auftraggeber lieferfähig bleiben will, braucht deshalb neben der Shop-Oberfläche einen zweiten, unsichtbaren Kanal: die maschinelle Anbindung per EDIFACT und VDA. Dieser Artikel erklärt die EDI-Grundlagen, die zentralen Nachrichtentypen, den Unterschied zwischen VAN und AS2 und zeigt, wie sich klassischer Dokumentenaustausch mit modernen Echtzeit-Schnittstellen zu einem hybriden Integrationsmodell verbinden lässt.
Warum Großkunden per EDI bestellen
Für einen Konzern-Einkauf ist die manuelle Bestellung im Webshop eines Lieferanten ein Bruch im Prozess. Große Beschaffungsorganisationen arbeiten mit zentralen ERP- und Einkaufssystemen, in denen Bedarfe, Budgets und Genehmigungen abgebildet sind. Eine Bestellung soll aus diesem System heraus entstehen, den Freigabeweg durchlaufen und ohne erneute Eingabe beim Lieferanten ankommen. Genau das leistet EDI: Es überträgt Geschäftsdokumente von System zu System in einem standardisierten, maschinenlesbaren Format -- ohne dass ein Mensch abtippt. Der Effekt ist messbar. Der B2B-E-Commerce in den USA wuchs 2025 um 13 Prozent auf 2,93 Billionen US-Dollar (Digital Commerce 360), und der Zuwachs entsteht vor allem dort, wo Bestellungen automatisiert in die Systeme der Kunden hineinlaufen.
EDI ist keine neue Mode, sondern seit Jahrzehnten das Rückgrat des professionellen Handels. Allein auf Basis des EDIFACT-Subsets EANCOM werden in Deutschland jährlich rund 1 Milliarde (GS1 Germany) Rechnungen elektronisch übermittelt. Für den Lieferanten bedeutet die EDI-Fähigkeit oft mehr als Effizienz: Sie ist Voraussetzung dafür, überhaupt gelistet zu werden. In vielen Rahmenverträgen und Ausschreibungen ist eine funktionierende EDI-Anbindung ein Muss-Kriterium. Wer sie nicht bietet, fällt aus der automatisierten Beschaffung heraus -- unabhängig davon, wie gut der Shop selbst gestaltet ist.
EDI ergänzt den Shop, es ersetzt ihn nicht
Was EDI und EDIFACT technisch sind
EDI steht für Electronic Data Interchange -- den strukturierten Austausch von Geschäftsdokumenten zwischen den Anwendungssystemen zweier Partner. EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) ist der von den Vereinten Nationen gepflegte, branchenübergreifende Standard dafür. Er definiert eine feste Grammatik: Eine Nachricht besteht aus Segmenten, Segmente aus Datenelementen. Ein Umschlag aus Kopf- und Fußsegmenten (UNB/UNZ für den Austausch, UNH/UNT für die einzelne Nachricht) klammert die Nutzdaten ein. Weil der Standard so präzise ist, kann jedes empfangende System eine EDIFACT-Datei ohne individuelle Absprache interpretieren -- das ist der Kern der Interoperabilität.
Weil der volle EDIFACT-Standard sehr umfangreich ist, haben Branchen eigene, verbindliche Teilmengen definiert. Im Konsumgüter- und Handelsbereich ist das EANCOM von GS1 der am weitesten verbreitete Standard, ein UN/EDIFACT-Subset, das weltweit von rund 126.000 (GS1) Unternehmen eingesetzt wird. In der Automobilindustrie übernimmt der VDA diese Rolle. Diese Subsets legen fest, welche Segmente und Felder für einen bestimmten Geschäftsvorfall Pflicht sind, und reduzieren so die Interpretationsspielräume. Der UN/EDIFACT-Standard selbst wird halbjährlich in sogenannten Directories fortgeschrieben -- die Nachrichtennamen sind stets sechs Zeichen lang, etwa ORDERS oder INVOIC (UN/CEFACT).
Segment und Nachricht
Jede EDIFACT-Nachricht ist aus Segmenten aufgebaut, die Datenelemente bündeln. Kopf- und Fußsegmente umschließen die Nutzdaten und machen den Beleg eindeutig zuordenbar.
UN/EDIFACT
Der branchenübergreifende UN-Standard mit über 200 Nachrichtentypen (UN/CEFACT). Halbjährliche Directories sichern eine gemeinsame, versionierte Sprache über Ländergrenzen hinweg.
EANCOM
Das GS1-Subset für Handel und Konsumgüter -- der verbreitetste EDI-Standard in Deutschland, Grundlage für rund eine Milliarde Rechnungen pro Jahr (GS1 Germany).
VDA und ODETTE
Die Standards der Automobilindustrie. Die früheren VDA-Festsatzformate sind heute EDIFACT-basiert, etwa DELFOR als Lieferabruf (VDA).
Validierbar
Weil Struktur und Pflichtfelder normiert sind, lässt sich jede Nachricht gegen das Schema prüfen. Formfehler fallen auf, bevor der Beleg in die Auftragsverarbeitung läuft.
Maschinenlesbar
Bestellungen, Lieferungen und Rechnungen fließen ohne manuelle Erfassung von System zu System. Das ist der eigentliche Grund, warum Großkunden EDI verlangen.
Die zentralen Nachrichtentypen im Bestellprozess
Ein vollständiger Bestellvorgang bildet sich in EDIFACT über eine Kette klar definierter Nachrichten ab. Die drei am häufigsten genutzten Typen sind ORDERS, DESADV und INVOIC (GS1 Germany) -- ergänzt um die Auftragsbestätigung ORDRSP. Jede Nachricht trägt eine eindeutige Referenz, sodass Bestellung, Lieferung und Rechnung über den gesamten Vorgang zusammenhängen. Diese Referenzklammer ist entscheidend: Sie erlaubt es dem ERP, eingehende Belege automatisch dem richtigen Vorgang zuzuordnen und Abweichungen zu erkennen.
| Nachricht | Bedeutung | Richtung | Inhalt |
|---|---|---|---|
| ORDERS | Bestellung | Kunde an Lieferant | Positionen, Mengen, Preise, Liefertermin, Referenzen |
| ORDRSP | Auftragsbestätigung | Lieferant an Kunde | Bestätigung, Änderungen, Verfügbarkeit, bestätigte Termine |
| DESADV | Lieferavis | Lieferant an Kunde | Sendungsinhalt, Packstruktur, Versanddaten, Lieferschein |
| INVOIC | Rechnung | Lieferant an Kunde | Rechnungspositionen, Steuern, Zahlungsbedingungen |
| DELFOR | Lieferabruf | Kunde an Lieferant | Rahmenmengen und Termine, typisch in der Automobilindustrie |
In der Automobilindustrie ist die Kette oft dichter getaktet. Der VDA hat bereits seit den 1970er-Jahren eigene EDI-Empfehlungen für die Kommunikation zwischen Herstellern und Zulieferern definiert (VDA). Heute sind diese Empfehlungen EDIFACT-basiert: Der Lieferabruf DELFOR steuert Rahmenmengen und Termine, das Lieferavis DESADV kündigt die Sendung an. Für Zulieferer ist die korrekte, fristgerechte Nachrichtenverarbeitung unmittelbar geschäftsrelevant, weil sie in Lieferantenbewertungen und Konformitätsrahmen wie MMOG/LE einfließt (VDA). Ein Fehler in der Nachrichtenverarbeitung ist hier kein technisches Detail, sondern ein Reputationsrisiko in der Lieferkette.
VAN oder AS2: die Wege der Übertragung
Ein EDIFACT-Dokument ist zunächst nur eine Datei -- entscheidend ist, wie sie zum Partner gelangt. Historisch lief das über ein Value Added Network (VAN), eine Art betriebenes Postnetz für EDI. Beide Partner unterhalten dort ein Postfach, der VAN-Betreiber nimmt Nachrichten entgegen, protokolliert sie und stellt sie zu. Das VAN entkoppelt die Partner technisch und übernimmt Konvertierung und Nachverfolgung. Der Preis dafür sind transaktions- oder volumenbasierte Gebühren und die Abhängigkeit von einem Vermittler.
Die modernere Alternative ist AS2 (Applicability Statement 2), ein Protokoll für den direkten, verschlüsselten Austausch über das Internet. Die Partner senden ihre Nachrichten Punkt zu Punkt per HTTPS, signieren sie digital und erhalten mit der MDN-Quittung eine überprüfbare Empfangsbestätigung. AS2 vermeidet laufende Transaktionsgebühren und beschleunigt die Übertragung, verlangt aber, dass beide Seiten Zertifikate und Endpunkte pflegen. In der Praxis existieren beide Wege nebeneinander: Welcher genutzt wird, gibt in aller Regel der Großkunde vor. Eine tragfähige Anbindung sollte deshalb transportunabhängig sein und beide Wege bedienen können.
| Merkmal | VAN (Mailbox-Netz) | AS2 (Punkt-zu-Punkt) |
|---|---|---|
| Prinzip | Betriebenes Zwischennetz mit Postfächern | Direkte Verbindung über HTTPS |
| Kosten | Transaktions- oder volumenbasiert | Keine Transaktionsgebühr, eigener Betrieb |
| Quittung | Netzinterne Protokollierung | Signierte MDN-Empfangsbestätigung |
| Aufwand | Gering, Vermittler betreibt | Zertifikate und Endpunkte selbst pflegen |
| Geschwindigkeit | Abhängig vom Zustellintervall | Nahezu in Echtzeit |
EDI und API als hybrides Modell
Der spannendste Trend ist nicht EDI gegen API, sondern EDI mit API. Klassischer Dokumentenaustausch und moderne Echtzeit-Schnittstellen haben unterschiedliche Stärken, und 2026 verschmelzen sie zu hybriden Integrationsmodellen. EDI ist stark im standardisierten, rechtsverbindlichen Austausch großer Belegmengen -- die Bestellung, die Auftragsbestätigung, das Lieferavis, die Rechnung. Diese Dokumente sind asynchron: Sie werden erzeugt, übertragen und verarbeitet, ohne dass jemand darauf wartet. Eine REST- oder GraphQL-Schnittstelle dagegen glänzt bei synchronen Einzelabfragen, die im Moment der Anfrage eine aktuelle Antwort brauchen.
In der Praxis kombiniert man beides. Der Bestellprozess läuft als Dokumentenkette über EDIFACT, während der Kunde parallel über eine API in Echtzeit prüft, was er gerade braucht. Diese Aufteilung spielt die jeweiligen Stärken aus und vermeidet, ein Werkzeug für die falsche Aufgabe zu missbrauchen (Projekterfahrung).
Preise per API
Kundenindividuelle Netto-Preise und Staffeln ändern sich laufend. Eine Echtzeit-Abfrage liefert vor der Bestellung den gültigen Preis, statt ihn aus einem statischen Katalog zu raten.
Bestand per API
Verfügbarkeit ist volatil. Eine synchrone Bestandsabfrage zeigt dem Besteller, ob die gewünschte Menge lieferbar ist, bevor die ORDERS-Nachricht überhaupt entsteht.
Tracking per API
Der Sendungsstatus wird häufig abgefragt und selten in ein Dokument gegossen. Eine API liefert den aktuellen Stand on demand, ergänzend zum DESADV-Lieferavis.
Asynchrone Dokumente, synchrone Auskünfte
Mapping auf Shopware und ERP
Zwischen der EDIFACT-Nachricht und den Datenstrukturen von Shop und ERP liegt die eigentliche Arbeit: das Mapping. Eine ORDERS-Nachricht spricht in Segmenten und Codes, ein Shopware-Shop und ein ERP sprechen in ihren eigenen Feldern und Objekten. Das Mapping übersetzt beide Richtungen: Es zerlegt die eingehende Bestellung in Kunde, Positionen, Mengen und Konditionen und setzt umgekehrt aus den Auftragsdaten die ausgehende Auftragsbestätigung, das Lieferavis und die Rechnung zusammen. Dieser Übersetzungslayer ist der Kern eines jeden EDI-Projekts.
Die häufigste Fehlerquelle ist nicht die Technik, sondern die Datenpflege. Artikelnummern des Kunden weichen von den eigenen ab, Einheiten sind unterschiedlich codiert, ein Preis fehlt oder eine Referenz passt nicht. Ohne saubere Stammdaten scheitert das Mapping an genau diesen Kleinigkeiten (Projekterfahrung). Eine gepflegte PIM-Integration mit eindeutigen Identifikatoren und Cross-Referenzen zwischen Kunden- und Lieferantenartikelnummern ist deshalb die stille Voraussetzung einer stabilen Anbindung. Das Mapping ist ein klar umrissenes Schnittstellenprojekt, das sich sauber von der übrigen Shop-Entwicklung trennen lässt.
- Nachricht empfangen und validieren: Eingehende ORDERS gegen das Schema und die vereinbarte Teilmenge prüfen, Formfehler früh abfangen.
- Felder mappen: Kunden-, Artikel- und Konditionsfelder auf die Objekte von Shop und ERP übersetzen, Einheiten und Codes normalisieren.
- Artikel referenzieren: Kundenartikelnummern über eine Cross-Referenz auf die eigenen Nummern auflösen.
- Auftrag anlegen: Aus der Bestellung einen Auftrag in der Auftragsverarbeitung erzeugen, Referenzen für die Belegkette setzen.
- Rückmeldungen erzeugen: ORDRSP, DESADV und INVOIC aus den Auftragsdaten generieren und normkonform übergeben.
- Fehler behandeln: Nicht zuordenbare Nachrichten in eine kontrollierte Klärung leiten, statt sie stumm zu verwerfen.
Abgrenzung: Punchout, API und E-Rechnung
EDI wird leicht mit benachbarten Integrationsmustern verwechselt, obwohl jedes einen anderen Zweck erfüllt. Beim Punchout-Verfahren über OCI verlässt der Besteller kurzzeitig sein Einkaufssystem, stöbert live im Katalog des Lieferanten und überträgt den gefüllten Warenkorb zurück -- es geht um die interaktive Katalogsitzung im Beschaffungssystem, nicht um den asynchronen Belegaustausch. Eine REST- oder GraphQL-Architektur wiederum bedient synchrone System-zu-System-Aufrufe in Echtzeit. EDI dagegen ist der standardisierte, asynchrone Austausch großer Belegmengen mit festen Handelspartnern. Die drei Muster konkurrieren nicht, sie ergänzen sich in einer durchdachten Systemlandschaft.
Eng verwandt, aber nicht identisch, ist die Rechnung. Die INVOIC-Nachricht ist die klassische EDI-Rechnung, und unter den gesetzlich genannten Bedingungen kann EDI als strukturierte E-Rechnung dienen. Wie sich das in die kommende E-Rechnungspflicht ab 2027 und die Formate ZUGFeRD und XRechnung einfügt, behandelt ein eigener Beitrag. Und wer seine Stamm- und Bewegungsdaten für EDI ohnehin ordnet, schafft zugleich die Basis für weitere Datenpflichten wie den digitalen Produktpass. Sauber gepflegte Daten sind die gemeinsame Grundlage all dieser Anforderungen.
EDI, Punchout und API sind keine konkurrierenden Lager. Sie sind drei Werkzeuge für drei Aufgaben -- Belegaustausch, Katalogsitzung und Echtzeitauskunft. Die Kunst liegt darin, jedes dort einzusetzen, wo es seine Stärke hat.
Onboarding von Handelspartnern
Eine EDI-Anbindung ist selten fertig, wenn der erste Partner läuft. Jeder neue Großkunde bringt seine eigene Teilmenge, seine Artikelnummern und seine Vorgaben zu Transport und Feldern mit. Das Partner-Onboarding ist deshalb ein wiederkehrender Prozess, kein einmaliges Projekt. Weil jährlich Milliarden von EANCOM-Nachrichten zwischen Handelspartnern ausgetauscht werden (GS1 Germany), lohnt es sich, das Onboarding als geübten Ablauf zu gestalten -- mit einem verbindlichen Feld-Mapping, einer Testphase mit echten Belegen und einer überwachten Produktivschaltung.
Gerade die Testphase entscheidet über die Stabilität. Der Gesamt-B2B-Umsatz stieg 2025 nur um 0,4 Prozent (Digital Commerce 360), während die digitalen Kanäle deutlich zulegten -- der Druck, jede neue Anbindung sauber und schnell produktiv zu bekommen, ist real. Ein strukturiertes Onboarding fängt die kundenindividuellen Eigenheiten früh ab, statt sie im Live-Betrieb zu entdecken.
- Teilmenge und Nachrichtentypen mit dem Einkauf des Kunden verbindlich festlegen
- Transportweg klären: VAN oder AS2, Zertifikate und Endpunkte abstimmen
- Feld-Mapping und Artikelnummern-Cross-Referenz dokumentieren
- Testlauf mit echten Belegen über die gesamte Nachrichtenkette fahren
- Fehlerbehandlung und Eskalationsweg für nicht zuordenbare Nachrichten definieren
- Produktivschaltung überwacht starten und die ersten Belege eng begleiten
Onboarding als wiederholbaren Prozess anlegen
Quellen und Studien