EDI-Anbindung: EDIFACT-Daten an den Shop koppeln 2026

EDI steht für Electronic Data Interchange, den automatisierten Austausch von Geschäftsdokumenten zwischen den IT-Systemen zweier Partner ohne manuelles Zutun. EDIFACT ist der in Europa dominierende Standard dafür: ein von den Vereinten Nationen gepflegtes Regelwerk, das festlegt, wie eine Bestellung, ein Lieferschein oder eine Rechnung als Folge von Segmenten und Datenelementen aussieht. Während in Nordamerika ANSI X12 verbreitet ist, nutzt Europa überwiegend UN/EDIFACT (Wikipedia, EDIFACT). Eine EDIFACT-Nachricht ist nicht für Menschen gemacht: Sie besteht aus Segmenten wie UNB für den Umschlag, BGM für den Belegkopf und NAD für Adressen, jeweils mit Trennzeichen statt Klartext-Feldnamen.

Genau diese Kompaktheit ist Stärke und Hürde zugleich. Sie macht den Austausch schlank und maschinenlesbar, verlangt aber eine Übersetzung in das Datenmodell des Shops. Über 160.000 Unternehmen weltweit setzen heute eine Form von EDI ein und verarbeiten damit mehr als 23 Milliarden Transaktionen jährlich (market.us, EDI Software Market). Für einen Shopware-CE-Shop bedeutet das: Sobald große Handelspartner, Lieferanten oder Handelsketten als Kunden auftreten, führt an EDI selten ein Weg vorbei. Die Anbindung erfolgt dabei nicht im Shop selbst, sondern in einer vorgelagerten Integrationsschicht, die EDIFACT in API-Aufrufe übersetzt und umgekehrt.

Wirtschaftlich ist der Trend eindeutig: Der weltweite EDI-Markt soll von 36,58 Mrd. USD im Jahr 2024 mit einer jährlichen Wachstumsrate von 12,1 Prozent auf 91,22 Mrd. USD bis 2032 zulegen (Fortune Business Insights). Treiber sind cloudbasierte EDI-Lösungen und die zunehmende B2B-Integration. Wer seinen Shop für den Handel mit großen Partnern öffnet, profitiert von dieser Standardisierung, muss die Brücke zwischen EDIFACT und moderner API-Entwicklung aber bewusst und sauber bauen, statt sie als Nebenschauplatz zu behandeln.

Im Bestellprozess zwischen Handelspartner und Shop kommen einige wenige Nachrichtentypen besonders häufig vor. Die EANCOM-Subsets, eine von der Standardisierungsorganisation GS1 gepflegte Ausprägung von EDIFACT, heben ORDERS, DESADV und INVOIC als die drei am häufigsten genutzten Nachrichten hervor (GS1, EANCOM). Sie bilden den Kern des Order-to-Cash-Flusses ab: Bestellung, Lieferankündigung und Rechnung. Ergänzt werden sie um technische Quittungen, die bestätigen, dass eine Nachricht syntaktisch korrekt angekommen ist.

Jeder Partner kann denselben Nachrichtentyp leicht unterschiedlich füllen, weil EDIFACT viele optionale Segmente kennt und Organisationen eigene Subsets definieren. In der Praxis bedeutet das: Eine ORDERS von Partner A ist nicht eins zu eins die ORDERS von Partner B. Genau deshalb braucht jede Anbindung ein eigenes Partner-Profil mit eigenem Mapping. Eine durchdachte Schnittstellen-Konzeption modelliert diese Profile sauber getrennt, sodass eine Anpassung für einen Partner die übrigen nicht berührt.

Das Herzstück jeder EDI-Anbindung ist der Konverter. Er nimmt die rohe EDIFACT-Nachricht entgegen, zerlegt sie in ihre Segmente und Datenelemente und bildet sie auf das Datenmodell des Zielsystems ab. Eine eingehende ORDERS wird so zu einem Auftragsobjekt mit Kunde, Positionen, Mengen und Preisen, das der Shop oder das ERP über seine REST- oder GraphQL-API entgegennimmt. In die Gegenrichtung erzeugt der Konverter aus einem Shop-Objekt wieder eine valide EDIFACT-Nachricht, etwa eine INVOIC aus einer fertigen Rechnung.

