Lagerbestand im Shop-ERP synchronisieren: So verhinderst du Overselling und Minusbestände im e-Commerce dauerhaft

Wenn es trotz ERP-Schnittstelle nicht gelingt, den Shop-Lagerbestand zuverlässig zu synchronisieren 

Kaufinteressierte, die eine Absage bekommen, kaufen woanders. Im Wiederholungsfall kommen sie gar nicht mehr zurück, während dein Team Stunden damit verbringt, Bestände manuell abzugleichen, Bestellende zu vertrösten und Fehler zu korrigieren.

Wie ernst der Kundenverlust durch schlechte Liefererlebnisse ist, zeigen aktuelle Zahlen: Laut dem Metapack Ecommerce Delivery Benchmark Report 2025 für Großbritannien wechseln 60,1 % der Konsument:innen zu einer anderen Marke, sobald diese bequemere Lieferoptionen anbietet. Und 56,4 % kaufen woanders, wenn ein Händler sie einmal enttäuscht – beispielsweise mit einer nicht lieferbaren Bestellung. Dass vergangene Liefererlebnisse die Kaufentscheidung maßgeblich beeinflussen, betont auch eine 2024 veröffentlichte Studie von Sendcloud: 77 % der Befragten geben an, dass frühere Liefererfahrungen darüber entscheiden, ob sie bei einem Händler erneut kaufen.

Bei einer Bestellung, die du wegen falscher Bestandsdaten nicht liefern kannst, verlierst du Umsatz, Kundschaft und Zeit, was bereits schlecht genug ist. Die Konsequenzen können aber noch schlimmer ausfallen: Amazon wertet Stornierungen als Qualitätssignal und bestraft sie mit schlechteren Rankings oder sogar Kontosperrungen.

Das Grundproblem ist fast immer dasselbe: Shop und ERP reden nicht schnell genug miteinander. Oder sie reden zwar miteinander, aber auf Basis der falschen Bestandszahl.

Auf die richtige Konfiguration kommt es an 

Du weißt, worauf es beim Bestandsabgleich ankommt, dein Shop ist mit deinem ERP verbunden – trotzdem hast du Overselling in deinem e-Commerce nicht verhindern können? Dann ist dieser Ratgeber für dich. Von der Konfiguration des verkaufbaren Bestands über Synchronisationsintervalle bis zu kanalspezifischen Puffern und Retourenlogik: Wir beleuchten praktisch anwendbar, wie du deinen Lagerbestand im Shop-ERP zuverlässig synchronisierst.

Warum Overselling entsteht und das bloße Vorhandensein einer Schnittstelle nicht reicht 

Es ist ein Trugschluss zu glauben, man würde sämtliche Probleme mit Overselling und Minusbestand vermeiden, sobald die eigenen Shops und das ERP technisch verbunden sind. Die Schnittstelle läuft, der Bestand wird übertragen, was soll da noch schiefgehen?

Ziemlich viel. Denn die entscheidende Frage ist nicht, ob Bestandsdaten übertragen werden, sondern welcher Bestandswert übertragen wird und wie schnell das passiert.

Im ERP gibt es drei verschiedene Bestandsgrößen, die du auseinanderhalten musst:

• Physischer Bestand: Was tatsächlich im Lager liegt – gezählt, eingebucht, vorhanden.
• Reservierter Bestand: Ware, die bereits für offene Aufträge reserviert ist, aber noch nicht versendet wurde.
• Verkaufbarer Bestand: Was du tatsächlich noch verkaufen kannst.

Bildest du diese Unterscheidung nicht in deiner ERP-Konfiguration ab und überträgst stattdessen den physischen Rohbestand an den Shop, hast du einen systematischen Fehler im Setup. Bei nicht synchronisierten Lagerbeständen in deinen Shops handelt es sich also um keinen menschlichen Fehler, sondern einen ERP-Konfigurationsfehler. Und der lässt sich beheben.

Schritt 1: Verkaufbaren Bestand richtig definieren 

Hier liegt der häufigste Fehler. Nicht bei der Schnittstelle selbst, sondern bei der Frage, welche Zahl überhaupt übertragen wird.

Was Reservierungen sind und warum sie zählen 

Stell dir vor, du hast 10 Einheiten eines Artikels im Lager. Gleichzeitig liegen 8 offene Aufträge vor, die noch nicht versendet wurden. Die Ware ist also bereits für Kunden reserviert, liegt aber noch physisch bei dir. Dein Shop zeigt trotzdem 10 Einheiten als verfügbar an. Ein neuer Kunde bestellt 3 Einheiten. Du kannst nicht liefern. Hier macht sich die falsch konfigurierte Bestandslogik bemerkbar.

