Im B2B-Handel werden noch immer Bestellungen per E-Mail, PDF oder Telefon aufgegeben — mit Kosten von über $30 pro Vorgang (GS1 US). Gleichzeitig wächst der globale EDI-Softwaremarkt von $2,57 Milliarden (2026) auf prognostizierte $6,49 Milliarden bis 2034 bei einem CAGR von 12,3 Prozent (Fortune Business Insights). Der Grund: Wer Schnittstellen zwischen Shop, ERP und Handelspartnern über EDI automatisiert, senkt Transaktionskosten auf unter einen Dollar, reduziert manuelle Fehler und beschleunigt Bestellprozesse um bis zu 80 Prozent. Dieser Guide zeigt, welche EDI-Standards 2026 relevant sind, wie die Integration mit SAP, Dynamics oder JTL funktioniert und warum der Hybrid-Ansatz aus EDI und API zum dominierenden Modell wird.
Was ist EDI und warum ist es 2026 relevant?
EDI steht für Electronic Data Interchange und bezeichnet den standardisierten, elektronischen Austausch von Geschäftsdokumenten zwischen Unternehmen. Statt eine Bestellung als PDF zu versenden und sie beim Empfänger manuell ins ERP-System einzutippen, wird das Dokument in einem maschinenlesbaren Format direkt von System zu System übertragen — ohne menschlichen Eingriff.
Der breitere EDI-Markt erreicht laut Maximize Market Research ein Volumen von $41 Milliarden im Jahr 2025 und soll bis 2032 auf $91,21 Milliarden anwachsen — bei einem CAGR von 12,1 Prozent (Maximize Market Research). Dieses Wachstum wird vor allem durch zwei Entwicklungen getrieben: Zum einen konvergieren B2B-Seller E-Commerce und EDI zunehmend zu einem einheitlichen Auftragseingang (Digital Commerce 360). Zum anderen steigen die regulatorischen Anforderungen an strukturierte elektronische Geschäftsdokumente, etwa durch die E-Rechnungspflicht oder das europäische PEPPOL-Netzwerk.
Für B2B-Shop-Betreiber ist die Relevanz konkret: Große Handelspartner, Einzelhandelsketten und Marktplätze verlangen EDI-Anbindung als Voraussetzung für die Zusammenarbeit. Wer diese Anforderung nicht erfüllt, verliert Aufträge. Gleichzeitig zeigt die Praxis: Ohne EDI sind 60 Prozent der B2B-Transaktionen von Datenanomalien betroffen — falsche Mengen, fehlende Artikelnummern, abweichende Preise (Commport).
Die technische Grundlage bilden standardisierte Nachrichtenformate und sichere Übertragungsprotokolle. EDI-Nachrichten werden über Protokolle wie AS2 (Applicability Statement 2), OFTP2 (Odette File Transfer Protocol 2) oder SFTP ausgetauscht. Viele Unternehmen nutzen sogenannte Value Added Networks (VANs) — spezialisierte Netzwerke, die als Vermittler zwischen Sender und Empfänger fungieren und Formatkonvertierung, Nachrichtenverfolgung und Archivierung übernehmen. Alternativ setzen immer mehr Unternehmen auf Punkt-zu-Punkt-Verbindungen über AS2, bei denen die Kommunikation direkt und ohne Zwischenhändler stattfindet. Beide Modelle haben Vor- und Nachteile: VANs bieten Komfort und Partner-Management, AS2 bietet niedrigere laufende Kosten und mehr Kontrolle.
EDI-Standards im Überblick: EDIFACT, X12 und UBL
Die Wahl des richtigen EDI-Standards hängt davon ab, in welcher Region und Branche ein Unternehmen operiert. Drei Standards dominieren den Markt (Cleo/Coneksion):
| Merkmal | UN/EDIFACT | ANSI X12 | UBL 2.1 |
|---|---|---|---|
| Verbreitung | Europa, Asien, Afrika | USA, Kanada | EU (öffentlich), PEPPOL |
| Herausgeber | UN/CEFACT | ASC (ANSI) | OASIS |
| Format | Proprietäres Textformat | Proprietäres Textformat | XML-basiert |
| Typische Branchen | Handel, Automotive, Logistik | Retail, Healthcare, Finanzen | Öffentliche Verwaltung, B2G |
| Nachrichtentypen | ORDERS, DESADV, INVOIC etc. | 850, 856, 810 etc. | Invoice, Order, DespatchAdvice |
| Transportprotokolle | AS2, OFTP2, SFTP | AS2, SFTP, VAN | AS4, PEPPOL, REST API |
| Zukunftsfähigkeit | Stabil, große Installed Base | Stabil, US-dominiert | Wachsend, API-kompatibel |
In der Praxis bedeutet das: Wer mit europäischen Handelspartnern arbeitet, kommt an EDIFACT kaum vorbei. Wer US-amerikanische Partner bedient, benötigt X12. Und wer im öffentlichen Sektor aktiv ist oder auf das PEPPOL-Netzwerk setzt, nutzt UBL. Viele Middleware-Lösungen beherrschen heute alle drei Standards und konvertieren zwischen ihnen.
Ein häufiges Szenario in der Praxis: Ein deutscher Händler empfängt Bestellungen von europäischen Kunden per EDIFACT, verarbeitet Aufträge aus den USA im X12-Format und sendet Rechnungen an öffentliche Auftraggeber als UBL über das PEPPOL-Netzwerk. Ohne eine zentrale Middleware, die alle drei Formate versteht und ins interne ERP-Format übersetzt, wäre jede dieser Verbindungen ein eigenes Integrationsprojekt. Genau hier liegt der strategische Wert einer durchdachten Integrationsarchitektur: Sie entkoppelt die Geschäftslogik von den Kommunikationsstandards.
Die wichtigsten EDI-Dokumenttypen im E-Commerce
Ein typischer Bestell-Zyklus im E-Commerce umfasst eine Kette von EDI-Dokumenten, die jeweils einem festen Standard folgen. Die EDIFACT-Bezeichnungen sind im europäischen Handel am gebräuchlichsten:
- ORDERS (Bestellung) — Der Ausgangspunkt: Der Käufer sendet eine maschinenlesbare Bestellung mit Artikelnummern (GTIN/EAN), Mengen, Lieferadresse und gewünschtem Liefertermin an den Lieferanten.
- ORDRSP (Bestellbestätigung) — Der Lieferant bestätigt die Bestellung, meldet Teillieferungen oder lehnt einzelne Positionen ab. Dieses Dokument schließt die Abstimmungsphase ab.
- DESADV (Lieferavis) — Vor dem Warenversand informiert der Lieferant über Packstücke, Tracking-Nummern und voraussichtliche Ankunftszeit. Im Multi-Channel-Umfeld ist das DESADV entscheidend für die Bestandsführung.
- RECADV (Wareneingangsbestätigung) — Der Empfänger bestätigt den tatsächlichen Wareneingang, meldet Mengenabweichungen oder Beschädigungen.
- INVOIC (Rechnung) — Die elektronische Rechnung mit allen steuerrelevanten Daten. In Kombination mit der E-Rechnungspflicht gewinnt die automatisierte Rechnungsübertragung weiter an Bedeutung.
- PRICAT (Preisliste/Katalog) — Der Lieferant übermittelt sein Sortiment mit Preisen, Staffeln und Gültigkeitszeiträumen. Ermöglicht automatische Preisaktualisierungen im Shop.
- IFTMIN (Transportauftrag) — Die Anweisung an den Logistikdienstleister mit Abhol- und Zustelldaten, Gewicht und Servicelevel.
Die Global Trade Item Number (GTIN/EAN) ist der zentrale Identifier in EDI-Dokumenten. Ohne saubere GTIN-Pflege im Shop und im ERP-System scheitert die Zuordnung von Bestellpositionen. Prüfen Sie vor einer EDI-Einführung die Datenqualität Ihrer Artikelstammdaten.
Die Abfolge dieser Dokumenttypen bildet einen geschlossenen Kreislauf: Von der Bestellung (ORDERS) über die Bestätigung (ORDRSP), den Versand (DESADV) und den Wareneingang (RECADV) bis zur Rechnung (INVOIC). Jeder Schritt referenziert die vorherigen Dokumente über eindeutige Belegnummern, sodass sich der gesamte Vorgang lückenlos nachvollziehen lässt. Diese Durchgängigkeit ist nicht nur operativ wertvoll, sondern auch für Compliance-Anforderungen und Wirtschaftsprüfungen relevant — insbesondere im Zusammenspiel mit der E-Rechnungspflicht und den Aufbewahrungspflichten nach GoBD.
EDI vs. manuelle Bestellabwicklung: Kosten und Fehler
Der wirtschaftliche Unterschied zwischen manueller und EDI-basierter Bestellabwicklung ist erheblich. Laut GS1 US kostet die manuelle Bearbeitung einer Bestellung — inklusive Erfassung, Prüfung, Freigabe und Archivierung — im Durchschnitt über $30 pro Vorgang. Eine EDI-Transaktion dagegen liegt bei unter einem Dollar (GS1 US). Bei Unternehmen mit mehreren hundert Bestellungen pro Tag summiert sich das auf sechsstellige Einsparungen pro Jahr.
| Kriterium | Manuell | EDI-automatisiert |
|---|---|---|
| Kosten pro Vorgang | $30+ (GS1 US) | < $1 (GS1 US) |
| Bearbeitungszeit | Stunden bis Tage | Sekunden bis Minuten |
| Fehlerquote | 60% Datenanomalien (Commport) | Nahezu null durch Validierung |
| Skalierbarkeit | Linear mit Personal | Unbegrenzt |
| Einsparung Beschaffung | Baseline | Bis zu 40% (GS1 US) |
| ERP-Integration | Manueller Import | Automatischer Datenfluss |
Neben den direkten Kosteneinsparungen reduziert EDI die Bearbeitungszeit laut Cleo um 60 bis 80 Prozent bei vollständiger ERP-Integration (Cleo). Manuelle Fehler wie doppelte Erfassungen, Zahlendreher bei Mengen oder falsche Artikelzuordnungen entfallen, weil die Daten direkt aus dem Quellsystem übernommen werden. GS1 US beziffert die Gesamtersparnis bei Beschaffung, Auftragsbearbeitung und Rechnungsverarbeitung auf bis zu 40 Prozent (GS1 US).
Für Shop-Betreiber mit wachsendem B2B-Anteil ergibt sich daraus ein klarer Business Case: Ab einem Volumen von etwa 50 bis 100 Bestellungen pro Monat amortisiert sich eine EDI-Anbindung in der Regel innerhalb von sechs bis zwölf Monaten — vorausgesetzt, die Middleware ist sauber aufgesetzt und die Stammdatenqualität stimmt.
Hybrid-Integration 2026: EDI kombiniert mit API
Die strikte Trennung zwischen EDI und API löst sich 2026 zunehmend auf. OpenText beschreibt Hybrid-Modelle — die Kombination von EDI für den etablierten Handelspartner-Austausch und REST-APIs für Echtzeit-Daten und neue Integrationsszenarien — als dominierenden Ansatz (OpenText). Der Grund: Klassisches EDI über Value Added Networks (VANs) ist robust und standardisiert, aber nicht für Echtzeit-Szenarien wie Live-Bestandsabfragen oder sofortige Preisaktualisierungen ausgelegt.
EDI für Stabilität
Bewährte Protokolle (AS2, OFTP2) mit End-to-End-Verschlüsselung, Non-Repudiation und Audit-Trail. Unverzichtbar für regulierte Prozesse und Compliance-Anforderungen.
API für Echtzeit
REST/GraphQL-APIs für sofortige Bestandsabfragen, Webhook-basierte Statusupdates und flexible Integrationen mit neuen Partnern — ohne VAN-Setup.
Middleware als Brücke
Eine zentrale Integrationsplattform übersetzt zwischen EDI und API, normalisiert Datenformate und bietet ein einheitliches Monitoring für alle Kanäle.
In der Praxis sieht ein Hybrid-Setup typischerweise so aus: Große Handelspartner (Einzelhandelsketten, Industriekonzerne) kommunizieren weiterhin über EDIFACT/X12 via AS2. Kleinere Partner, Marktplätze und D2C-Kanäle nutzen REST-APIs. Die Middleware normalisiert beide Datenströme in ein einheitliches internes Format und leitet sie an das ERP-System weiter. Digital Commerce 360 bestätigt diesen Trend: B2B-Seller konvergieren E-Commerce und EDI zunehmend zu einem einheitlichen Auftragseingang (Digital Commerce 360).
Ein entscheidender Vorteil des Hybrid-Ansatzes: Die Einstiegshürde sinkt. Unternehmen, die bisher ausschließlich über Web-APIs mit Partnern kommunizieren, können EDI schrittweise einführen — beginnend mit den Handelspartnern, die es explizit verlangen. Gleichzeitig profitieren Unternehmen, die bereits eine etablierte EDI-Infrastruktur betreiben, von der API-Erweiterung für neue Use Cases wie Echtzeit-Bestandssynchronisation oder Event-getriebene Benachrichtigungen. Die Transportprotokolle AS2 (für EDI) und HTTPS (für APIs) können parallel auf derselben Middleware-Instanz laufen.
EDI mit ERP verbinden: SAP, Dynamics und JTL
Die EDI-Anbindung wird erst dann effektiv, wenn die eingehenden Geschäftsdokumente automatisch ins ERP-System fließen — und umgekehrt. Je nach ERP unterscheiden sich die Integrationswege erheblich:
- SAP Business One: SAP bringt mit dem SAP EDI-Adapter eine native Lösung mit, die EDIFACT- und X12-Nachrichten direkt verarbeitet. Für den Mittelstand ist oft eine Middleware wie Lobster oder Seeburger effizienter, die als Konverter zwischen dem EDI-Standard und der SAP-DI-API fungiert. Entscheidend ist das Mapping der EDI-Segmente auf SAP-Belege (Bestellung, Lieferschein, Rechnung).
- Microsoft Dynamics 365: Dynamics bietet über das Electronic Messaging Framework und Power Automate grundlegende EDI-Funktionalität. In der Praxis setzen die meisten Unternehmen auf spezialisierte ISV-Lösungen wie Data Masons oder To-Increase, die innerhalb von Dynamics als Add-on laufen und EDIFACT/X12 nativ verarbeiten.
- JTL-Wawi: JTL setzt auf Export-/Import-Mechanismen über CSV und XML. Die EDI-Anbindung erfolgt typischerweise über eine externe Middleware, die EDI-Nachrichten in das JTL-kompatible Format konvertiert und über die JTL-Ameise oder die REST-API einspielt. Besonders für Händler, die über Marktplätze verkaufen, ist dieser Weg gängig.
Das Mapping — die Zuordnung von EDI-Feldern zu ERP-Feldern — ist der aufwändigste Teil jeder EDI-Integration. Ein EDIFACT-ORDERS-Dokument enthält Hunderte optionaler Segmente. Welche davon das ERP-System benötigt, muss im Implementierungsleitfaden (MIG) mit jedem Handelspartner individuell abgestimmt werden.
Die Integration mit dem E-Commerce-Frontend erfolgt in den meisten Fällen nicht direkt, sondern über das ERP als zentralen Datenhub: Eingehende ORDERS-Nachrichten werden im ERP zu Aufträgen, die dann über die Shop-API den Bestellstatus aktualisieren. Ausgehende INVOIC-Nachrichten werden aus den ERP-Rechnungsbelegen generiert. Dieser Ansatz vermeidet redundante Schnittstellen und nutzt das ERP als Single Source of Truth.
Der Implementierungsaufwand variiert je nach ERP und Partneranzahl. Typische Projektlaufzeiten für eine initiale EDI-Anbindung mit zwei bis drei Handelspartnern liegen bei sechs bis zwölf Wochen. Der Großteil der Zeit entfällt dabei nicht auf die technische Anbindung selbst, sondern auf das Mapping und die Abstimmung der Nachrichtenspezifikationen mit den Partnern. Jeder Handelspartner hat individuelle Anforderungen: Welche optionalen Felder müssen befüllt sein? Welche Qualifikatoren werden für Artikelnummern verwendet (GTIN, Lieferanten-Artikelnummer, Käufer-Artikelnummer)? Werden Mengen in Stück, Kartons oder Paletten angegeben? Diese Details werden im MIG (Message Implementation Guide) festgehalten und sind die Grundlage für das technische Mapping in der Middleware.
KI in EDI-Workflows: Agentic AI und Anomalie-Erkennung
Die nächste Evolutionsstufe des elektronischen Datenaustauschs liegt in der Integration von künstlicher Intelligenz. OpenText beschreibt den Einsatz von Agentic AI in EDI-Workflows: Autonome KI-Agenten überwachen Datenströme, interpretieren Anomalien und optimieren Prozesse in Echtzeit — ohne menschliche Intervention (OpenText).
Konkret lassen sich KI-gestützte Funktionen in drei Bereiche einteilen:
Anomalie-Erkennung
Machine-Learning-Modelle erkennen atypische Muster in EDI-Nachrichten: ungewöhnlich hohe Bestellmengen, abweichende Preise oder verdächtige Lieferadressen. Die Nachricht wird automatisch in eine Prüfqueue geleitet.
Auto-Mapping
KI-gestütztes Mapping analysiert eingehende EDI-Dokumente neuer Handelspartner und schlägt automatisch Feldzuordnungen vor — statt manueller Konfiguration pro Partner.
Predictive Routing
Basierend auf historischen Daten optimiert die KI das Routing: Welcher Lieferant liefert erfahrungsgemäß am schnellsten? Welcher Logistikpartner hat die niedrigste Fehlerquote?
Für B2B-Händler mit hohem Transaktionsvolumen bedeutet das: Die 60 Prozent Datenanomalien (Commport), die ohne EDI auftreten, lassen sich durch KI-gestützte Validierung weiter reduzieren. Gleichzeitig sinkt der Aufwand beim Onboarding neuer Handelspartner, weil das Mapping nicht mehr vollständig manuell erfolgen muss.
Dieser Artikel basiert auf Daten von: Fortune Business Insights (EDI-Softwaremarkt-Prognose), Maximize Market Research (EDI-Marktgröße), GS1 US (Transaktionskosten und Einsparpotenziale), Cleo (Bearbeitungszeiten bei ERP-Integration), Commport (Datenanomalien ohne EDI), OpenText (Hybrid-Modelle und Agentic AI), Digital Commerce 360 (Konvergenz E-Commerce und EDI), Cleo/Coneksion (Standardvergleich EDIFACT vs. X12). Die genannten Zahlen und Prognosen können je nach Branche und Unternehmensgröße variieren.
EDI als Wettbewerbsvorteil im B2B-Handel
Die Zahlen sind eindeutig: Ein EDI-Softwaremarkt, der mit 12,3 Prozent CAGR wächst (Fortune Business Insights), Transaktionskosten, die um den Faktor 30 sinken (GS1 US), und Bearbeitungszeiten, die sich um 60 bis 80 Prozent verkürzen (Cleo) — EDI ist 2026 kein Nischentechnologie mehr, sondern eine Grundvoraussetzung für skalierbaren B2B-E-Commerce.
Der Schlüssel liegt in der richtigen Architektur: Eine Middleware-basierte Integration, die EDI und API als komplementäre Kanäle behandelt, das ERP als zentralen Datenhub nutzt und KI für Anomalie-Erkennung und Auto-Mapping einsetzt. Wer diese Bausteine kombiniert, automatisiert nicht nur den Bestellprozess, sondern schafft die Infrastruktur für weitere Optimierungen — von dynamischen Preisregeln über automatisierte Produktdatenpflege bis hin zur durchgängigen Rechnungsautomatisierung.
Der erste Schritt ist dabei nicht die Technologieauswahl, sondern die Bestandsaufnahme: Welche Handelspartner fordern bereits EDI? Welche Dokumenttypen werden am häufigsten ausgetauscht? Wie sieht die aktuelle Stammdatenqualität im ERP aus? Auf dieser Basis lässt sich ein realistischer Implementierungsplan erstellen, der mit den umsatzstärksten Partnern beginnt und schrittweise weitere Verbindungen aufbaut. Die Investition amortisiert sich in der Regel schnell — nicht nur durch niedrigere Transaktionskosten, sondern auch durch schnellere Auftragsabwicklung, weniger Retouren aufgrund fehlerhafter Lieferungen und eine höhere Handelspartner-Zufriedenheit.
Die Kosten variieren je nach Komplexität erheblich. Typischerweise liegen die initialen Implementierungskosten für eine Middleware-basierte EDI-Anbindung an ein ERP-System im niedrigen bis mittleren fünfstelligen Bereich. Laufende Kosten für VAN-Services, Transaktionsgebühren und Wartung kommen hinzu. Der ROI stellt sich erfahrungsgemäß ab einem Volumen von 50 bis 100 Bestellungen pro Monat innerhalb von sechs bis zwölf Monaten ein, da die Transaktionskosten laut GS1 US von über $30 auf unter $1 pro Vorgang sinken.
Für den europäischen Handel ist UN/EDIFACT in der Regel der passende Standard — er deckt Branchen von Retail über Automotive bis Logistik ab. Wer zusätzlich im öffentlichen Sektor aktiv ist, kommt mit UBL 2.1 und dem PEPPOL-Netzwerk in Berührung. Handelspartner in den USA verlangen typischerweise ANSI X12. Eine moderne Middleware beherrscht in der Regel alle drei Standards und konvertiert zwischen ihnen.
Ja. JTL-Wawi lässt sich über externe Middleware-Lösungen an EDI anbinden. Die Middleware konvertiert eingehende EDI-Nachrichten in das JTL-kompatible Format und übergibt sie über die JTL-Ameise oder die REST-API. Umgekehrt werden ausgehende Dokumente aus JTL-Daten im EDI-Format erzeugt. Der Aufwand ist typischerweise geringer als bei SAP oder Dynamics, weil die Datenstrukturen einfacher sind.
EDI umfasst den gesamten Geschäftsdokumenten-Austausch — von Bestellungen über Lieferavise bis zu Rechnungen. Die E-Rechnungspflicht bezieht sich ausschließlich auf den Rechnungsaustausch in strukturierten Formaten wie XRechnung oder ZUGFeRD. In der Praxis ergänzen sich beide: Wer bereits EDI nutzt, kann die INVOIC-Nachricht als Basis für die E-Rechnung verwenden und so die gesetzlichen Anforderungen ohne zusätzlichen Aufwand erfüllen.
Hybrid-Integration bedeutet, dass EDI-basierte Kommunikation (über AS2, OFTP2 oder VANs) und API-basierte Kommunikation (über REST oder GraphQL) parallel in einer einheitlichen Middleware-Architektur laufen. Große Handelspartner nutzen typischerweise EDI, während kleinere Partner und Marktplätze über APIs angebunden werden. Die Middleware normalisiert beide Datenströme und leitet sie an das ERP weiter. OpenText beschreibt diesen Ansatz als das dominante Integrationsmodell 2026.
KI wird in EDI-Workflows zunehmend für drei Aufgaben eingesetzt: Anomalie-Erkennung (atypische Bestellmuster identifizieren), Auto-Mapping (Feldzuordnungen für neue Handelspartner automatisch vorschlagen) und Predictive Routing (optimale Lieferanten- und Logistikpartner-Auswahl). OpenText beschreibt den Einsatz von Agentic AI — autonomen KI-Agenten, die Datenströme überwachen und Prozesse in Echtzeit optimieren. In der Praxis reduziert das den manuellen Aufwand beim Partner-Onboarding erheblich.