Das Beispiel zeigt den prinzipiellen Aufbau: UNB öffnet den Umschlag mit Absender und Empfänger, UNH benennt Nachrichtentyp und Version, BGM trägt die Belegnummer, NAD die Partneradresse und LIN samt QTY eine Bestellposition mit Menge. Der Konverter liest diese Segmente und schreibt ihre Werte in die Felder, die der Shop erwartet. Eine reine Format-Konvertierung genügt dabei nicht: Codes müssen übersetzt, Einheiten geprüft und Artikelnummern auf interne Identifikatoren abgebildet werden. Diese fachliche Logik gehört in die Middleware, nicht in den Shop, damit dessen Kernfunktionen schlank bleiben.

Eine EDIFACT-Nachricht muss sicher von einem System zum anderen gelangen. Drei Transportwege dominieren im B2B-Datenaustausch, und die Wahl hängt von Branche und Partner ab. AS2 ist in der IETF-Spezifikation RFC 4130 definiert und basiert auf HTTP sowie S/MIME (IETF, RFC 4130). Es verpackt EDI-Nachrichten in standardisierte MIME-Strukturen, signiert und verschlüsselt sie und liefert mit der Message Disposition Notification, kurz MDN, eine signierte Empfangsquittung zurück. AS2 hat sich durch die Verbreitung im Handel als De-facto-Standard etabliert (Wikipedia, AS2).

OFTP2 ist die aktuelle Version des Odette File Transfer Protocol und im Automobilsektor verbreitet. Es bietet Datenkompression, Dateiverschlüsselung und den Austausch digitaler Zertifikate zwischen Partnern (Odette, OFTP2). SFTP ist der einfachste Weg: ein verschlüsselter Dateitransfer über SSH, bei dem ein Schlüsselpaar genügt und kein Zertifikatstausch nötig ist. Der Preis dieser Einfachheit ist, dass SFTP auf Protokollebene keine Empfangsquittung kennt; eine fachliche CONTRL- oder Status-Rückmeldung muss dann separat organisiert werden. Welche Variante passt, entscheidet die Middleware-Konzeption pro Partner, oft betreibt eine Anbindung mehrere Wege parallel.

Bevor eine eingehende Nachricht in den Shop wandert, muss die Middleware prüfen, ob sie überhaupt valide ist. Diese Validierung geschieht in mehreren Stufen. Zuerst die Syntax: Entspricht die Nachricht der Struktur des angegebenen Nachrichtentyps und der Version? Dann die Schlüssel: Sind Partner, Artikel und Adressen über das Mapping auflösbar? Schließlich die Fachlogik: Sind Mengen plausibel, Preise vorhanden, Pflichtfelder gefüllt? Eine Nachricht, die hier durchfällt, darf nicht stillschweigend verschwinden, sondern muss eine eindeutige Rückmeldung auslösen.

Genau dafür existiert die CONTRL-Nachricht. Sie quittiert auf Syntaxebene, dass eine Nachricht korrekt empfangen wurde, oder meldet konkret, welches Segment fehlerhaft war. Fachliche Antworten wie eine Auftragsbestätigung ORDRSP gehen darüber hinaus und melden, ob die Bestellung auch inhaltlich angenommen wurde. Sicherheit spielt dabei eine zentrale Rolle: Laut OWASP API Security Project gehören fehlende oder fehlerhafte Authentifizierung und Autorisierung zu den am häufigsten ausgenutzten Schwachstellen in Schnittstellen (OWASP API Security Top 10, 2023). Eine EDI-Anbindung prüft Signatur und Herkunft jeder Nachricht, bevor sie deren Inhalt verarbeitet.

Der wirtschaftliche Nutzen dieser Sorgfalt ist erheblich. Erfahrungsgemäß senkt die Automatisierung manuelle Aufwände in EDI-Prozessen typischerweise deutlich, weil die fehleranfällige Erfassung von Hand entfällt (Projekterfahrung). Genau diese Fehlerquellen adressiert eine saubere Validierung, indem sie fehlerhafte Nachrichten früh abfängt, statt sie in den nachgelagerten Systemen Schaden anrichten zu lassen. Eine ausführliche Behandlung des Umgangs mit Fehlern, Wiederholungen und doppelten Nachrichten zeigt der Schwester-Artikel zur Produktdaten-Pipeline der PIM-Integration.

