# Wie funktioniert die EDI-ERP-Anbindung? Für die EDI-ERP-Anbindung gibt es drei verbreitete Wege: eine Programmierschnittstelle (API), Schnittstellentabellen in einer Datenbank oder den Austausch von Dateien. Welcher passt, entscheidet meist das ERP: Was es anbietet, ist fast immer günstiger als etwas Neues zu bauen. Wichtiger als der technische Weg ist oft die Zuordnung der Stammdaten, also welche Artikelnummer, welcher Kunde und welche Einheit auf beiden Seiten gemeint ist. ## Wo die ERP-Anbindung im EDI-Ablauf sitzt Eine EDI-Lösung hat zwei Seiten. Nach außen spricht sie mit dem Partner, in seinem Format und über seinen Übertragungsweg (siehe [Übertragungswege](https://edi-service.eu/wissen/edi-uebertragungswege/)). Nach innen spricht sie mit Ihrem ERP. Dazwischen liegt das Mapping, das eine EDIFACT-Bestellung in die Struktur übersetzt, die Ihr ERP versteht, und umgekehrt eine Rechnung aus dem ERP in die INVOIC des Partners. Der Partner sieht von der ERP-Seite nichts. Für ihn zählt nur, dass Nachrichten pünktlich und vollständig ankommen. Für Sie entscheidet die ERP-Seite, ob Bestellungen ohne Handarbeit als Aufträge angelegt werden und ob Lieferavis und Rechnung automatisch entstehen. Manche Anbieter rechnen die ERP-Anbindung deshalb getrennt ab; EDI+EXPERTS etwa nennt dafür in der Preisliste ein „individuelles Angebot“. ## Drei Wege für die EDI-ERP-Anbindung ### Per API oder Webhook Viele neuere ERP-Systeme bieten eine Programmierschnittstelle über HTTP, oft als REST-API. Die EDI-Lösung legt einen Auftrag dann direkt per Aufruf an, und das ERP antwortet sofort mit Erfolg oder Fehler. Für die Gegenrichtung kann das ERP einen Webhook auslösen: Es ruft bei einem Ereignis, etwa „Lieferung gebucht“, eine Adresse der EDI-Software auf. Wichtig ist der Umgang mit Wiederholungen. Bricht die Verbindung nach dem Senden ab, weiß die EDI-Lösung nicht, ob der Auftrag angelegt wurde. Die HTTP-Norm (RFC 9110) unterscheidet deshalb idempotente Methoden, deren Wiederholung dieselbe Wirkung hat wie ein einzelner Aufruf. Praktisch heißt das: Jede Bestellung braucht einen eindeutigen Schlüssel, damit ein zweiter Versuch keinen doppelten Auftrag erzeugt. ### Über Schnittstellentabellen (DB-Staging) Viele ERP-Systeme, gerade ältere oder branchenspezifische, haben eigene Importtabellen. Die EDI-Software schreibt eine Bestellung als Datensätze in diese Tabellen, oft Kopf und Positionen getrennt, und setzt ein Status-Feld. Ein Programm im ERP holt die Sätze ab, prüft sie, legt den Auftrag an und schreibt das Ergebnis zurück. Der Vorteil: Das ERP behält die Kontrolle über seine Prüfregeln, und der Status jedes Satzes ist nachvollziehbar. Der Nachteil: Die EDI-Lösung braucht Zugriff auf die Datenbank, und das Abholprogramm im ERP muss laufen. Schreiben Sie nie direkt in die eigentlichen Auftragstabellen des ERP. Damit umgehen Sie dessen Prüfungen, und ein Update des ERP kann die Anbindung unbemerkt brechen. ### Über Dateien Fast jedes ERP kann Dateien einlesen und ausgeben, meist als CSV, XML oder JSON. Die EDI-Software legt eine Datei in einem Ordner ab, auf einem Dateiserver oder per SFTP, und das ERP importiert sie zeitgesteuert. In die Gegenrichtung exportiert das ERP Lieferscheine oder Rechnungen als Datei, die die EDI-Lösung abholt. Dateien sind robust und leicht zu prüfen, weil man sie öffnen und lesen kann. Rückmeldungen kommen dafür verzögert, und Fehler beim Import sieht man oft erst im Protokoll des ERP. Vereinbaren Sie deshalb feste Regeln: eindeutige Dateinamen, Schreiben unter einem temporären Namen und erst danach Umbenennen, getrennte Ordner für Erfolg und Fehler. ### IDoc als Sonderfall In SAP-Umgebungen ist das IDoc (Intermediate Document) verbreitet. SAP beschreibt es als Container für den Datenaustausch zwischen SAP-Systemen und Fremdsystemen, bestehend aus Kopf, Datensegmenten und Statussätzen. Ein IDoc ist damit eher ein Format als ein eigener Weg; übertragen wird es je nach Einrichtung als Datei oder über eine Schnittstelle. ## Die drei Wege im Vergleich | | API oder Webhook | Schnittstellentabellen | Datei | |---|---|---|---| | Rückmeldung | sofort | sobald das ERP den Satz verarbeitet hat | verzögert, oft über Protokoll | | Fehlersuche | über Antwortcodes und Protokolle | Status je Satz in der Tabelle | Datei lesen, Fehlerordner | | Voraussetzung im ERP | dokumentierte API | Importtabellen und Abholprogramm | Import- und Exportfunktion | | Zugriff für die EDI-Software | Netzwerk und Zugangsdaten zur API | Datenbankzugang, möglichst nur auf diese Tabellen | Ordner oder SFTP-Konto | | Doppelte Aufträge vermeiden | eindeutiger Schlüssel je Vorgang | eindeutiger Schlüssel in der Tabelle | eindeutige Dateinamen, Ablage nach Import | | Geeignet für | moderne ERP-Systeme, Cloud-ERP | ERP mit vorhandenen Importtabellen | fast jedes ERP, auch ältere | ## Stammdaten-Mapping ist die eigentliche Arbeit Die meisten Fehler bei der EDI-ERP-Anbindung entstehen nicht in der Technik, sondern bei der Zuordnung von Nummern und Einheiten. - Artikelnummern: Der Partner bestellt mit seiner Materialnummer oder mit der GTIN, Ihr ERP kennt Ihre eigene Artikelnummer. GS1 beschreibt die GTIN als Nummer, mit der ein Unternehmen seine Handelseinheiten eindeutig kennzeichnet. Sie brauchen eine gepflegte Zuordnung, im ERP oder in der EDI-Lösung. - Partner und Lieferorte: Der Partner nennt Käufer, Lieferort und Rechnungsempfänger meist per GLN. Ihr ERP arbeitet mit Kundennummern und Lieferadressen. Jede GLN muss einem Datensatz zugeordnet sein, sonst landet die Ware am falschen Ort. Mehr dazu unter [GLN und andere Kennungen](https://edi-service.eu/wissen/gln-kennungen/). - Einheiten: Der Partner bestellt in Stück, Ihr ERP führt den Artikel im Karton zu zwölf Stück. Ohne Umrechnung stimmen Mengen und Preise nicht. - Preise und Konditionen: Weicht der Preis in der Bestellung vom Preis im ERP ab, muss feststehen, wer gewinnt und wer benachrichtigt wird. ## Fehlerbehandlung und Test Planen Sie für jeden Fehler einen Weg. Eine Bestellung mit unbekannter Artikelnummer darf weder verschwinden noch halb angelegt werden. Sie gehört in eine Fehlerliste mit Originaldatei und Klartextmeldung, damit jemand sie korrigieren und neu einspielen kann. Wer welche Meldung bekommt, sollte vor dem Start feststehen. Testen Sie die Anbindung zuerst gegen einen Testmandanten oder eine Testumgebung des ERP. Spielen Sie dort echte Beispiele aus dem Leitfaden des Partners durch, auch die unangenehmen: Stornos, Teillieferungen, unbekannte Artikel, doppelte Nachrichten. Erst wenn diese Fälle sauber laufen, gehört die Anbindung in den Produktivmandanten. Welche Punkte im Leitfaden dafür wichtig sind, zeigt die [Checkliste zum EDI-Leitfaden](https://edi-service.eu/wissen/edi-leitfaden-checkliste/). ## Was edi-service.eu auf der ERP-Seite anbietet edi-service.eu bindet Ihr ERP über drei allgemeine Adapter an: einen REST- und Webhook-Adapter, Schnittstellentabellen in einer Datenbank und einen Datei-Adapter für CSV, XML oder JSON. Ein fertiger Adapter für ein bestimmtes ERP-Produkt gehört nicht zum Umfang, ebenso wenig Anpassungen im ERP selbst. Die KI richtet die Zuordnung zuerst im TEST-Betrieb ein, in den Produktivbetrieb geht sie erst nach Ihrer Freigabe. Was im Festpreis enthalten ist, steht unter [Preis](https://edi-service.eu/#preis). Wenn Sie klären möchten, ob Ihr ERP einen der drei Wege bietet, können Sie eine [Anfrage stellen](https://edi-service.eu/anfrage/). ## Häufige Fragen ### Welche Schnittstelle braucht mein ERP für EDI? Ihr ERP braucht einen Weg, Aufträge entgegenzunehmen und Lieferungen oder Rechnungen auszugeben: eine API, Importtabellen oder eine Dateischnittstelle. Fast jedes ERP bietet mindestens den Datei-Import. Welche Wege es gibt, steht in der Dokumentation des ERP oder weiß Ihr ERP-Betreuer. ### Muss das ERP selbst EDIFACT verstehen? Nein. Die Übersetzung zwischen EDIFACT oder VDA und dem Format des ERP übernimmt die EDI-Software. Das ERP sieht nur seine eigene Struktur, etwa eine CSV-Datei oder einen API-Aufruf. ### Was ist DB-Staging? DB-Staging heißt, dass Nachrichten über Zwischentabellen in der Datenbank übergeben werden. Die EDI-Lösung schreibt hinein, ein Programm im ERP liest, prüft und verbucht. So bleiben die Prüfregeln des ERP wirksam. ### Wie verhindere ich doppelte Aufträge? Jede Nachricht braucht einen eindeutigen Schlüssel, etwa Partner plus Bestellnummer. Die EDI-Software und das ERP prüfen vor dem Anlegen, ob es diesen Schlüssel bereits gibt. Das schützt auch, wenn ein Partner dieselbe Bestellung zweimal schickt. ## Quellen - IETF: „RFC 9110, HTTP Semantics“, (abgerufen 16.10.2026) - SAP: „IDocs (SAP Library)“, (abgerufen 16.10.2026) - GS1: „Global Trade Item Number (GTIN)“, (abgerufen 16.10.2026) - GS1: „Global Location Number (GLN)“, (abgerufen 16.10.2026) - EDI-Experts Service GmbH: „Preise“, (abgerufen 16.10.2026)