ERP-Schnittstelle planen: Shop, CRM, Lager und Buchhaltung verbinden

Für wen das Thema relevant ist und welches Problem es löst

Eine ERP-Schnittstelle verbindet Ihr Warenwirtschafts- oder ERP-System mit anderen Programmen: Onlineshop, CRM, Lagerverwaltung, Versanddienstleister, Buchhaltung oder Kundenportal. Der Auslöser ist meist banal: Jemand überträgt Daten per Hand, per CSV-Export oder per Copy-and-paste, und das kostet Zeit und erzeugt Fehler.

Typische Einsatzfälle (Beispiele, keine Marktstatistik):

• Shop-Bestellungen sollen automatisch als Aufträge im ERP landen.
• Lagerbestände aus dem ERP sollen im Shop aktuell sein.
• Kundenstammdaten aus dem CRM sollen mit dem ERP übereinstimmen.
• Rechnungen und Zahlungen sollen ohne Neueingabe in die Buchhaltung gelangen.

Wer sich noch fragt, ob eine individuelle Lösung überhaupt nötig ist, findet Entscheidungshilfen im Ratgeber Individualsoftware oder Standardsoftware.

Was vor dem Angebot geklärt sein muss

Die meisten Schnittstellenprojekte werden nicht an der Technik teuer, sondern an offenen Fachfragen. Diese Punkte sollten Sie vor der Angebotsphase beantworten.

Führendes System pro Datenobjekt

Legen Sie für jedes Datenobjekt fest, welches System die „Wahrheit“ hält, und in welche Richtung Änderungen laufen.

Die Tabelle ist ein Denkmodell. Ihre Verteilung kann anders aussehen. Wichtig ist, dass für jede Zeile genau ein System führt. Wenn beide Seiten schreiben dürfen, brauchen Sie eine ausdrückliche Konfliktregel, etwa „der jüngere Zeitstempel gewinnt“, und sollten wissen, welche Folgen sie hat.

Feldzuordnung (Mapping)

Das Mapping beschreibt, welches Feld im Quellsystem welchem Feld im Zielsystem entspricht. Hier verstecken sich die meisten Überraschungen:

• Einheiten: Stück, Karton, Palette, kg; Umrechnungsfaktoren und Rundung.
• Umsatzsteuer: Steuersätze, Steuerschlüssel, Netto-/Brutto-Preisführung, Auslandsfälle.
• Varianten: Ein Shop-Artikel mit Größe und Farbe ist im ERP vielleicht mehrere Artikelnummern.
• Kundennummern: Wie wird ein Gastbesteller im Shop einem Kunden im ERP zugeordnet, und wann entsteht ein neuer Kunde?
• Texte und Zeichensätze: Längenbegrenzungen, Umlaute, Sonderzeichen in Adressen.
• Pflichtfelder: Was verlangt das Zielsystem, was das Quellsystem nicht liefert?

Verlangen Sie das Mapping als Dokument (Tabelle), das Ihre Fachabteilung lesen und freigeben kann, nicht nur als Programmcode.

Synchronisationsmuster

Es gibt zwei grundsätzliche Arten, Änderungen zu übertragen:

• Ereignisgesteuert (Webhook oder Event): Das Quellsystem meldet eine Änderung sofort. Das ist zeitnah, setzt aber voraus, dass das System das anbietet, und verlangt Vorsorge für verpasste Meldungen.
• Abfragend oder im Stapel (Polling, Batch): Die Schnittstelle fragt in festen Abständen nach Änderungen. Das ist einfacher und robust, aber nicht in Echtzeit.

In der Praxis kombiniert man oft beides: Ereignisse für Geschwindigkeit, ein regelmäßiger Abgleichslauf als Sicherheitsnetz.

Zwei Begriffe sollten Sie im Angebot wiederfinden:

• Idempotenz: Wird dieselbe Bestellung zweimal übertragen, entsteht trotzdem nur ein Auftrag. Das gelingt über eine eindeutige Referenz (zum Beispiel die Shop-Bestellnummer), die das Zielsystem speichert und prüft.
• Dublettenvermeidung: Regeln, wann ein Kunde oder Artikel als „schon vorhanden“ gilt.

Fehlerfälle

Jede Schnittstelle fällt irgendwann aus: Das Zielsystem ist in Wartung, ein Pflichtfeld fehlt, eine Artikelnummer existiert nicht. Klären Sie vorab:

