Welche Daten müssen zwischen ERP, CRM und Shop fließen?
Ohne Schnittstellen tippen Mitarbeitende Bestellungen aus dem Shop ins ERP, pflegen Kunden doppelt im CRM und gleichen Bestände per Excel ab. Das kostet Zeit und erzeugt Fehler: überverkaufte Artikel, falsche Preise, Rechnungen an alte Adressen. Bevor Sie über Technik sprechen, klären Sie für jedes Datenobjekt, welches System führend ist, wohin die Daten fließen und wie aktuell sie sein müssen.
| Datenobjekt | Führendes System (typisch) | Richtung | Aktualität |
|---|---|---|---|
| Artikel und Stammdaten | ERP oder PIM | zu Shop und Marktplätzen | bei Änderung |
| Preise und Konditionen | ERP | zu Shop und CRM | bei Änderung, oft kundenspezifisch |
| Bestand | ERP oder Lagerverwaltung | zu Shop und Marktplätzen | nahezu in Echtzeit |
| Bestellungen | Shop | zum ERP | sofort |
| Kunden und Ansprechpartner | CRM oder ERP | in beide Richtungen, mit klaren Regeln | bei Änderung |
| Lieferstatus und Sendungsnummer | ERP oder Versandsystem | zu Shop und Kunde | sofort |
| Rechnungen | ERP | zu Kunde, Buchhaltung und Kundenkonto im Shop | sofort oder täglich |
Die Tabelle wirkt banal, verhindert aber den häufigsten Fehler: zwei Systeme, die beide glauben, für Kundenadressen zuständig zu sein, und sich gegenseitig überschreiben.
REST, Webhooks, EDI oder CSV: Welche Technik passt?
Welche Verbindung möglich ist, bestimmen meist die beteiligten Systeme. Die gängigen Wege im Vergleich:
| Verfahren | Geeignet für | Stärken | Schwächen |
|---|---|---|---|
| REST-API (JSON) | moderne ERP-, CRM- und Shopsysteme | verbreitet, gezielte Abfragen, gut dokumentiert | Abfragelimits, Versionswechsel des Anbieters |
| Webhooks | Ereignisse wie neue Bestellung oder Statuswechsel | sofortige Übertragung ohne ständiges Abfragen | Empfänger muss erreichbar sein, Zustellung absichern |
| OData, SOAP, IDoc | ERP-Systeme etwa von SAP oder Microsoft | strukturierter Zugriff auf Geschäftsobjekte | komplexer, teils ältere Technik |
| Dateien (CSV, XML) per SFTP | ältere Systeme, Massendaten, Partner | einfach, unempfindlich, überall verfügbar | zeitverzögert, Formatfehler, keine direkte Rückmeldung |
| EDI (EDIFACT, VDA) | Bestellungen, Lieferavise und Rechnungen mit Handelspartnern und in der Automobilindustrie | etabliert, von großen Partnern gefordert | Konverter oder Dienstleister nötig, Abstimmung je Partner |
| Direkter Datenbankzugriff | nur als Ausnahme | schnell umgesetzt | umgeht die Geschäftslogik, bricht bei Updates |
Bei Webhooks sollte der Empfänger die Signatur jeder Nachricht prüfen, meist ein HMAC mit gemeinsamem Schlüssel, und den Eingang sofort bestätigen. Die eigentliche Verarbeitung folgt danach über eine Warteschlange, sonst wiederholt der Absender bei langsamer Antwort und schickt Dubletten. Bei EDIFACT sind die Nachrichtentypen ORDERS (Bestellung), ORDRSP (Auftragsbestätigung), DESADV (Lieferavis) und INVOIC (Rechnung) am verbreitetsten.
Nicht jede Verbindung muss in Echtzeit laufen. Bestände und Bestellungen sollten möglichst sofort übertragen werden, Artikeltexte oder Bilder reichen oft stündlich oder nächtlich. Weniger Echtzeit heißt weniger Abfragen, weniger Last und eine einfachere Fehlerbehandlung. Legen Sie die nötige Aktualität deshalb je Datenobjekt fest, nicht pauschal für die ganze Schnittstelle.
Punkt-zu-Punkt oder Middleware?
Bei zwei Systemen ist eine direkte Verbindung die einfachste Lösung. Mit jedem weiteren System steigt die Zahl möglicher Verbindungen schnell: Fünf Systeme können bis zu zehn Einzelverbindungen haben, acht Systeme bis zu 28. Jede davon hat eigene Formate, Fehlerfälle und Zuständige. Spätestens ab drei bis vier Systemen lohnt sich eine zentrale Integrationsschicht:
- Eine Middleware oder ein eigener Integrationsdienst übernimmt Umwandlung, Weiterleitung, Wiederholung und Protokollierung an einer Stelle, im eigenen Rechenzentrum oder als gehosteter Dienst.
- iPaaS-Angebote (Integration Platform as a Service) sind gemietete Integrationsplattformen mit fertigen Konnektoren für verbreitete Systeme. Sie sind schnell eingerichtet, kosten dafür laufend und machen Sie vom Anbieter abhängig.
- Viele ERP-Hersteller liefern eigene Konnektoren zu Shops und Marktplätzen. Prüfen Sie vor der Entscheidung, ob diese Ihre Sonderfälle abdecken, etwa Staffelpreise, Sets oder mehrere Lager.
Ob ein fertiges Produkt oder eine eigene Integrationslösung besser passt, ist dieselbe Abwägung wie bei Individual- oder Standardsoftware. Unabhängig vom Werkzeug gilt: Die Integrationslogik gehört dokumentiert an eine Stelle, nicht verteilt auf Skripte auf verschiedenen Servern.
Stammdaten zuerst: ohne saubere Daten keine saubere Schnittstelle
Die meisten Schnittstellenprojekte scheitern nicht an der Technik, sondern an den Daten. Typische Baustellen:
- keine eindeutigen Schlüssel, ein Kunde hat im Shop, im CRM und im ERP verschiedene Nummern,
- Dubletten und veraltete Datensätze,
- unterschiedliche Einheiten, Steuersätze, Zahlungsbedingungen oder Länderkürzel,
- Pflichtfelder, die im einen System leer sein dürfen und im anderen nicht.
Planen Sie vor der Entwicklung eine Bereinigung und eine Zuordnungstabelle (Mapping) für jedes Feld ein. Legen Sie außerdem fest, wer Stammdaten künftig wo pflegen darf: Ändert ein Kunde seine Adresse im Shop, muss klar sein, ob sie ins ERP übernommen oder dort überschrieben wird. Das ist unspektakulär, erspart aber später die meisten Supportfälle.
Fehlerbehandlung und Monitoring: Was passiert, wenn etwas schiefgeht?
Jede Schnittstelle fällt irgendwann aus: Ein System wird gewartet, ein Zertifikat läuft ab, ein Anbieter ändert seine API. Dann dürfen keine Daten verloren gehen, und jemand muss es merken, bevor sich Kunden beschweren. Diese Prinzipien haben sich bewährt:
- Idempotenz: Eine Bestellung, die zweimal ankommt, wird nur einmal angelegt, etwa anhand der Bestellnummer als eindeutigem Schlüssel.
- Warteschlangen und Wiederholung: Fehlgeschlagene Nachrichten werden mit wachsendem Abstand erneut versucht und landen nach mehreren Versuchen in einer Fehlerablage, statt verloren zu gehen.
- Alarmierung: Fehler, Rückstau und ausbleibende Nachrichten lösen eine Meldung an eine zuständige Person aus.
- Abgleich: Ein täglicher Vergleich von Anzahlen und Summen, etwa Bestellungen im Shop gegen Aufträge im ERP, findet stille Fehler.
- Nachvollziehbarkeit: Jede Nachricht bekommt eine Kennung, über die sie in allen Systemen und Protokollen auffindbar ist.
- Sicherheit: Zugangsdaten mit minimalen Rechten, verschlüsselte Übertragung, Schlüssel regelmäßig erneuern.
E-Rechnungspflicht 2027: Was sie für Ihre Schnittstellen bedeutet
Seit dem 1. Januar 2025 müssen Unternehmen in Deutschland E-Rechnungen von inländischen Geschäftspartnern empfangen können, dafür genügt nach Auskunft des Finanzministeriums schon ein E-Mail-Postfach. Ab dem 1. Januar 2027 müssen Unternehmen, deren Gesamtumsatz im Vorjahr über 800.000 Euro lag, bei Umsätzen an andere inländische Unternehmen E-Rechnungen auch ausstellen. Ab dem 1. Januar 2028 gilt das für alle. Ausgenommen sind Kleinunternehmer sowie Kleinbetragsrechnungen bis 250 Euro brutto. Zulässig sind Formate nach der Norm EN 16931, insbesondere XRechnung und ZUGFeRD ab Version 2.0.1 (außer den Profilen MINIMUM und BASIC-WL). Bestehende EDI-Verfahren bleiben möglich, wenn sich die umsatzsteuerlichen Pflichtangaben daraus in ein EN-16931-konformes Format übertragen lassen, andere EDI-Formate nur noch bis Ende 2027. Einzelheiten stehen in den FAQ des Bundesfinanzministeriums.
Für die Integration heißt das: Ausgangsrechnungen müssen strukturiert aus dem ERP entstehen, Eingangsrechnungen automatisch eingelesen, geprüft und dem richtigen Vorgang zugeordnet werden. Bei ZUGFeRD zählt dabei das eingebettete XML, nicht das sichtbare PDF. Weichen beide voneinander ab, gilt der XML-Teil. Für Lieferscheine, Auftragsbestätigungen und andere Belege, die weiter als PDF kommen, kann eine KI-gestützte Dokumentenverarbeitung die Daten auslesen. Dieser Artikel ersetzt keine Rechtsberatung.
So läuft ein Schnittstellenprojekt ab
- Prozesse aufnehmen: Welche Abläufe sollen automatisiert werden, wo entstehen heute Fehler und Doppelarbeit?
- Datenobjekte und führende Systeme festlegen, wie in der ersten Tabelle oben.
- Felder, Zuordnungen, Auslöser, Häufigkeit, Fehlerfälle und Zuständigkeiten in einer Spezifikation festhalten.
- Technik wählen: vorhandene Konnektoren prüfen, sonst API, EDI oder Datei, dazu die Entscheidung zwischen Einzelverbindung und Integrationsschicht.
- Entwickeln und mit Testsystemen und realistischen Daten testen, die Fehlerfälle eingeschlossen.
- Einige Tage bis Wochen parallel betreiben und gegen den bisherigen Ablauf abgleichen.
- Live gehen, mit Überwachung und klarer Zuständigkeit für Fehlermeldungen.
- Im Betrieb API-Änderungen der Anbieter verfolgen, Zertifikate und Zugangsdaten erneuern und Schnittstellen bei jedem Update testen.
Zur Einordnung: Die Einrichtung eines vorhandenen Standardkonnektors zwischen Shop und ERP liegt meist bei etwa 2.000 bis 5.000 Euro, eine individuell entwickelte Schnittstelle bei etwa 5.000 bis 30.000 Euro, eine Integrationsschicht für mehrere Systeme schnell im fünf- bis sechsstelligen Bereich. iPaaS-Dienste kosten je nach Umfang einige hundert bis mehrere tausend Euro im Monat. Richtwerte am Markt, netto, Stand November 2026, kein Angebot.
Wie Unite2Link Systeme verbindet
Unser Team analysiert Ihre Abläufe und Systeme, legt führende Systeme und Datenflüsse fest und entwickelt die Schnittstellen, von der einfachen Shop-Anbindung bis zur Integrationsschicht für mehrere Systeme, inklusive Überwachung und Betrieb. Eine Handelsplattform, die unser Team seit über 15 Jahren betreibt und weiterentwickelt, ist mit zahlreichen Partnersystemen verbunden, etwa für Preise, Versand und Lagerung. Fehlerbehandlung und Abgleich sind dort Alltag. Abgerechnet wird nach Aufwand: Techniker ab 80 Euro, Ingenieur ab 120 Euro pro Stunde, netto. Mehr zu Automatisierung, individueller Software und E-Commerce.