Reservierungen entstehen immer dann, wenn ein Auftrag im ERP angelegt wird, aber die Ware noch nicht das Lager verlassen hat. Dieser reservierte Bestand muss vom physischen Bestand abgezogen werden, bevor der Wert an deinen Shop oder Marktplatz übertragen wird.

Die ERP-Konfiguration, um den Lagerbestand bei mehreren Marktplätzen synchron zu halten 

In Xentral legst du fest, welcher Bestandswert als Basis für die Kanal-Übertragung gilt. Die richtige Einstellung ist der verkaufbare Bestand, also physischer Bestand abzüglich aller offenen Reservierungen und abzüglich deines definierten Sicherheitspuffers.

Das ist die Konfigurationsentscheidung, die bereits die häufigste Ursache für Overselling verhindert. Sind deine Bestandsdaten auf diese Weise organisiert, hast du die Grundlage für Synchronisation, Puffer und Retourenlogik gelegt.

Schritt 2: Der richtige Synchronisationsmodus – Lagerbestand in Echtzeit synchronisieren 

Selbst wenn der richtige Bestandswert übertragen wird, kann Overselling eintreten – nämlich wenn die Übertragung zu langsam ist.

Intervallbasierte vs. ereignisbasierte Synchronisation 

Die entscheidende Frage ist, wann dein Bestand in den jeweiligen Kanal übertragen wird. Du kannst mit intervallbasierter und ereignisbasierter Synchronisation arbeiten:

Intervallbasierte Synchronisation ist im Multichannel-Vertrieb ein häufiger Grund für Overselling. Zwischen festgelegten Synchronisationsintervallen liegen im Zweifel genau die Sekunden, in denen ein zweiter Kanal dieselbe Einheit verkauft. Je mehr Kanäle gleichzeitig aktiv sind, desto kritischer wird jede Minute Verzögerung.

Warum 15-Minuten-Intervalle zu lang sind 

Stell dir vor, du verkaufst denselben Artikel gleichzeitig auf Amazon und in deinem Shopify-Shop. Du hast noch 2 Einheiten auf Lager. Um 14:03 Uhr kauft ein Kunde auf Amazon die letzten 2 Einheiten. Dein System synchronisiert intervallbasiert alle 15 Minuten – der nächste Abgleich ist um 14:15 Uhr. Um 14:07 Uhr kauft ein zweiter Kunde im Shopify-Shop dieselben 2 Einheiten. Der Shop zeigt noch Verfügbarkeit, weil der Bestand noch nicht aktualisiert wurde.

So tritt Overselling als Resultat des falschen Synchronisationsmodus ein. Gerade wenn du mehrere Shops betreibst, bedeutet eine intervallbasierte Synchronisation auf lange Sicht „setting yourself up for failure“.

Ereignisbasierte Synchronisation als Goldstandard 

Bei ereignisbasierter Synchronisation löst jede Lagerbewegung – jeder Auftragseingang, jede Reservierung, jede Versandbuchung – sofort eine Bestandsaktualisierung in allen angebundenen Kanälen aus. Es gibt dadurch kein Zeitfenster, in dem Bestände auseinanderlaufen können.

Xentral Connect ist die technische Grundlage dafür. Xentral Connect überträgt Bestandsänderungen ereignisgesteuert an alle darüber angebundenen Shops und Marktplätze – darunter Shopify, Shopware 6 und OTTO, ohne dass dafür ein separates Middleware-Tool nötig ist.

Schritt 3: Überverkauf im ERP verhindern – kanalspezifische Bestandspuffer konfigurieren 

Ereignisbasierte Synchronisation löst das Timing-Problem. Aber es gibt noch eine zweite Fehlerquelle: Alle Kanäle sehen denselben Bestand.

Das klingt zunächst logisch, denn du hast ja nun mal einen Bestand, und der wird synchronisiert. Das Problem ist, dass dein eigener Shop und insbesondere Amazon sehr unterschiedliche Risikoprofile haben.

Warum Amazon einen höheren Puffer braucht 

Gemäß den Richtlinien der Amazon Seller Central wirken sich Stornierungen durch den verkaufenden Shop (z. B. wegen Nichtverfügbarkeit) negativ auf die Stornorate und damit auf die Verkäuferleistung aus, da Amazon erwartet, dass der Lagerbestand aktuell gehalten wird. Anhaltend schlechte Leistungskennzahlen können zu Maßnahmen gegen das Verkäuferkonto bis hin zur Deaktivierung führen. Die Stornierungsquote ist ein zentrales Qualitätssignal für den Algorithmus. Wer auf Amazon eine Bestellung annimmt, die er wegen Nullbestand nicht erfüllen kann, muss stornieren; und jede händlerbedingte Stornierung verschlechtert die Verkäuferleistung direkt. Amazon schaut nicht, ob der Artikel in deinem eigenen Shop noch verfügbar wäre. Für den Algorithmus zählt nur: Bestellung eingegangen, aber nicht geliefert.