• Wiederholung (Retry): Wie oft und in welchen Abständen wird erneut versucht?
• Fehlerwarteschlange (Dead-Letter-Queue): Wohin kommen Datensätze, die nach mehreren Versuchen scheitern, damit sie nicht verloren gehen?
• Benachrichtigung: Wer erfährt von einem Fehler, in welchem Kanal, und wer darf ihn beheben? Eine Fehlermeldung, die nur in einer Logdatei steht, erreicht niemanden.
• Nacharbeit: Kann ein Mitarbeiter einen fehlerhaften Datensatz korrigieren und erneut senden, ohne Entwickler?

Abgleich (Reconciliation)

Auch wenn alles „grün“ ist, können Datensätze fehlen. Ein Abgleich vergleicht die Systeme regelmäßig:

• Anzahl der Bestellungen pro Tag in Shop und ERP,
• Summe der Auftragswerte,
• offene Posten und Zahlungseingänge,
• Lagerbestände stichprobenartig oder vollständig.

Vereinbaren Sie, wer den Abgleichsbericht bekommt und was bei Abweichungen passiert.

Überwachung, Protokollierung und Grenzen der API

• Monitoring: Laufzeiten, Fehlerquoten und Warteschlangenlängen sollten sichtbar sein, nicht nur auf Zuruf.
• Protokolle (Logs): Jeder übertragene Datensatz sollte nachvollziehbar sein: wann, woher, wohin, mit welchem Ergebnis. Achten Sie dabei auf Datenschutz, denn Logs enthalten oft personenbezogene Daten und brauchen eine Löschfrist.
• API-Limits: Viele Schnittstellen begrenzen Aufrufe pro Zeitraum oder Datenmenge pro Abfrage. Ein Dienstleister sollte die Grenzen Ihrer Systeme in der aktuellen Dokumentation prüfen und beschreiben, wie die Lösung bei Überschreitung reagiert (Drosselung, Wiederholung, Teilmengen).

Standard-Konnektor, Individualbau oder Middleware

Entscheidend ist weniger „die beste Technik“ als die Frage: Wer ist in drei Jahren für die Pflege zuständig, und was kostet ein Wechsel? Mehr zur Abwägung steht im Ratgeber zu Individualsoftware und Standardsoftware.

Beispielszenario: Shopware-Bestellungen in ein ERP übertragen

Beispielszenario, frei erfunden und kein realer Fall. Angenommen, ein Großhändler in Mannheim verkauft an gewerbliche Kunden über einen Shopware-Shop. Aufträge werden im ERP erfasst; derzeit tippt ein Mitarbeiter jede Online-Bestellung ab.

Mögliche Festlegungen in der Planung:

• Führende Systeme: Artikel, Preise und Lagerbestand führt das ERP. Die Bestellung entsteht im Shop und wird ins ERP übernommen. Danach führt das ERP den Status.
• Mapping: Shop-Varianten werden auf ERP-Artikelnummern abgebildet, Mengeneinheiten (Karton gegenüber Stück) umgerechnet, Steuerschlüssel pro Lieferland zugeordnet. Bestandskunden werden über die Kundennummer erkannt, Neukunden zur Prüfung in einer Warteschlange angelegt.
• Übertragung: Neue Bestellungen kommen per Ereignis, ein nächtlicher Lauf holt Verpasstes nach. Die Shop-Bestellnummer dient als Idempotenzschlüssel.
• Fehler: Scheitert eine Bestellung, etwa wegen einer unbekannten Artikelnummer, landet sie nach drei Versuchen in der Fehlerliste. Der Vertrieb bekommt eine Mitteilung und korrigiert in einer einfachen Oberfläche.
• Abgleich: Jeden Morgen vergleicht ein Bericht Bestellanzahl und Gesamtwert des Vortags in beiden Systemen.
• Test: Vor dem Start laufen anonymisierte Echtbestellungen der letzten Monate gegen ein Testsystem, darunter Sonderfälle wie Teillieferung, Storno und Auslandskunde.

Die Zahlen und Fristen in diesem Szenario sind Platzhalter für Ihre Entscheidung, keine Empfehlung.

Was Sie als Auftraggeber liefern müssen

• Zugang zu Test- und Produktivsystemen (zunächst nur Test) und zu den Schnittstellendokumentationen der Hersteller,
• einen fachlichen Ansprechpartner, der Mapping-Fragen entscheiden darf,
• anonymisierte Beispieldaten mit den Sonderfällen,
• die Beschreibung der heutigen manuellen Abläufe,
• Klarheit über Verantwortliche beim ERP-Hersteller oder -Betreuer, falls Anpassungen am ERP nötig sind.

Die Ergebnisse dieser Vorarbeit gehören in ein strukturiertes Dokument. Wie das aussieht, zeigt der Ratgeber Lastenheft für Software.

Phasen eines Schnittstellenprojekts

