TL;DR. B2B EDI Integration verbindet deinen Shop direkt mit den ERPs deiner Großkunden. Eine saubere B2B EDI Integration spart pro Bestellung Stunden Handarbeit und reduziert Fehler in Auftragsdaten dramatisch. Wir zeigen, welche Standards bei B2B EDI Integration relevant sind, was die Anbindung an Shopware oder commercetools wirklich kostet und wo typische Stolperfallen liegen.
Dein Großkunde ist SAP-Anwender. Seine Bestellung kommt nicht über den Shop. Sie kommt über EDI, elektronischer Datenaustausch. Das ist Business-Kommunikation auf Maschinenlevel. Keine Mails, keine Uploads, keine Handeingaben. Einfach System zu System.
EDI ist ein spezialisiertes Thema. Es braucht gründliche Analyse, technisches Know-how und vor allem sorgfältige Planung. Wir klären im Erstgespräch gerne ob und wie EDI für dich relevant ist. Hier zeigen wir dir wie EDI funktioniert und wo die Fallstricke liegen.
Inhalt
- Was ist EDI und warum brauchst du das?
- EDIFACT, X.12, API: Welcher Standard ist richtig?
- Wie funktioniert EDI technisch?
- Kosten für EDI Integration
- Welche Fehler treten am häufigsten auf?
- Wie lang dauert eine EDI Implementierung?
Was ist EDI und warum brauchst du das?
EDI steht für Electronic Data Interchange. Vereinfacht: Zwei Systeme tauschen Daten aus, ohne dass ein Mensch dazwischen sitzt.
Klassisches Szenario: Dein Kunde arbeitet mit SAP. Jedes Mal wenn er was bei dir bestellen will, landet das in seinem SAP. Ohne EDI müsste jemand die Bestellung in sein SAP-System tippen, als Excel runterladen, dir mailen oder sie manuell im Shop eingeben. Das ist fehleranfällig und kostet Zeit.
Mit EDI schickt sein SAP automatisch eine strukturierte Datei an dein System. Dein System verarbeitet die Bestellung, aktualisiert Verfügbarkeiten, sendet Bestätigungen zurück. Alles automatisch, 24/7, kein manueller Eingriff nötig.
Das Plus: Weniger Fehler. Weniger Support. Echtzeit-Abwicklung. Das Minus: Technisch komplex, braucht Planung, kostet Geld.
EDI ist Phase 5+ des B2B-Spektrums (Plattform aufwärts): Systeme kommunizieren untereinander, ohne manuellen Input. Als Teil einer durchdachten B2B Commerce Strategie zahlt sich die Investition schnell aus. Das ist nicht das erste B2B-Projekt, sondern kommt, wenn du den Shop stabil am Laufen hast und Großkunden bereit sind dafür zu investieren.
Typische Einsatzbereiche sind größere Produktmengen, regelmäßige Bestellungen (wiederkehrende Orders) und Kunden die international arbeiten und verschiedene Standards nutzen.
EDIFACT, X.12, API: Welcher Standard ist richtig?
Das ist eine der Fragen die am häufigsten kommt: "Welchen Standard brauchst du denn?" Die Antwort ist fast immer: "Den den dein Kunde vorgibt."
EDIFACT
EDIFACT ist der europäische Standard. UN/EDIFACT mit den aktuellen Versionen D96A, D00B und D01B. Das ist das, was dein deutsches Unternehmen sieht wenn es mit europäischen Großkunden spricht.
Ein EDIFACT-Nachricht ist textbasiert und sieht so aus:
UNA:*+.? '
UNB+IATB:1+6XPPC+LHPPC+060101:2359+1'
UNH+00000000000001+ORDERS:D:96A:UN:EAN008'
BGM+220+1001'
DTM+137:20060101:102'
Für menschliche Augen unlesbar. Für Systeme perfekt strukturiert. Jedes Feld hat eine Bedeutung (Auftragsnummer, Lieferdatum, Kundenreferenz, etc.). Das wird von deinem EDI-Gateway geparst und dein System kann damit arbeiten.
EDIFACT ist stabil, etabliert und wird von fast allen Großunternehmen in Europa verwendet. Wenn dein Kunde ein großes deutsches Industrieunternehmen ist, wird es EDIFACT sein.
X.12 (ASC X.12)
Das ist der nordamerikanische Standard. Wenn dein Kunde in den USA ansässig ist, wird wahrscheinlich X.12 verlangt. Es funktioniert ähnlich wie EDIFACT, hat aber etwas andere Syntax und Feldstruktur.
In Europa ist X.12 selten relevant, es sei denn dein Kunde ist multinational und will den gleichen Standard weltweit.
API-basierter Datenaustausch
Viele modernere Unternehmen setzen inzwischen auf APIs statt EDI. Ein API-Endpoint den dein Kunde aufrufen kann um Bestellungen zu platzieren. Das ist einfacher zu handhaben als EDIFACT, braucht aber eine Dokumentation des API.
Das Plus: Einfacher zu debuggen. Das Minus: Der Kunde muss Entwickler haben die das implementieren. Nicht alle Kunden haben das.
Unsere Erfahrung: EDIFACT ist immer noch die Nummer 1. Bei neuen Projekten sehen wir langsam API-Lösungen entstehen. Aber wenn ein Großkunde EDI will, ist es zu 95% EDIFACT.
Wie funktioniert EDI technisch?
Hier ist der typische Ablauf. EDI ist ein kritischer Teil einer modernen B2B Shop-Architektur und gehört zu den wichtigsten B2B-Integrationen, die dein E-Commerce-System braucht.
Schritt 1: Nachricht-Erstellung beim Kunden
Der Kunde sitzt in SAP, erstellt eine Bestellung. SAP generiert automatisch eine EDIFACT-Nachricht (ORDER Nachricht mit Positions-Details, Lieferadresse, Rechnungsadresse, Bezahlung, etc.).
Schritt 2: Übertragung
Die Nachricht wird über einen EDI-Transport zu dir übermittelt. Es gibt mehrere Möglichkeiten:
- SFTP: Datei wird auf einen SFTP-Server hochgeladen den du mit dem Kunden gemeinsam nutzt
- AS2: Asynchronous Secure Exchange, ein Protokoll speziell für EDI, sicherer als FTP
- API: Der Kunde ruft einen Endpoint auf
- E-Mail mit Attachment: Alte Schule, aber noch verbreitet
Alle Varianten haben Vor- und Nachteile. SFTP ist simpel. AS2 ist sicherer. API ist modern. E-Mail ist ein Sicherheitsrisiko, sollte die letzte Option sein.
Schritt 3: Parsing beim Empfänger
Die Datei kommt bei dir an. Dein EDI-Gateway (oder dein Custom-Code) parst die EDIFACT-Nachricht. Das heißt: Die Maschinen-Syntax wird gelesen und in verständliche Daten umgewandelt.
Ein EDI-Gateway ist spezialisierte Software die genau das macht. Es gibt kommerzielle Lösungen (z.B. TrustCommerce, Oxfam EDI, Seeburger) und Open-Source Lösungen (z.B. Bonita).
Schritt 4: Verarbeitung in deinem System
Dein Shop oder dein ERP wird gegenüber der geparsten Information abgeglichen:
- Kennen wir den Kunden?
- Stimmen die Produktnummern (deine Nummern vs. seine Artikelnummern)?
- Sind die Mengen verfügbar?
- Sind die Preise korrekt?
Falls Fehler auftreten (Artikel nicht gefunden, Kundengruppe nicht erkannt), muss das eskaliert werden. Normalerweise an den Support.
Schritt 5: Bestätigung zurück
Dein System sendet eine EDIFACT ORDERS-Response zurück (Auftragsbestätigung, Lieferdatum, korrigierte Preise falls nötig, etc.). Das kommt wieder per SFTP/AS2/API beim Kunden an und landet in SAP.
Der Kunde sieht dann die Bestätigung mit genauem Lieferdatum und Gesamtpreis.
Schritt 6: Laufende Synchronisation
Nach der Bestellung folgen weitere Nachrichten:
- DESADV (Lieferschein): Wenn der Auftrag gepackt wird
- INVOIC (Rechnung): Die Rechnung
- Tracking-Daten: Paktverfolgungsnummer
Alles über die gleiche Kommunikationsstrecke.
Kosten für EDI Integration
EDI ist nicht günstig. Hier sind realistische Orientierungswerte (zum aktuellen Zeitpunkt).
EDI-Gateway Software
Kommerzielle Lösungen (wie TrustCommerce, Seeburger) bringen Support, Update-Management und vorgebaute Integrationen. Das hat seinen Preis. Open-Source-Alternativen (wie Bonita) sind günstiger, brauchen aber dein eigenes Team zur Überwachung. Wir empfehlen das richtige Modell anhand deiner internen Kapazitäten zu wählen, nicht anhand des Einstiegspreises.
Implementierung pro Kunde
- Einfache EDI (EDIFACT ORDER + Bestätigung): ab 8.000+ EUR
- Standard (ORDER, DESADV, INVOIC): ab 15.000+ EUR
- Enterprise (Multi-Standort, Compliance, Custom-Workflows): ab 30.000+ EUR
Das umfasst: Analyse der Kundenanforderungen, Mapping der Felder (seine Artikelnummern zu deinen), Tests mit echten Daten des Kunden, Dokumentation.
Laufende Betreuung pro Kundenverbindung
- Monitoring und Support: ab 500+ EUR pro Jahr
- Änderungen bei Kundenanforderungen: nach Aufwand, ab 2.000+ EUR pro Änderung
Faustregel: Mit einem Großkunden EDI aufzubauen kostet dich mindestens 20.000+ EUR. Das ist nicht klein. Aber wenn der Kunde große Mengen abwickelt, rechnet sich das schnell durch Fehlerreduktion und Support-Ersparnis.
In unseren Projekten sehen wir dass sich EDI innerhalb von 6 bis 12 Monaten amortisiert wenn der Kunde regelmäßig bestellt. Für viele B2B Unternehmen gehört EDI zur modernen E-Commerce-Agentur Leistung und zum Standard bei der Betreuung von Großkunden.
Welche Fehler treten am häufigsten auf?
Fehler 1: Falsches Feld-Mapping
Der Kunde sendet seine interne Artikelnummer "2024-ROT-L-10", dein System kennt die aber nicht. Du brauchst ein Mapping-Dokument das sagt: "Seine 2024-ROT-L-10 ist deine SKU #4711".
Wenn das Mapping falsch ist, landen Bestellungen mit falschen Produkten bei dir an. Das ist teuer im Support und zerstört Kundenzufriedenheit.
Lösung: Gründliche Analyse der Kundenartikel VOR dem Live-Rollout. Und ein Test mit 50 echten Bestellungen des Kunden bevor es produktiv geht.
Fehler 2: Dezimalzahlen und Formatierung
Deutsche Systeme nutzen Komma (1.234,56), englische Punkt (1,234.56). EDIFACT hat strikte Standards. Wenn die Preise falsch formatiert sind, können Systeme die nicht verarbeiten.
Lösung: Das ist ein technisches Detail das der EDI-Gateway normalerweise handelt. Aber testet es. Mit echten Zahlen.
Fehler 3: Timing und Häufigkeit
Der Kunde sendet eine Bestellung alle 5 Minuten. Dein System kann das nicht verarbeiten. Oder der Kunde sendet nur nachts um 3 Uhr und dein Support-Team sieht Fehler erst am nächsten Morgen.
Lösung: Definiere vorab welche Sendungshäufigkeit realistisch ist und wie Alerts funktionieren wenn was schiefgeht.
Fehler 4: Kein Rollback-Plan
EDI ist live, der erste Fehler tritt auf. Was jetzt? Zurück zu manuellen E-Mails? Bestellungen abweisen?
Lösung: Hab einen Fallback-Plan. Was passiert wenn EDI ausfällt. Die meisten arbeiten mit: "Bei kritischen Fehler fallen wir auf E-Mail-Bestellungen zurück, das Ops-Team wird informiert."
Fehler 5: Unzureichende Dokumentation
Wer überwacht das EDI-System? Wer behält die Fehler? Was sind SLAs (Service Level Agreements)? Wenn das nicht dokumentiert ist, gibt es später Missverständnisse.
Lösung: Schriftliche Dokumentation mit Verantwortlichkeiten, Eskalationswegen und SLAs.
Wie lang dauert eine EDI Implementierung?
Realistischer Zeitplan für einen Kunden:
Woche 1-2: Analyse & Anforderungen
- Kick-off mit dem Kunden
- Sammlung der EDI-Profile (welche Nachrichten, welche Häufigkeit)
- Sammlung von Testdaten
- Entscheidung EDI-Gateway (extern oder eigenes System)
Woche 3-6: Design & Setup
- Detailliertes Mapping-Dokument
- Gateway-Konfiguration
- Test-Umgebung aufsetzen
- API/Schnittstellen-Spezifikation
Woche 7-10: Entwicklung & Tests
- Parser und Verarbeitung implementieren
- Fehlerbehandlung
- Unit-Tests
- Integration-Tests mit echten Testdateien des Kunden
Woche 11-14: Abnahme-Tests (UAT)
- Der Kunde sendet echte Testbestellungen
- Ihr verarbeitet die und sendet Bestätigungen zurück
- Fehler werden dokumentiert und behoben
- Mehrere Iterationen wenn nötig
Woche 15: Go-Live
- Der Kunde geht live mit echter Produktivumgebung
- Intensive Überwachung erste Woche
- Support-Team im Hotline-Modus
Total: 3 bis 4 Monate für einen Kunden. Das kann schneller gehen wenn der Kunde einfach strukturiert ist, wird länger wenn es mehrere Kundenstandorte oder komplexe Business-Logik gibt.
Viele Unternehmen mit mehreren EDI-Kunden bauen sich eine "Vorlage" nach dem ersten Projekt. Der zweite und dritte Kunde gehen dann in 4-6 Wochen statt 3 Monate live.