Hinzu kommt, dass Retourenquoten auf Amazon strukturell höher sind als im eigenen Shop. Ware, die zurückkommt, ist für eine gewisse Zeit nicht wieder verkaufbar. Das musst du einkalkulieren, um keine Engpässe zu riskieren.

Sicherheitspuffer pro Kanal konfigurieren 

Amazon überwacht Händler:innen anhand harter KPIs: Die Stornierungsrate vor Erfüllung darf maximal 2,5 % betragen, die Bestellmängelrate (Order Defect Rate) maximal 1 %. Werden diese Schwellenwerte überschritten, droht die Kontosperrung ohne vorherige Verwarnung. Du musst dann innerhalb von 17 Tagen einen überzeugenden Plan of Action vorlegen, ansonsten verlierst du dauerhaft deinen Zugang zum Marktplatz.

Kaufland beispielsweise sanktioniert ebenfalls, aber anders: Wer dort eine händlerbedingte Stornierungsrate von 3 % überschreitet, zahlt zunächst eine Strafgebühr von 10 % auf die betroffenen Transaktionen. Eine Kontosperrung erfolgt erst bei wiederholten Verstößen.

In Xentral lässt sich für jeden angebundenen Kanal ein eigener Sicherheitspuffer konfigurieren – technisch über die Pseudolagerzahlen-Funktion und Lagerkorrekturwerte. Das bedeutet: Amazon sieht einen niedrigeren Bestand als tatsächlich vorhanden ist. Das ist dein Puffer gegen die oben beschriebenen Risiken.

Als Orientierung kannst du mit folgenden Sicherheitspuffern arbeiten. Die realistischen Werte hängen aber letztendlich von der Anzahl deiner Produkte und deiner Retourenquote ab:

Flash-Sale-Szenario: Puffer temporär erhöhen 

Vor einem Aktionszeitraum, also etwa Black Friday, einem Marktplatz-Deal, einer eigenen Rabattaktion und dergleichen, solltest du die Puffer manuell erhöhen, bevor der Traffic ansteigt. Denn wenn du wartest, bis der erste Overselling-Fall eintritt, hast du bereits das Problem.

Wie hoch dein Sicherheitspuffer sein sollte, hängt auch von der für dich optimalen Menge an Bestellungen ab. Unser Rechner für die optimale Bestellmenge hilft dir dabei, deine richtige Basis zu ermitteln. Was passiert, wenn du trotz Puffer in einen Nullbestand läufst, erklärt unser Artikel zur Vermeidung von Out-of-Stock-Situationen.

Nach dem Sale setzt du den Wert wieder auf deinen Standardpuffer zurück. Trag dir den Reset-Termin direkt im Kalender ein, denn erhöhte Puffer, die nach einem Black-Friday-Weekend vergessen werden, kosten dich in den Folgewochen unnötig Reichweite.

Schritt 4: Minusbestand im ERP vermeiden, Retouren korrekt zurückbuchen 

Minusbestände entstehen selten durch fehlerhafte Synchronisation, sondern fast immer nach Retouren – nämlich, wenn die Retourenlogik im ERP falsch konfiguriert ist.

Warum der Zeitpunkt der Rückbuchung entscheidend ist 

Eine Retoure durchläuft mehrere Stationen: Kund:innen kündigen sie an, schicken die Ware zurück, die Ware geht im Lager ein, wird geprüft und dann eingebucht. Das Problem entsteht, wenn der Bestand zu früh oder zu spät korrigiert wird.

• Zu frühe Bestandskorrektur: Die Retoure wird im Shop als abgeschlossen markiert, sobald Kund:innen sie anmelden – der Bestand steigt sofort. Die Ware ist aber noch unterwegs. Wenn sie eingeht und beschädigt ist, hast du einen Bestand, der nicht existiert.
• Zu späte Bestandskorrektur: Die Ware liegt im Lager, ist aber noch nicht eingebucht. Der Bestand bleibt negativ, obwohl die Einheit physisch vorhanden ist.

Die richtige Konfiguration, um Minusbestand nach einer Retoure zu verhindern 

