Die Anforderung kommt vom Geschäftspartner: Ab dem nächsten Quartal werden Rechnungen nur noch per EDI akzeptiert. EDIFACT oder X12, je nach Branche und Region. Das klingt nach Enterprise-IT, nach SAP-Projekten und Middleware-Plattformen. In der Realität sitzt auf der eigenen Seite manchmal ein ERP-System, das eine Access-Datenbank als Backend hat, und dessen letzte Erweiterung vor acht Jahren von einem Mitarbeiter gebaut wurde, der inzwischen in Rente ist.

Was EDI wirklich bedeutet

EDI – Electronic Data Interchange – ist zunächst kein technisches Format, sondern ein Konzept: zwei Systeme tauschen strukturierte Geschäftsdokumente aus, ohne menschliche Zwischenschritte. Die technische Umsetzung variiert stark: EDIFACT ist in Europa weit verbreitet, X12 dominiert in Nordamerika, und daneben gibt es proprietäre Formate, die ein einzelner Handelskette-Konzern irgendwann festgelegt hat und seitdem von seinen Lieferanten verlangt.

EDI ist kein Protokoll, das man implementiert. Es ist ein Kommunikationsprozess, den man mit dem Geschäftspartner abstimmt. Der technische Teil ist der einfachere.

Das eigentliche Problem: die Datenseite

Bevor Mapping, Transformation und Übertragung ein Thema sind, stellt sich die grundlegendere Frage: Wo sind die Daten, die in das EDI-Dokument fließen sollen, und in welcher Qualität liegen sie vor?

  • Sind Artikel mit EAN oder GTIN gepflegt?
  • Gibt es eindeutige Lieferanten- und Kundennummern im Format des Partners?
  • Sind Rechnungspositionen maschinenlesbar, oder werden sie aus einem Freitextfeld zusammengesetzt?
  • Gibt es eine verlässliche Schnittstelle zur Access-Datenbank, oder läuft alles über exportierte Excel-Dateien?

Die Antworten auf diese Fragen bestimmen, wie aufwändig die Integration wirklich wird.

Pragmatische Umsetzung: Middleware statt direkter Integration

In den meisten Fällen mit Legacy-ERP-Systemen ist eine direkte Integration nicht der richtige Weg. Stattdessen empfiehlt sich eine leichtgewichtige Middleware – ein kleines Programm oder Service, das aus dem Quellsystem (z.B. per SQL auf die Access-Datenbank oder per CSV-Export) Daten liest, sie in das EDI-Format transformiert, und per SFTP oder AS2 an den Partner überträgt.

Die Übertragungsinfrastruktur – also SFTP-Server, AS2-Zertifikate, Quittierungsprotokolle – sollte nicht selbst gebaut werden. Es gibt spezialisierte EDI-Dienstleister, die diese Infrastruktur betreiben und zwischen den Formaten der Partner übersetzen. Das ist keine Schwäche, sondern der pragmatische Weg für Unternehmen ohne eigene EDI-Kompetenz im Haus.

Fazit

EDI-Integration ist selten so kompliziert wie sie klingt – und selten so einfach wie der Anbieter es verspricht. Der schwierigste Teil ist oft nicht die Technik, sondern die Koordination: Was genau erwartet der Partner, in welchem Format, mit welchen Pflichtfeldern, und bis wann? Wer diese Fragen früh klärt, spart sich Überraschungen kurz vor dem Go-live.