---
title: "Warum ERP und Shop beim Bestand auseinanderlaufen"
description: "Der Sync-Fehler, der jeden Shop irgendwann betrifft: zwei Systeme, die sich beide für die Bestandszahl zuständig sehen, und die Muster, die den Konflikt lösen."
author: "Luboš Zápotočný"
published: "2026-06-11"
language: "de"
canonical: "https://zapolu.com/de/blog/warum-erp-und-shop-beim-bestand-auseinanderlaufen/"
---

# Warum ERP und Shop beim Bestand auseinanderlaufen

Früher oder später erreicht jeden Shop mit ERP-Anbindung dasselbe
Ticket: Die Storefront meldet fünf auf Lager, das Lager meldet
null, und ein Kunde hat gerade einen Artikel bezahlt, der nicht
verfügbar ist. Der Support wertet es als einmaligen Fehler, doch es
geht auf eine Architekturentscheidung zurück, an die sich niemand
mehr erinnert.

## Die eigentliche Ursache: ungeklärte Ownership

Wenn die Zahlen auseinanderlaufen, debuggt jeder das
Synchronisationsskript. Aber das Skript tut meist genau das, was man
ihm gesagt hat; das Problem ist, dass zwei Systeme beide glauben,
die Bestandszahl gehöre ihnen. Das ERP bucht ab, wenn es einen
Auftrag erfasst. Der Shop bucht ab, wenn der Checkout abschließt.
Beide haben nach ihren eigenen Regeln recht, und der Sync-Job
vermittelt zwischen beiden ohne definierte Vorrangregel.

Der Fix ist ein Prinzip: **ein System of Record pro
Fakt.** Die Bestandswahrheit liegt an genau einer Stelle, fast immer
im ERP oder im WMS, denn dort wird der Bestand gebucht und dort
bewegt sich die Ware physisch. Der
Shop hält lediglich eine gecachte Kopie für die Anzeige und eine
*Reservierung*. Ist das einmal explizit, hat jede
Sync-Frage eine Antwort: Im Zweifel gewinnt das System of Record.

## Die Fehlerbilder, die wir immer wieder finden

Ist die Ownership geklärt, sind die verbleibenden Bugs mechanisch,
und sie wiederholen sich quer über Plattformen und ERPs:

- **Verlorene Updates.** Das ERP schickt eine Bestandsänderung, der
  Shop steckt mitten im Deployment oder drosselt den Aufruf, und
  niemand wiederholt ihn. Wochen später fragt jemand, warum eine SKU
  den ganzen Monat „ausverkauft“ war.
- **Doppelte Zustellungen.** Derselbe Webhook feuert zweimal (die
  Zustellung ist typischerweise at-least-once, [dasselbe Event kann
  also mehrfach ankommen](/de/blog/webhooks-kommen-doppelt/)),
  und der Handler bucht den Bestand zweimal ab.
- **Vollabgleiche im Wettlauf mit Deltas.** Ein nächtlicher
  Komplettimport und eventgetriebene Updates laufen gegen dieselben
  Zeilen; wer zuletzt fertig wird, gewinnt, und das ist manchmal
  der veraltete Stand.
- **Mapping-Drift.** Eine im ERP umbenannte SKU wird im Shop still
  zu einem neuen Produkt; das alte behält seinen veralteten Bestand
  für immer.
- **Bundles und Sets.** Der Shop verkauft ein Set; das ERP zählt
  Komponenten. Steht die Umrechnung nur in einer Excel-Tabelle, ist
  sie in der Praxis nie aktuell.

## Die Muster, die den Konflikt beenden

Die Integrationsschicht, die diese Tickets nicht mehr produziert,
sieht unabhängig vom dahinterliegenden ERP gleich aus:

1. **Deltas plus Reconciliation.** Eventgetriebene Updates für die
   Geschwindigkeit, dazu ein periodischer Vollabgleich, der findet,
   was die Events verpasst haben. Die Reconciliation ist das
   Sicherheitsnetz, das den schnellen Pfad erst vertrauenswürdig
   macht.
2. **Idempotente Consumer.** Jedes Update trägt einen Identifier, auf
   dem der Consumer dedupliziert; es zweimal zu verarbeiten ändert
   nichts. Das fängt Retries und
   Replays ab. Concurrency-Konflikte sind ein eigenes Problem:
   Verlorene Updates und Vollabgleiche im Wettlauf mit Deltas
   brauchen Versionsstempel oder Sequenznummern, damit ein
   veralteter Write keinen neueren überschreiben kann.
3. **Correlation-IDs von Ende zu Ende.** Wenn Bestellung 18342 nie
   im Lager ankam, sollte eine einzige Log-Abfrage zeigen, wo sie
   hängen geblieben ist.
4. **Alarm bei Divergenz, nicht nur bei Ausfall.** Ein Sync, der
   grün läuft, während die Zahlen auseinanderdriften, ist schlimmer
   als einer, der abstürzt. Vergleichen Sie Aggregate nach Zeitplan
   und alarmieren Sie jemanden, wenn das Delta wächst.
5. **Reservierungen mit Ablaufdatum.** Wenn Ihr Setup Bestand früh
   reserviert, hält ein Warenkorb ihn für Minuten und eine unbezahlte
   Bestellung länger; standardmäßig entsteht die Reservierung aber
   erst bei der Auftragsanlage, nicht beim Add-to-Cart. So oder so
   fällt alles irgendwann an das System of Record zurück. Overselling während
   Kampagnen geht meist auf Reservierungen zurück, die nie ablaufen
   oder nie existiert haben.

Nichts davon hängt am Hersteller. Wir haben dieselbe Struktur gegen
Business Central und SAP Business One gebaut, gegen NetSuite und
Odoo, und auch gegen tschechische und slowakische Systeme wie Pohoda und
Money S5, die internationale Konnektor-Anbieter gern übersehen;
dieser Long Tail ist der halbe Grund, warum es
[unsere Integrationsarbeit](/de/services/integrations/) gibt.

Wenn Ihr Shop und Ihr ERP diesen Streit gerade führen, beginnen Sie
damit, die Ownership-Frage explizit zu machen. Wenn Sie dabei
Hilfe möchten, [melden Sie sich bei uns](/de/contact/).
Die Ownership-Frage zu klären ist Teil des
[System Designs](/de/services/system-design/); danach ist der
Aufbau der Synchronisation Routinearbeit.