ERP-Schnittstelle anbinden: Vorgehen in fünf Schritten
Wer eine ERP-Schnittstelle anbindet, legt zuerst fest, welche Daten in welche Richtung fließen und welches System je Datenart führt. Danach folgen Feldzuordnung, die Wahl zwischen API, Dateiaustausch und Middleware, Fehlerbehandlung mit Überwachung und ein Test mit echten Daten.
Vor jeder technischen Entscheidung steht bei einer Anbindung eine fachliche Frage: Wer ändert den Preis, wenn Shop und ERP unterschiedliche Zahlen zeigen? Solange das niemand entschieden hat, überschreiben sich zwei Systeme gegenseitig, und am Monatsende stimmen Bestände, Rechnungen oder Kundendaten nicht mehr.
Die fünf Schritte unten gelten für ein ERP wie SAP Business One oder Microsoft Dynamics 365 Business Central ebenso wie für eine Warenwirtschaft wie JTL-Wawi, Xentral, weclapp oder plentymarkets. Im Folgenden steht „ERP“ für beides. Die Schritte gelten auch für die Gegenseite, egal ob dort ein Onlineshop, ein Kundenportal oder eine App für den Außendienst steht; der reine Bestandsabgleich zwischen Shop und Warenwirtschaft ist dabei nur ein Fall von vielen. Am Ende steht eine Schnittstelle, deren Verhalten bei Fehlern vorher feststeht und die ein anderes Team übernehmen kann.
Bestandsaufnahme
Schritt 1: Welche Daten fließen wohin?
Die Bestandsaufnahme beginnt als Liste. Für jede Datenart steht dort, wo sie entsteht, wer sie liest und wer sie ändern darf. Typische Zeilen sind Artikel und Varianten, Preise und Preislisten, Bestände je Lager, Kunden und Lieferadressen, Aufträge, Zahlungen, Lieferscheine mit Sendungsnummern, Rechnungen und Gutschriften.
Für jede Zeile beantworten Fachabteilung und IT gemeinsam vier Fragen:
Wie viele Datensätze gibt es, und wie viele ändern sich am Tag?
Wie schnell muss eine Änderung auf der anderen Seite sichtbar sein?
Was passiert fachlich, wenn sie eine Stunde zu spät ankommt?
Wer bemerkt einen Fehler zuerst, und wie?
Zuständigkeit
Schritt 2: Führendes System festlegen
Für jede Datenart gibt es genau ein führendes System. Nur dort wird der Wert geändert, alle anderen Systeme erhalten eine Kopie. Ändert jemand den Preis im Shop, obwohl das ERP führt, überschreibt der nächste Abgleich die Änderung ohne Warnung. Das ist gewollt, muss aber allen Beteiligten bekannt sein, und die Felder sollten im nachgelagerten System gesperrt sein.
Die Tabelle zeigt ein ausgefülltes Beispiel für einen Onlineshop, der an ein ERP angebunden ist. Die Takte sind Vorschläge, die sich aus den vier Fragen von Schritt 1 ergeben. Für Händler, die Onlineshop und Ladengeschäft aus einem Bestand bedienen, kommt die Kasse als drittes System dazu; worauf es im Onlinehandel und Filialgeschäft technisch ankommt, steht auf der Branchenseite.
Zwei Zeilen wechseln das führende System: Kunden und Aufträge entstehen im Shop und gehen zu einem festen Zeitpunkt an das ERP über, Kunden mit der ersten Bestellung, Aufträge mit dem Zahlungseingang. Das ist eine Übergabe; zu jedem Zeitpunkt führt genau ein System, und der Zeitpunkt des Wechsels steht in der Tabelle.
Kunden sind dabei der häufigste Streitfall. Legt jemand im Shop ein Konto an und ändert später im Kundenservice des ERP die Lieferadresse, gibt es zwei Wahrheiten. Eine klare Regel hilft: Das ERP führt ab der ersten Bestellung, Adressänderungen im Shop erzeugen eine Änderungsanfrage statt eines direkten Überschreibens.
Zur Tabelle gehört eine Feldzuordnung (Mapping) je Datenart: welches Feld im einen System welchem im anderen entspricht und wie Werte übersetzt werden. Typische Stellen sind Artikelnummern mit und ohne Variantenzusatz, Mengeneinheiten (Stück gegen Karton), Steuerschlüssel, Zahlungs- und Versandarten, Länderkennungen und Pflichtfelder, die es nur auf einer Seite gibt. Jede Zeile der Zuordnung nennt auch, was bei einem unbekannten Wert passiert.
| Führendes System | Richtung und Takt | |
|---|---|---|
| Artikel und Varianten | ERP | ERP nach Shop, nach jeder Änderung oder nächtlich |
| Preise und Preislisten | ERP | ERP nach Shop, nach jeder Änderung, Aktionspreise mit Gültigkeitsdatum |
| Bestände je Lager | ERP | ERP nach Shop, alle paar Minuten oder bei Änderung |
| Produkttexte und Bilder | Shop oder Produktdatenbank (PIM) | Shop nach ERP nur, falls Belege sie brauchen |
| Kunden und Adressen | Shop für Neukunden, danach ERP | Shop nach ERP bei Bestellung, Änderungen zurück per Abgleich |
| Aufträge | Shop bis zur Übergabe, danach ERP | Shop nach ERP sofort nach Zahlungseingang |
| Lieferstatus und Sendungsnummer | ERP | ERP nach Shop bei Versand |
| Rechnungen und Gutschriften | ERP oder Buchhaltung | ERP nach Shop als PDF, Buchungsdaten weiter an DATEV |
Technik
Schritt 3: API, Dateiaustausch oder Middleware
Welcher Weg passt, entscheidet zuerst das ERP: Was es anbietet und was Hersteller oder Partner freigegeben haben, begrenzt die Auswahl. Drei Wege kommen infrage.
Programmierschnittstelle (API). Viele Systeme dokumentieren eine Web-API. Microsoft beschreibt für Dynamics 365 Business Central eine REST-Schnittstelle in Version 2.0, die online standardmäßig aktiv ist und bei lokalen Installationen eingeschaltet werden muss. SAP Business One bietet mit dem Service Layer eine Schnittstelle nach dem OData-Standard. JTL dokumentiert auf seinem Entwicklerportal eine ERP-API für JTL-Wawi, die Anwendung wird in der Wawi registriert. Xentral hat die ältere REST-API in den Wartungsmodus versetzt und verweist für neue Funktionen auf die neue Xentral API, weclapp und plentymarkets (seit November 2024 unter dem Namen PlentyONE) dokumentieren ebenfalls REST-Schnittstellen. Bei Systemen wie Sage, proALPHA oder abas hängen Umfang und Lizenz der Schnittstelle von Produktlinie und Version ab; dort lohnt die Frage an Hersteller oder Partner, bevor geplant wird. Ob REST, GraphQL oder Webhooks für Ihre Seite der Verbindung passen, ordnet der Beitrag REST, GraphQL oder Webhooks ein.
Dateiaustausch. Fehlt eine API oder ist sie lizenzpflichtig, bleibt der Austausch von CSV- oder XML-Dateien über ein abgesichertes Verzeichnis. Das ist langsamer, aber robust und leicht nachvollziehbar, weil jede Datei ein Beleg ist. DATEV etwa nutzt das DATEV-Format als Grundlage für seinen Buchungsdatenservice; dieselbe Struktur lässt sich auch als Datei übergeben.
Middleware. Eine eigene Zwischenschicht übersetzt zwischen den Systemen, sammelt Aufträge in einer Warteschlange, wiederholt fehlgeschlagene Übertragungen und protokolliert jeden Schritt. Sie rechnet sich, sobald mehr als zwei Systeme beteiligt sind oder ein System später ausgetauscht werden soll: Dann ändert sich nur ein Adapter. Für kleine Abläufe kann auch ein Automatisierungswerkzeug diese Rolle übernehmen; wo n8n, Make und Zapier an Grenzen stoßen, zeigt der Vergleich der drei Werkzeuge.
Wie wir solche Anbindungen zwischen Shop, Portal und ERP bauen und für die Übernahme durch Ihr Team dokumentieren, beschreibt die Leistungsseite. Eine maschinenlesbare Beschreibung der eigenen Endpunkte nach OpenAPI gehört dazu, damit beide Seiten gegen denselben Vertrag entwickeln.
Betrieb
Schritt 4: Fehler, Wiederholungen und Protokolle
Jede Schnittstelle fällt irgendwann aus: Das ERP wird gewartet, ein Zertifikat läuft ab, ein Artikel hat ein Pflichtfeld nicht gefüllt. Für den Betrieb zählt, was dann passiert, und das legen Sie fest, bevor die erste Zeile Code entsteht.
Wiederholen mit Pause. Eine Retry-Logik versucht es nach wachsenden Abständen erneut, zum Beispiel nach einer, fünf und dreißig Minuten, und stellt den Vorgang danach in eine Liste für Menschen.
Doppelte Übertragung verkraften. Ein Auftrag, der zweimal ankommt, darf nur einmal angelegt werden. Das gelingt über eine eindeutige Kennung je Vorgang, die vor dem Anlegen geprüft wird. Warum das bei Webhooks unverzichtbar ist, erklärt der oben verlinkte Schnittstellen-Beitrag.
Fachliche Fehler trennen. Ein Timeout darf wiederholt werden, ein Auftrag mit unbekannter Artikelnummer nicht. Er gehört sofort zu jemandem, der ihn klären kann.
Protokoll je Vorgang. Wann ging welcher Auftrag mit welcher Kennung hinaus, was antwortete das ERP? Ohne dieses Protokoll beginnt jede Rückfrage aus dem Kundenservice mit Raten.
Überwachung. Drei Werte zeigen, ob die Schnittstelle läuft: die Zeit seit dem letzten erfolgreichen Lauf, die Zahl der Vorgänge in der Fehlerliste und die Zahl der Wiederholungen je Stunde. Überschreitet einer davon eine Grenze, geht ein Alarm an eine benannte Person.
Wie viel der Takt ausmacht, zeigt eine Beispielrechnung mit angenommenen Werten: Ein Shop hat 5.000 Artikel und gleicht die Bestände alle 15 Minuten ab, also 96-mal am Tag. Überträgt jeder Lauf den vollen Bestand, sind das 96 mal 5.000, zusammen 480.000 Artikeldatensätze am Tag. Fragt jeder Lauf nur nach Änderungen seit dem letzten Lauf und ändern sich am Tag 300 Artikel, sind es 96 Abfragen und 300 Datensätze. Der Abgleich nach Änderungen setzt voraus, dass das ERP ein verlässliches Änderungsdatum liefert; das gehört in die Prüfung von Schritt 3. Ein nächtlicher Vollabgleich fängt dann auf, was tagsüber verloren ging.
Abnahme
Schritt 5: Test mit echten Daten und Übergabe
Testdaten mit drei sauberen Artikeln finden die Fehler nicht, die im Betrieb auftreten. Getestet wird deshalb mit einer Kopie der echten Stammdaten in einer Testumgebung des ERP, mit personenbezogenen Daten nur so weit, wie es für den Test nötig ist.
In den Testplan gehören die Sonderfälle, die die Bestandsaufnahme aus Schritt 1 hervorgebracht hat: Varianten mit fehlender Farbe, Artikel mit Bestand null, Umlaute und Sonderzeichen in Adressen, Teillieferungen, Stornos nach Versand, Gutschriften, ein Artikel, der im ERP gelöscht wurde, während er im Warenkorb lag. Danach folgt ein Ausfalltest: ERP für eine Stunde nicht erreichbar, und es wird geprüft, ob alle Aufträge danach genau einmal ankommen.
Zur Übergabe gehören die Tabelle aus Schritt 2, die Beschreibung der Endpunkte, eine Liste der Fehlermeldungen mit der jeweils zuständigen Stelle und ein Ansprechpartner auf beiden Seiten. Wer welches Problem löst, wenn nachts Aufträge hängen bleiben, steht dort mit dem Namen einer Person.
Die Tabelle aus Schritt 2 als Ausgangspunkt
Füllen Sie die Tabelle aus Schritt 2 für Ihre Systeme aus. Mit dieser Liste klären wir, welcher technische Weg zu Ihrem ERP passt und welche Fehlerfälle die Anbindung abdecken muss.
Vor dem Start gefragt
Häufige Fragen
-
Dann bleibt der Austausch über Dateien, zum Beispiel CSV oder XML in einem abgesicherten Verzeichnis, das beide Seiten in festen Abständen lesen und schreiben. Viele ältere oder lokal installierte Systeme können solche Exporte zeitgesteuert erzeugen. Eine Middleware übernimmt dann Umwandlung, Prüfung und Protokoll. Bevor Sie diesen Weg wählen, fragen Sie den Hersteller nach lizenzpflichtigen Schnittstellenmodulen.
-
Meist die Warenwirtschaft oder das ERP, weil dort Einkauf, Lager und Buchhaltung arbeiten und Bestände aus Wareneingang und Versand entstehen. Der Shop zeigt eine Kopie und meldet Verkäufe zurück. Ausnahmen gibt es bei reinen Onlinehändlern, die Preise im Shop-System pflegen; dann muss die Rückrichtung ins ERP genauso sauber geregelt sein.
-
Das richtet sich nach dem Schaden einer Verzögerung, nicht nach der technischen Möglichkeit. Bestände knapper Artikel und Aufträge brauchen Minuten, Artikelstammdaten und Preislisten oft nur einen Lauf pro Nacht oder einen Abgleich nach Änderung. Ein zusätzlicher nächtlicher Vollabgleich findet Abweichungen, die tagsüber durch Ausfälle entstanden sind.
Nachweise
Quellen und Stand
Stand: 04.09.2026. Angaben zu Schnittstellen laut Dokumentation der jeweiligen Hersteller; Umfang und Lizenzbedingungen können je Version abweichen. Die Rechnung zum Abgleichtakt beruht auf angenommenen Werten.
Artikel teilen