Der Bestand darf erst dann steigen, wenn die Retoure physisch im Lager eingegangen und geprüft wurde. Nicht bei Ankündigung, nicht bei Versand des Rücksendeetiketts, sondern erst nach dem tatsächlichen Eingang und der positiven Prüfung einer wiederverkaufsfähigen Ware.

Xentral steuert diesen Zeitpunkt über die Retourenlogik: Der Wareneingang der Retoure triggert die Bestandskorrektur. Erst wenn er die Qualitätsprüfung bestanden hat, führt das ERP den Artikel wieder als verkaufbar.

Schritt 5: Fehler und Sync-Probleme im Journal erkennen 

Du hast die Konfiguration sauber aufgesetzt und trotzdem stimmt der Bestand nicht überein. Klingt blöd, aber: Das passiert. Es gibt viele Fehlerquellen, die sich nicht vollständig ausschließen lassen. Entscheidend ist, dass du sie schnell erkennst.

Typische Fehlerquellen 

• Verbindungsabbrüche: Die Übertragung wird ausgelöst, kommt aber nicht an.
• API-Timeouts: Der Marktplatz antwortet zu langsam, die Übertragung bricht ab. Das tritt häufiger in Lastspitzen auf.
• Falsch konfiguriertes Kanal-Mapping: Ein Artikel ist im ERP unter einer anderen SKU geführt als auf dem Marktplatz. Der Bestand wird übertragen, landet aber beim falschen Artikel.

Das Übertragungsjournal in Xentral Connect 

Xentral Connect protokolliert jede Bestandsübertragung. Fehlgeschlagene Übertragungen sind im Journal sofort mit Zeitstempel, betroffener SKU und Fehlerursache sichtbar. Du musst nicht warten, bis Kund:innen Fehler melden. Du siehst das Problem, bevor es zum Overselling führt.

Manuelle Neusynchronisation 

Wenn du einen Fehler im Journal erkennst und den Bestand sofort korrigieren musst, kannst du in Xentral Connect eine manuelle Neusynchronisation für einzelne Artikel oder Kanäle anstoßen. Das ist das Eskalationsszenario (nicht der Normalfall, aber wichtig zu kennen).

Checkliste: Ist deine Bestandssynchronisation korrekt konfiguriert? 

Bevor du deinen nächsten Kanal anbindest oder dein Volumen erhöhst, geh diese Liste durch:

☐ Der verkaufbare Bestand (NICHT der physische Rohbestand) wird an alle Kanäle übertragen.

☐ Reservierungen offener, noch nicht versendeter Aufträge werden vom Bestand abgezogen.

☐ Ereignisbasierte Synchronisation ist aktiviert, KEIN reiner Intervallmodus bei mehreren Kanälen.

☐ Sicherheitspuffer sind pro Kanal individuell konfiguriert, NICHT kanalübergreifend einheitlich.

☐ Der Amazon-Bestandspuffer ist höher als der für den eigenen Shop.

☐ Die Retourenlogik ist so eingestellt, dass der Bestand erst bei physischem Wareneingang und bestandener Qualitätsprüfung steigt.

☐ Das Übertragungsjournal in Xentral Connect wird regelmäßig auf fehlgeschlagene Übertragungen geprüft.

☐ Flash-Sale-Puffer werden VOR Aktionszeiträumen manuell erhöht.

☐ Alle Kanäle sind in Xentral Connect aktiv und korrekt gemappt (SKU-Zuordnung geprüft).

☐ Kanal-Mappings werden nach JEDER Sortimentserweiterung auf Vollständigkeit geprüft.

Fazit: Einmal richtig konfigurieren – dauerhaft den Lagerbestand deiner Shops im ERP synchronisieren 

Overselling ist das Ergebnis einer Konfiguration, die nicht für mehrere Kanäle und wachsendes Volumen ausgelegt ist.

Wenn du die fünf Schritte in diesem Ratgeber einmal sauber umsetzt – verkaufbaren Bestand definieren, ereignisbasierte Synchronisation aktivieren, kanalspezifische Puffer setzen, Retourenlogik korrekt konfigurieren und das Journal im Blick behalten – hast du ein Setup, das mit dem Unternehmen mitwächst. Ohne permanente manuelle Korrekturen, ohne Kundenbeschwerden wegen nicht lieferbarer Ware, ohne Amazon-Abstrafungen.

Wenn du wissen möchtest, wie Xentral die Lagerverwaltung konkret abbildet, findest du auf der Produktseite alle Details. Und falls du nicht sicher bist, ob dein aktuelles Setup das leisten kann, zeigt dir eine Bedarfsanalyse in wenigen Minuten, wo dein Betrieb steht.