Sobald ein Online-Shop nicht mehr nur Daten aus dem ERP empfängt, sondern selbst zurückschreibt, wird aus einer einfachen Übertragung eine bidirektionale Synchronisation - und damit beginnen die eigentlichen Probleme. Kundenkonten, Bestellungen und Statusänderungen entstehen heute im Shop und müssen zurück ins ERP, während Artikel, Preise und Bestände aus dem ERP in den Shop fließen. Wenn beide Seiten dasselbe Feld verändern dürfen, entstehen Datenkonflikte: ein überschriebener Bestand, ein zurückgesetzter Preis oder eine Endlosschleife aus gegenseitigen Updates. Schlechte Datenqualität kostet Organisationen laut Gartner im Schnitt 12,9 Millionen US-Dollar pro Jahr (Gartner), und nur 3 Prozent der Unternehmensdaten erfüllen grundlegende Qualitätsstandards (Harvard Business Review). Dieser Beitrag zeigt, wie Sie Konflikte in der bidirektionalen ERP-Shop-Synchronisation systematisch auflösen - mit klarer Feld-Hoheit je Datenkategorie statt blindem Last-Write-Wins und mit Mechanismen, die Sync-Loops verhindern. Bewusst ausgeklammert bleiben die verwandten, aber eigenständigen Themen der Stammdaten-Governance im MDM und der Idempotenz- und Retry-Strategien.
Das Wichtigste in Kürze
- Sobald der Shop nicht mehr nur liest, sondern zurückschreibt, ist die Frage nicht mehr, ob ein Konflikt auftritt, sondern wann: überschriebene Bestände, zurückgesetzte Preise oder Endlosschleifen aus gegenseitigen Updates.
- Schlechte Datenqualität kostet Organisationen im Schnitt 12,9 Millionen US-Dollar (Gartner) pro Jahr, und nur 3 Prozent (Harvard Business Review) der Unternehmensdaten erfüllen grundlegende Qualitätsstandards.
- Last-Write-Wins entscheidet allein nach Zeitstempel (coraltree-systems.de): Es setzt synchron laufende Uhren voraus, behandelt alle Felder gleich und verwirft die unterlegene Änderung ohne Protokoll, also unbemerkt.
- Die tragfähige Alternative ist Feld-Hoheit: Je Feld besitzt genau ein System die Wahrheit (loskan.io). Artikel, Preise und Bestände führt das ERP, Kundenkonten und Bestellungen der Shop; die Grenze verläuft auf Feld-, nicht auf Systemebene.
- Gegen Sync-Loops wirken Herkunfts-Kennzeichnung, Echo-Unterdrückung, Korrelations-IDs und ein Änderungsvergleich vor dem Schreiben. Feld-Hoheit, Master-Data-Management und Idempotenz ergänzen sich, lösen aber je ein anderes Problem.
Warum Shops 2026 zurückschreiben und Konflikte entstehen
In den frühen Jahren der Shop-Anbindung war die Richtung eindeutig: Das ERP oder die Warenwirtschaft war die Quelle, der Shop das Schaufenster. Artikel, Preise und Bestände flossen in eine Richtung, der Shop selbst erzeugte kaum eigene Daten. Das hat sich verändert. Moderne Shops sind Konten-, Bestell- und teils Preisplattformen: Kunden registrieren sich, pflegen Lieferadressen, lösen Bestellungen aus, stornieren und hinterlegen Zahlungsarten. Diese Daten müssen zurück ins führende System, damit Auftragsabwicklung, Buchhaltung und Disposition damit arbeiten können. Die Verbindung wird damit zwangsläufig bidirektional.
Der wirtschaftliche Druck dahinter ist real. Der deutsche Online-Handel ist auf 92,3 Milliarden Euro gewachsen (HDE Online-Monitor 2026), der Online-Anteil am Einzelhandelsumsatz liegt bei 13,5 Prozent (HDE Online-Monitor 2026). Gleichzeitig haben 44 Prozent der B2B-Einkäufer schon einmal den Lieferanten wegen einer schlechten digitalen Erfahrung gewechselt (Forrester), und 73 Prozent der jüngeren Entscheider gehören zur Generation, die reibungslose digitale Prozesse erwartet (Forrester). Wer Bestellungen, Konten und Status nicht sauber zwischen Shop und ERP spiegelt, riskiert genau diese Erfahrung. Hier liegt aber auch die Gefahr: Sobald zwei Systeme dasselbe Datenfeld schreiben dürfen, ist die Frage nicht mehr, ob, sondern wann der erste Konflikt auftritt. 61 Prozent (Bitkom, Digitalisierung der Wirtschaft 2025) der Unternehmen können ihr Datenpotenzial nicht voll ausschöpfen, weil Informationen in unverbundenen Systemen liegen.
Artikel und Preise
Entstehen im ERP. Schreibt der Shop hier zurück, überschreibt eine spontane Kampagne schnell den kalkulierten Verkaufspreis.
Bestände
Gehören ins ERP. Reserviert der Shop und meldet gleichzeitig das ERP einen Wareneingang, kollidieren zwei Zahlen auf demselben Feld.
Kundenstammdaten
Entstehen oft im Shop. Ändert die Buchhaltung parallel die Rechnungsadresse, ist unklar, welche Version gelten soll.
Bestellungen und Status
Kommen aus dem Shop, der Status wandert hin und her - eine ideale Brutstätte für Sync-Loops.
Zahlungsdaten
Zahlart im Shop, Zahlungseingang im ERP: Der abgeglichene Status muss aus genau einer Richtung kommen.
Rabatte und Aktionen
Zeitlich begrenzt im Shop gepflegt, dauerhaft im ERP kalkuliert - ohne Hoheitsregel überschreiben sie sich gegenseitig.
Das Problem mit Last-Write-Wins
Die naheliegendste Konfliktlösung ist Last-Write-Wins: Bei einer Kollision gewinnt schlicht der zeitlich jüngste Schreibvorgang, erkennbar am Zeitstempel (coraltree-systems.de). Für unkritische Felder mag das genügen, als generelle Strategie ist es jedoch riskant. Erstens setzt es voraus, dass die Uhren beider Systeme exakt synchron laufen - schon wenige Sekunden Drift lassen ein älteres Update ein neueres überschreiben. Zweitens behandelt Last-Write-Wins alle Felder gleich, obwohl ein manuell gepflegter Verkaufspreis im ERP eine ganz andere Autorität hat als eine automatische Bestandsmeldung aus dem Shop. Drittens verliert man bei jedem Konflikt eine der beiden Änderungen kommentarlos - der Verlust fällt oft erst auf, wenn ein Kunde einen falschen Preis sieht oder ein Artikel doppelt verkauft wurde.
Der stille Datenverlust
Feld-Hoheit je Datenkategorie festlegen
Die tragfähige Alternative ist eine klare Hoheitsregel: Für jede Datenkategorie wird genau ein führendes System bestimmt, das dieses Feld verbindlich besitzt (loskan.io). Alle anderen Systeme dürfen lesen, aber nicht überschreiben. Das ist der Kern des Single-Source-of-Truth-Prinzips, angewendet nicht auf ganze Systeme, sondern auf einzelne Datenfelder. Artikelstammdaten, Preise und Bestände gehören typischerweise ins ERP; Kundenkonten, Warenkörbe und Bestellungen entstehen im Shop und sind dort führend. Entscheidend ist, dass diese Zuordnung explizit dokumentiert und in der Middleware technisch erzwungen wird, statt sie dem Zufall der Reihenfolge zu überlassen. Bei einem Online-Anteil von 13,5 Prozent am Einzelhandelsumsatz (HDE Online-Monitor 2026) und weiter steigenden Rückschreibmengen ist diese saubere Zuordnung kein Luxus, sondern die Grundlage jeder verlässlichen Anbindung.
| Datenkategorie | Führendes System | Sync-Richtung |
|---|---|---|
| Artikelstammdaten | ERP / Warenwirtschaft | ERP → Shop |
| Preise und Staffeln | ERP | ERP → Shop |
| Bestände | ERP | ERP → Shop |
| Kundenkonten | Shop | Shop → ERP |
| Bestellungen | Shop | Shop → ERP |
| Auftragsstatus | ERP | ERP → Shop |
Single Source of Truth pro Feld, nicht pro System
Ein häufiges Missverständnis ist, die Single Source of Truth auf ganze Systeme zu beziehen - "das ERP ist die Wahrheit" oder "der Shop führt die Kunden". In der Praxis verläuft die Hoheitsgrenze feiner, oft mitten durch einen Datensatz. Beim Kundenstamm etwa pflegt der Shop Name, Login und Lieferadresse, während Kreditlimit und Zahlungskonditionen aus dem ERP kommen. Beide schreiben denselben Kundendatensatz, aber unterschiedliche Felder. Die Hoheit wird deshalb auf Feldebene definiert, nicht auf Objektebene. Erst diese Granularität verhindert, dass ein harmloser Adress-Update aus dem Shop die im ERP gepflegte Bonitätsgrenze überschreibt. Dass sich die Investition lohnt, zeigt schon die Größenordnung des Risikos: Schlechte Datenqualität schlägt laut Gartner mit durchschnittlich 12,9 Millionen US-Dollar pro Jahr zu Buche (Gartner).
Hoheit ist eine Feldeigenschaft
Sync-Loops erkennen und durchbrechen
Der zweite große Fehlerfall der bidirektionalen Sync ist die Endlosschleife. Sie entsteht, wenn System A eine Änderung an System B meldet, B daraufhin denselben Datensatz aktualisiert und diese Aktualisierung als vermeintlich neue Änderung an A zurückmeldet - woraufhin A erneut B benachrichtigt. Ohne Gegenmaßnahme kreisen beide Systeme in wachsender Zahl von Updates, belasten die Schnittstelle und produzieren widersprüchliche Zwischenstände. Solche Loops sind bei ereignisgetriebenen Architekturen besonders tückisch, weil jedes Webhook-Event sofort das nächste auslösen kann.
- Herkunfts-Kennzeichnung: Jede Änderung trägt ihre Quelle mit sich. Ein Update, das ursprünglich aus dem Shop kam, wird im Shop nicht erneut verarbeitet.
- Echo-Unterdrückung: Die Middleware merkt sich den zuletzt geschriebenen Wert je Feld und ignoriert das eingehende Echo, wenn es identisch ist.
- Korrelations-ID: Jede Synchronisation erhält eine eindeutige Kennung, die über beide Systeme mitgeführt wird und Rückläufer erkennbar macht.
- Dirty-Flag statt Zeitstempel: Nur fachlich tatsächlich geänderte Felder werden als änderungswürdig markiert, nicht jeder technische Schreibvorgang.
- Änderungsvergleich vor dem Schreiben: Unterscheidet sich der eingehende Wert nicht vom gespeicherten, unterbleibt das Update - und die Schleife bricht.
Konfliktstrategien im Vergleich
Nicht jede Datenkategorie braucht dieselbe Strategie. Für Felder mit eindeutiger Hoheit genügt die Richtungsregel, für seltene Fälle geteilter Zuständigkeit braucht es feinere Verfahren. Die folgende Übersicht ordnet die gängigen Ansätze ein - von der einfachen, aber riskanten Zeitstempel-Regel bis zur feldbasierten Hoheit, die sich auch in Echtzeit-Szenarien bewährt. Angesichts dessen, dass nur 3 Prozent der Unternehmensdaten grundlegende Qualitätsstandards erreichen (Harvard Business Review), ist die bewusste Wahl der Strategie kein Detail, sondern eine Grundsatzentscheidung.
| Strategie | Wie sie entscheidet | Wann sie passt |
|---|---|---|
| Last-Write-Wins (Zeitstempel) | Jüngster Schreibvorgang gewinnt | Nur unkritische Felder mit synchronen Uhren |
| Feld-Hoheit (führendes System) | Der Eigentümer des Feldes gewinnt immer | Standard für Artikel, Preise, Bestände, Kunden |
| Versions- oder Änderungszähler | Höhere Version gewinnt, unabhängig von der Uhr | Verteilte Systeme mit Uhr-Drift |
| Zusammenführung (Merge) | Nicht kollidierende Felder werden kombiniert | Datensätze mit geteilter Feld-Hoheit |
| Manuelle Klärung | Konflikt wird zur Prüfung gemeldet | Seltene, wirtschaftlich kritische Kollisionen |
Klare Abgrenzung: weder MDM noch Retry
Konfliktauflösung wird leicht mit zwei benachbarten Themen verwechselt, die eine eigene Betrachtung verdienen. Das erste ist die Stammdaten-Governance im Sinne eines Master-Data-Managements: Dort geht es um Datenqualität, Freigabeprozesse und die organisatorische Pflege von Stammdaten über den gesamten Lebenszyklus - eine Ebene über der technischen Sync. Wie ein MDM die Stammdaten-Synchronisation organisiert, ist ein Governance-Thema, keine reine Konfliktregel. Das zweite ist die Zustellsicherheit: Idempotenz und Retry-Strategien sorgen dafür, dass eine mehrfach zugestellte Nachricht nicht mehrfach wirkt und ein fehlgeschlagener Aufruf sicher wiederholt wird. Das verhindert Duplikate durch technische Wiederholung, aber nicht den fachlichen Konflikt, wenn zwei Systeme bewusst dasselbe Feld ändern. Feld-Hoheit, MDM und Idempotenz greifen ineinander, lösen aber unterschiedliche Probleme.
Umsetzung Schritt für Schritt
- Datenfluss kartieren: Jede Datenkategorie erfassen und festhalten, in welchem System sie entsteht und wohin sie fließt. Ein sauberes Daten-Mapping zwischen ERP und Shop ist die Grundlage.
- Feld-Hoheit definieren: Pro Feld genau ein führendes System bestimmen und die Sync-Richtung dokumentieren. Uneindeutige Felder werden mit dem Fachbereich geklärt, nicht technisch geraten.
- Hoheit in der Middleware erzwingen: Die Middleware lässt Schreibzugriffe nur aus der jeweils führenden Richtung zu und weist gegenläufige Updates ab oder protokolliert sie.
- Loop-Schutz aktivieren: Herkunfts-Kennzeichnung, Echo-Unterdrückung und Änderungsvergleich einbauen, damit Rückläufer nicht erneut verarbeitet werden.
- Konflikte protokollieren und überwachen: Jede abgewiesene oder aufgelöste Kollision wird geloggt und über ein Monitoring der Schnittstellen sichtbar gemacht.
- Mit Kollisions-Szenarien testen: Gleichzeitige Änderungen an denselben Feldern gezielt provozieren und prüfen, ob die Hoheitsregel korrekt greift, bevor die Anbindung produktiv geht.
Wie belastbar dieser Aufbau sein muss, zeigt sich spätestens, wenn ein führendes System selbst migriert wird. Wer etwa seine Shop-Anbindung wegen des SAP-ECC-Wartungsendes migriert, sollte die Feld-Hoheit dokumentiert haben, bevor die Datenflüsse umgezogen werden. Und sobald der Shop verlässlich zurückschreibt, lassen sich Kundendienste ausbauen, etwa der live aus dem ERP gespeiste Auftragsstatus im B2B-Kundenkonto - ein Nutzen, der ohne saubere Konfliktregel nicht tragfähig wäre. Immerhin haben 44 Prozent der B2B-Einkäufer schon wegen schlechter digitaler Prozesse den Anbieter gewechselt (Forrester); eine konfliktfreie Rückschreibung ist damit auch ein Vertriebsargument.
Bidirektionale Sync scheitert nicht an der Technik der Übertragung, sondern an der fehlenden Antwort auf eine einzige Frage: Wem gehört dieses Feld?