1. Analyse: Prozesse, Datenobjekte, führende Systeme, Schnittstellen der Systeme, Limits.
2. Konzept: Mapping, Synchronisationsmuster, Fehlerkonzept, Abgleich, Testplan.
3. Umsetzung: Entwicklung oder Konfiguration, zunächst gegen das Testsystem.
4. Test mit echten Beispieldaten: inklusive Sonderfälle, Lastspitzen, Ausfälle des Zielsystems.
5. Parallellauf und Start: erst begleitet, dann produktiv; Rückfallweg definieren.
6. Übergabe und Betrieb: Dokumentation, Einweisung, Überwachung, Pflegevertrag.

Was Sie verlangen sollten

• Quellcode oder Konfiguration mit Nutzungsrechten, die zu Ihrem Geschäftsmodell passen,
• Mapping-Dokument, Datenflussdiagramm und Betriebshandbuch,
• Zugangsdaten und Schlüssel auf Ihren Namen, nicht auf den des Dienstleisters,
• automatisierte Tests oder zumindest ein dokumentiertes Testprotokoll,
• Anleitung zur Fehlerbehebung für Ihre Mitarbeiter,
• Abgleichsbericht und Benachrichtigungsregeln.

Kosten- und Zeittreiber

Konkrete Preise lassen sich ohne Kenntnis Ihrer Systeme nicht seriös nennen. Beeinflusst werden Aufwand und Dauer vor allem durch:

• Qualität und Zugänglichkeit der APIs der beteiligten Systeme (manche ERP-Systeme bieten nur Dateiaustausch oder Datenbankzugriff),
• Zahl der Datenobjekte und Richtungen,
• Menge der Sonderfälle im Mapping,
• Anforderungen an Echtzeit und Ausfallsicherheit,
• Testumgebungen: Gibt es ein ERP-Testsystem, oder muss es erst aufgebaut werden?
• Abstimmungsaufwand mit Drittanbietern, etwa dem ERP-Hersteller.

Eine Orientierung zur Struktur von Angeboten gibt der Ratgeber Was kostet Individualsoftware?.

Betrieb und Wartung

Eine Schnittstelle altert auch, wenn niemand sie anfasst. ERP-Updates, neue Shop-Versionen, geänderte Felder oder abgekündigte API-Versionen können sie stören. Das BSI beschreibt im Baustein zum Patch- und Änderungsmanagement, wie Änderungen geplant, getestet und dokumentiert werden sollten; das lässt sich auf Schnittstellen übertragen.

Vereinbaren Sie deshalb:

• wer vor einem ERP- oder Shop-Update informiert wird und die Schnittstelle prüft,
• ob eine Testumgebung für Updates bereitsteht,
• wie schnell der Dienstleister bei Störungen reagiert (Reaktionszeit schriftlich),
• wer API-Änderungen der Hersteller beobachtet,
• wie die Dokumentation aktuell gehalten wird.

Buchhaltungsdaten und GoBD

Wenn Daten an die Buchhaltung gehen, spielen die GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) eine Rolle. Das Bundesfinanzministerium hat sie zuletzt mit Schreiben vom 14. Juli 2025 geändert, vor allem wegen der E-Rechnung. Für Schnittstellen bedeutet das allgemein: Übertragungen sollten nachvollziehbar sein, Daten sollten unverändert und vollständig ankommen, und die Verfahrensdokumentation sollte die Schnittstelle beschreiben. Das ist eine allgemeine Information, keine Rechts- oder Steuerberatung; klären Sie Details mit Ihrer Steuerberatung.

Warnzeichen im Angebot

• Es ist von „Anbindung“ die Rede, aber nicht von Fehlerbehandlung, Abgleich oder Tests.
• Das Angebot nennt keine führenden Systeme und kein Mapping.
• Getestet wird „mit Beispieldaten des Dienstleisters“, nicht mit Ihren.
• Zugänge und Schlüssel liegen beim Dienstleister.
• Keine Dokumentation, keine Übergabe, kein Wort zum Betrieb.
• Pauschalaussagen wie „funktioniert mit jedem ERP“, ohne die Schnittstellen Ihres Systems angesehen zu haben.
• Echtzeit wird versprochen, ohne API-Limits zu nennen.

Nächster Schritt

Wenn Sie ein Konzept beauftragen wollen, halten Sie die Ausgangslage schriftlich fest. Mit dem Werkzeug Projekt vorbereiten erstellen Sie eine kopierbare Projektbeschreibung für Angebotsanfragen. Ist Ihr ERP selbst das Problem, lesen Sie Software modernisieren. Zur Struktur Ihrer Anforderungen hilft der Ratgeber Lastenheft für Software.