Kurz beantwortet: Bei ERP-Schnittstellen unterscheiden Unternehmen vor allem zwischen API (meist REST-basiert) und EDI. Eine API überträgt Daten in Echtzeit über HTTP-Anfragen, meist im JSON-Format, und eignet sich für die Anbindung von Onlineshops, Marktplätzen oder Cloud-Diensten. EDI (Electronic Data Interchange) tauscht Geschäftsdokumente wie Bestellungen, Lieferscheine und Rechnungen dagegen als strukturierte Stapel-Nachrichten aus, meist im EDIFACT- oder EANCOM-Format, und ist in Handel, Automobilindustrie und Logistik seit Jahrzehnten der Standard. Welche Schnittstelle ein Warenwirtschaftssystem tatsächlich braucht, hängt davon ab, mit wem und wie oft Daten ausgetauscht werden.
Was eine ERP-Schnittstelle leisten muss
Ein Warenwirtschaftssystem steht selten allein: Es muss Bestellungen aus dem Onlineshop übernehmen, Rechnungen an die Finanzbuchhaltung weiterreichen, Bestände mit Marktplätzen abgleichen und oft auch mit Lieferanten oder Großhändlern kommunizieren. Jede dieser Verbindungen ist technisch eine eigene Schnittstelle mit eigenen Anforderungen an Format, Frequenz und Absicherung. In der Praxis kristallisieren sich dabei zwei grundsätzliche Architekturen heraus: der programmatische Echtzeit-Zugriff über eine API und der dokumentenbasierte Stapelaustausch über EDI.
API und REST: Echtzeit-Datenaustausch über HTTP
Eine API (Application Programming Interface) ermöglicht es zwei Systemen, direkt und in Echtzeit miteinander zu kommunizieren. Im ERP-Umfeld hat sich dafür der REST-Standard durchgesetzt: Anfragen laufen über HTTP, die Antworten kommen meist im JSON-Format. Das System, das eine Information braucht – etwa den aktuellen Lagerbestand für die Anzeige im Onlineshop –, fragt sie gezielt ab und erhält die Antwort sofort, statt auf die nächste geplante Datenübertragung zu warten. Diese Echtzeitfähigkeit macht REST-APIs zum bevorzugten Standard für E-Commerce- und Cloud-Anbindungen, während dokumentenbasierte EDI-Verfahren in klassischen B2B-Lieferketten dominieren.
EDI: der etablierte Standard für Bestellungen und Rechnungen
EDI ist deutlich älter als die heutige API-Welt und in bestimmten Branchen bis heute Pflicht für die Zusammenarbeit mit größeren Handelspartnern. Kern ist der strukturierte Austausch kompletter Geschäftsdokumente – etwa einer Bestellung, einer Lieferavis oder einer Rechnung – in einem festgelegten Nachrichtenformat, meist EDIFACT oder dem darauf aufbauenden Handelsstandard EANCOM von GS1. Anders als eine API arbeitet EDI klassischerweise asynchron im Batch-Betrieb: Nachrichten werden gesammelt und zu festen Zeitpunkten übertragen, nicht bei jeder einzelnen Anfrage einzeln abgerufen.
Wie verbindlich dieser Standard gepflegt wird, zeigt sich an seiner Governance: Die für UN/EDIFACT zuständige Organisation UN/CEFACT genehmigt jedes Jahr zwei neue Standardversionen, gekennzeichnet mit Jahreszahl und dem Zusatz „A“ oder „B“ für die erste beziehungsweise zweite Freigabe des Jahres. EDIFACT und seine Subsets gelten als die weltweit am weitesten verbreiteten EDI-Datenformate, wobei EANCOM speziell in der Konsumgüterindustrie als etablierter Nachrichtenstandard von GS1 gilt; in Nordamerika hat sich parallel dazu ANSI X12 durchgesetzt. GS1 Germany nennt als typische EDI-Branchen unter anderem Handel und Konsumgüter (FMCG), Baumarktsortiment, Logistik, Fashion sowie das Gesundheitswesen; in der Automobilindustrie ist mit VDA ein eigener EDI-Standard etabliert.
Wie konkret das im Tagesgeschäft aussieht, zeigt sich etwa bei der Anbindung an Amazon Vendor: Dort werden Bestellungen (PO), Bestellbestätigungen (POA), Lieferavise (ASN) und Rechnungen (INV) als eigene EDI-Dokumenttypen ausgetauscht – jeder mit einem festen Format und Ablauf, den ein Warenwirtschaftssystem entweder direkt oder über einen EDI-Dienstleister abbilden muss.
Webhooks als Ergänzung zur klassischen API
Neben der klassischen REST-API, bei der ein System aktiv nach Daten fragt, nutzen viele moderne Warenwirtschaftssysteme zusätzlich Webhooks: Statt dass der Onlineshop wiederholt abfragt, ob sich ein Bestellstatus geändert hat, meldet das ERP-System die Änderung von sich aus an eine hinterlegte Adresse. In der Praxis werden REST-API und Webhooks meist kombiniert – die API für gezielte Abfragen und Schreibvorgänge, Webhooks für Ereignisse, auf die andere Systeme sofort reagieren sollen, etwa eine Stornierung oder eine Zahlungsbestätigung.
Worauf bei der Einführung einer neuen Schnittstelle zu achten ist
Unabhängig davon, ob eine API- oder eine EDI-Anbindung ansteht, wiederholen sich in der Praxis ähnliche Fragen: Welche Datenfelder werden tatsächlich benötigt, und in welchem Format erwartet die Gegenseite sie? Wie wird mit Fehlern umgegangen, wenn eine Übertragung fehlschlägt – gibt es eine automatische Fehlerbenachrichtigung oder muss das manuell geprüft werden? Und wie wird die Verbindung abgesichert, etwa durch Authentifizierung, verschlüsselte Übertragung und eine klare Rechtevergabe für die einzelnen Endpunkte? Gerade bei EDI-Anbindungen an größere Handelspartner geben diese häufig ein festes technisches Pflichtenheft vor, an das sich das eigene Warenwirtschaftssystem oder ein zwischengeschalteter EDI-Dienstleister halten muss.
API vs. EDI im Vergleich
| Kriterium | API / REST | EDI |
|---|---|---|
| Datenformat | meist JSON, teils XML | EDIFACT, EANCOM, ANSI X12, VDA |
| Übertragung | Echtzeit, Anfrage-Antwort | asynchron, meist im Batch |
| Typischer Einsatz | Onlineshop, Marktplatz, Cloud-Dienste | Bestellungen/Rechnungen mit Handelspartnern, Automobilzulieferung, Logistik |
| Verbreitung | Standard bei modernen Cloud-ERP-Systemen | seit Jahrzehnten Standard im klassischen B2B-Handel |
| Setup-Aufwand | keine Angabe (stark anbieterabhängig) | keine Angabe (stark anbieter- und partnerabhängig) |
Wann lohnt sich welche Schnittstelle für ein Warenwirtschaftssystem?
Für ein Unternehmen, das primär über einen eigenen Onlineshop oder wenige Marktplätze verkauft, reicht in der Regel eine API-Schnittstelle zum Shopsystem aus – sie ist schneller einzurichten und liefert Bestände und Bestellstatus in Echtzeit. Sobald jedoch größere Handelsketten, Baumärkte oder Automobilhersteller als Abnehmer auftreten, verlangen diese häufig eine EDI-Anbindung als Voraussetzung für die Zusammenarbeit – unabhängig davon, wie das eigene ERP-System sonst aufgebaut ist. Viele moderne Warenwirtschaftssysteme im Anbieter-Verzeichnis, etwa JTL-Wawi, Xentral oder Odoo, bieten beide Wege parallel an: eine offene REST-API für Cloud- und Shop-Anbindungen sowie EDI-Module oder Partnerschaften mit EDI-Dienstleistern für den klassischen B2B-Datenaustausch. Auch die Anbindung an die Finanzbuchhaltung läuft technisch oft über eine vergleichbare Logik, wie der Artikel zur DATEV-Schnittstelle zeigt. Einen strukturierten Überblick über weitere Schnittstellentypen und Integrationsfragen bietet die Kategorie Schnittstellen & Integration.
Häufige Fragen zu ERP-Schnittstellen
Was ist der Hauptunterschied zwischen API und EDI?
Eine API überträgt Daten in Echtzeit über eine gezielte Anfrage, meist im JSON-Format. EDI tauscht dagegen vollständige Geschäftsdokumente wie Bestellungen oder Rechnungen in einem festen Nachrichtenformat aus, klassischerweise asynchron im Batch-Betrieb.
Brauchen auch kleine Unternehmen eine EDI-Anbindung?
Nicht zwingend. Solange ein Unternehmen vor allem über den eigenen Onlineshop oder kleinere Marktplätze verkauft, reicht meist eine API-Schnittstelle. EDI wird relevant, sobald größere Handelspartner, Handelsketten oder Automobilzulieferketten eine standardisierte Anbindung voraussetzen.
Kann ein Warenwirtschaftssystem sowohl API als auch EDI nutzen?
Ja. Viele Systeme kombinieren eine offene REST-API für Echtzeit-Anbindungen mit separaten EDI-Modulen oder der Anbindung an spezialisierte EDI-Dienstleister für den dokumentenbasierten Austausch mit Handelspartnern.