Der größte Aufwand einer EDI-Anbindung liegt selten im Transport, sondern im Mapping. EDIFACT lässt Organisationen viel Spielraum, welche Segmente sie nutzen und wie sie Codes belegen. Jeder große Handelspartner pflegt daher ein eigenes Implementierungshandbuch, das seine Ausprägung des Standards beschreibt. Eine Anbindung an drei Partner bedeutet in der Regel drei Mappings, die zwar viel gemeinsam haben, sich aber in Details unterscheiden. Wer versucht, alle Partner über ein einziges starres Schema zu bedienen, baut sich eine schwer wartbare Konstruktion.

Der bewährte Ansatz trennt ein gemeinsames internes Datenmodell von partnerindividuellen Profilen. Der Konverter übersetzt jede eingehende Nachricht zuerst in das interne Modell und von dort in das Shop-Objekt, und umgekehrt. Änderungen für einen Partner berühren nur dessen Profil. Diese Architektur zahlt sich aus, sobald Partner hinzukommen oder ihre Handbücher anpassen. In über 50 Integrationsprojekten (Projekterfahrung) hat sich diese saubere Trennung als deutlich wartungsärmer erwiesen als ein monolithisches Mapping. Wie man dieses interne Modell für Stammdaten gestaltet, vertieft der Beitrag zu den Versand- und Logistik-Schnittstellen.

Eine belastbare EDI-Anbindung legt die gesamte Logik in eine Middleware zwischen Handelspartner und Shop, nicht in den Shop selbst. Diese Schicht nimmt die Nachricht über AS2, OFTP2 oder SFTP entgegen, prüft Signatur und Syntax, persistiert jede Nachricht mit einem eindeutigen Schlüssel und verarbeitet sie asynchron in Richtung Shop und ERP. Der Vorteil dieser Entkopplung ist Robustheit: Fällt ein Zielsystem kurz aus, bleibt die Nachricht sicher in der Warteschlange und wird wiederholt, ohne dass der Partner etwas davon merkt. Laut Gartner scheitern Integrationsinitiativen überdurchschnittlich oft an nicht-funktionalen Anforderungen wie Lastverhalten und Fehlertoleranz (Gartner, 2024), nicht an der Fachlogik.

Die Persistenz mit Idempotenz-Schlüssel ist dabei zentral, denn auch im EDI-Austausch kann eine Nachricht mehrfach ankommen, etwa nach einer wiederholten Zustellung. Der Schlüssel, oft die Belegnummer aus dem BGM-Segment, sorgt dafür, dass dieselbe Bestellung nicht zweimal als Auftrag angelegt wird. Diese Entkopplung erlaubt es zudem, schwere Verarbeitung von der schnellen Annahme zu trennen: Die Quittung bestätigt den sicheren Empfang, die eigentliche Auftragsanlage geschieht im Hintergrund. Diese Prinzipien gelten gleichermaßen für eine SAP-Anbindung wie für die Kopplung an ein anderes ERP.

Wirtschaftlich lohnt sich der Aufwand, weil der B2B-Handel weiter wächst. Der deutsche B2B-E-Commerce gehört mit einem Umsatzvolumen im dreistelligen Milliardenbereich zu den wachstumsstärksten Vertriebskanälen (BEVH, 2024), und der Branchenverband BITKOM sieht in der Automatisierung von Geschäftsprozessen einen der wichtigsten Hebel zur Effizienzsteigerung (BITKOM, 2024). Statista weist für den deutschen E-Commerce über die vergangenen Jahre ein anhaltend zweistelliges Wachstum des digitalen Handels aus (Statista, 2024). Eine EDI-Anbindung ist die technische Voraussetzung, um an diesem Wachstum mit großen Partnern teilzunehmen, ohne im manuellen Aufwand zu ersticken. Eine begleitende Integrationsberatung hilft, die Anbindung an Ihre konkreten Partner und Prozesse auszurichten.