EU-Batterierichtlinie in deutschen Amazon-Lagern: Änderungen bei der FC-Annahme
22 Juli 2026
Kitting und Montage in Deutschland und Polen: Wie Lohnverpackung Bestellungen beschleunigt
22 Juli 2026
FLEX. Logistics
Wir bieten Logistikdienstleistungen für Online-Händler in Europa an: Amazon FBA-Vorbereitung, Bearbeitung von FBA-Rücksendeaufträgen, Weiterleitung zu Fulfillment-Centern – sowohl FBA- als auch Vendor-Versendungen.
Ein Xentral-Nutzer in Köln verkauft über Amazon.de, einen Shopware-Shop und einen Großhandels-B2B-Kanal. Die Bestandszahlen sind live in Xentral verfügbar, doch der Lagerboden aktualisiert eine Tabelle, und Amazon-Listings werden zweimal täglich manuell aktualisiert. An einem hektischen Dienstag geht eine Bestellung für die letzten vier Einheiten eines Bestsellers ein – genau in dem Moment, in dem eine Retoure eingelagert und eine Palette für den Versand kommissioniert wird. Niemand bemerkt es, bis Amazon eine negative verfügbare Menge anzeigt und die Auftragswarteschlange dahinter stockt. Genau das passiert, wenn die Xentral-ERP-Integration als optional und nicht als zentrales Rückgrat betrachtet wird, das Bestand, Auftragsstatus und Marktplatzsichtbarkeit verbindet. Die Lösung ist kein besseres Tabellenverhalten. Es ist ein direkter Datenfeed zwischen Xentral, dem Lager und Amazon, der den Bestand aktualisiert, Aufträge weiterleitet und Tracking-Daten automatisch zurückspielt. So kann der Leser entscheiden, ob eine manuelle Synchronisation bei seinem aktuellen Auftragsvolumen noch tragfähig ist oder bereits mehr kostet, als sie einspart.
Was eine Xentral-to-3PL-Verbindung tatsächlich verbindet
Eine funktionierende Integration besteht aus drei Datenflüssen, die im Kreis laufen – nicht aus einer einzigen generischen Verbindung. Erstens: Bestandssynchronisation – das Warehouse-Management-System meldet reale Bestandsmengen in kurzen Intervallen zurück an Xentral, sodass Amazon, Shopware und alle Marktplatz-Connectoren dieselbe Zahl sehen. Zweitens: Auftragsweiterleitung – wenn ein Auftrag aus einem beliebigen Verkaufskanal in Xentral eingeht, wird er als Kommissionierauftrag an das Lager übermittelt, ohne dass ein Mitarbeiter SKUs oder Mengen neu eintippen muss. Drittens: Tracking-Rückmeldung – sobald der Frachtführer ein Paket scannt, fließen Tracking-Nummer und Versandzeitstempel zurück in Xentral, das diese dann an Amazon oder den Shop weiterleitet, um den Auftrag abzuschließen.
Jeder dieser drei Flüsse kann über die native API von Xentral oder über eine Middleware wie die ChannelEngine-Integration laufen, wenn mehrere Marktplätze beteiligt sind. Für Verkäufer, die zusätzlich Plentymarkets-Fulfillment oder Billbee-Integration neben Xentral nutzen, gilt dieselbe Drei-Fluss-Logik – nur mit einem anderen Connector, der zwischen den Systemen übersetzt. Entscheidend ist nicht, welches Tool in der Mitte sitzt. Entscheidend ist, dass Bestand, Aufträge und Tracking über einen Feed laufen statt über drei separate manuelle Routinen.
Was der Betreiber steuern muss
Der Verkäufer und nicht der 3PL besitzt in der Regel die SKU-Stammdaten in Xentral: Produktcodes, FNSKU-Zuordnungen, Bundle-Logik und kanalspezifische Listing-Regeln. Wird eine SKU in Xentral umbenannt oder ein Bundle umstrukturiert, ohne das Lagersystem zu informieren, scheitert die Synchronisation entweder stillschweigend oder übermittelt den falschen Artikel. Der Betreiber entscheidet auch über das Synchronisationsintervall. Eine 15-Minuten-Bestandssynchronisation verhält sich völlig anders als ein nächtlicher Batch, wenn ein Bestseller an einem Nachmittag in einem Flash Sale ausverkauft wird. Die Wahl dieses Intervalls ist eine unternehmerische Entscheidung, kein technisches Detail, und sollte bei demjenigen liegen, der die Amazon Buy Box-Performance verantwortet – denn Stockouts und Übersellungen schädigen beide Account-Health-Metriken, die sich nur schwer wiederherstellen lassen.
Was ohne diese Steuerung schiefgeht
Wenn SKU-Zuordnungen abweichen oder Synchronisationsintervalle zu groß sind, zeigt sich das sichtbare Symptom als Übersellung: Amazon nimmt einen Auftrag für Ware an, die bereits für einen anderen Kanal kommissioniert wurde. Der Verkäufer muss den Auftrag stornieren, was zu einer Defektrate im Account führen kann, oder Ersatzware zu schlechteren Margen beschaffen. Umgekehrt führt eine Unterbestückung der ERP-Sicht zu Phantom-Stockouts, bei denen Amazon ein Listing unterdrückt, obwohl physische Ware im Regal liegt. Beide Fehler haben bei einer Überprüfung dieselbe Ursache: Die ERP-Versandintegration wurde als Nice-to-have statt als umsatzrelevanter Kontrollpunkt behandelt.
Der Übergabepunkt, den die meisten Verkäufer übersehen
Der häufigste Fehler ist nicht die Synchronisation selbst, sondern der Moment, in dem Ware physisch bewegt wird, ohne entsprechendes Systemereignis. Eine Palette wird bei einer Lagerumorganisation verlegt, eine Retoure in ein anderes Fach eingelagert oder ein Rücksendeauftrag zieht Einheiten zur Entsorgung heraus – und keine dieser Aktionen erzeugt eine Transaktion in Xentral. Das System meldet dann einen Bestand, der mit der Realität nichts mehr zu tun hat. Vor der Skalierung des Auftragsvolumens sollte geprüft werden, dass jede physische Bewegung im Lager – nicht nur Verkauf und Wareneingang – ein passendes Ereignis erzeugt, das zurück in das ERP fließt.
Manuelle CSV-Uploads versus automatisierte Synchronisation bei steigendem Volumen
Viele Xentral-Nutzer beginnen mit manuellen CSV-Exporten: Bestandsreport ziehen, in Amazon Seller Central hochladen, täglich wiederholen. Bei zehn oder zwanzig Aufträgen pro Tag ist das mühsam, aber machbar, weil ein Mensch offensichtliche Fehler abfangen kann, bevor sie kundenrelevant werden. Die Wirtschaftlichkeit ändert sich, sobald das Auftragsvolumen die Marke von etwa fünfzig bis hundert Aufträgen pro Tag über mehrere Kanäle hinweg überschreitet, weil der CSV-Prozess sich nicht in die verfügbare Zeit zwischen Verkaufsspitzen und Versand-Cut-offs pressen lässt.
Das unternehmerische Argument für die automatisierte Synchronisation geht nicht um Eleganz, sondern um die Kosten der Fehler, die manuelle Prozesse nicht schnell genug erkennen: ein stornierter Auftrag wegen Übersellung, eine verspätete Sendung, weil ein Auftrag sechs Stunden in einer Export-Warteschlange lag, oder ein Kundenservice-Ticket, weil Tracking nie beim Marktplatz ankam. Jeder dieser Fälle verursacht direkte Kosten durch Rückerstattungen, Account-Health-Strafen oder Arbeitszeit. Die automatisierte Synchronisation tauscht eine feste Integrationskosten gegen eine laufende Reduzierung dieser Fehlerquoten – und dieser Tausch wird schon lange vor dem Punkt vorteilhaft, an dem die meisten Verkäufer ihn erkennen.
Signale, dass es Zeit für die Automatisierung ist
Ein Auftragsvolumen, das regelmäßig das übersteigt, was eine Person morgens in unter einer Stunde manuell abgleichen kann, ist das klarste Signal. Ein zweites Signal ist der Betrieb von mehr als zwei Verkaufskanälen, die denselben physischen Bestand nutzen, da manuelle Abgleiche über mehrere Kanäle die Wahrscheinlichkeit von Abweichungen erhöhen. Ein drittes Signal ist jeder kürzliche Übersellungsfall, der eine Amazon-Richtlinienwarnung ausgelöst hat – ein nachlaufender Indikator, dass der aktuelle Prozess bereits mindestens einmal versagt hat.
Was auch bei Integration manuell bleibt
Automatisierung nimmt nicht die Notwendigkeit eines menschlichen Verantwortlichen für die Bearbeitung von Ausnahmen: ein fehlgeschlagener API-Aufruf, eine SKU, die sich nicht sauber zwischen Xentral und dem Lagersystem zuordnen lässt, oder ein Bundle-Produkt, das manuelle Kommissionierhinweise benötigt. Shopware-Fulfillment-3PL-Setups brauchen insbesondere jemanden, der prüft, ob Aktions-Bundles und Multipacks auf beiden Seiten korrekt abgebildet sind. Ziel der Integration ist die Reduzierung routinemäßiger manueller Arbeit, nicht die Abschaffung einer benannten Person, die täglich die Ausnahme-Warteschlange überwacht.
Wer welchen Teil des Feeds verantwortet
In einer typischen Konstellation besitzt der Verkäufer die Produktdaten und Kanal-Listing-Regeln innerhalb von Xentral. Der 3PL oder das Lagersystem besitzt die physische Bestandsgenauigkeit und die Kommissionier- und Verpackungsausführung. Die Integrationsschicht – egal ob native API oder Middleware – verantwortet die Übersetzung und das Timing zwischen beiden. Wenn etwas nicht funktioniert, lautet die schnellste Diagnose-Frage, welcher der drei Verantwortlichen die betroffene SKU zuletzt angefasst hat, da sich der Fehler so sofort auf einen Dateneingabefehler, einen physischen Handhabungsfehler oder einen Synchronisations-Timing-Fehler eingrenzen lässt.
Wo Integrationen stillschweigend scheitern, obwohl sie verbunden wirken
Ein häufiger blinder Fleck ist die Annahme, die Verbindung sei binär – entweder integriert oder nicht –, obwohl in der Praxis eine teilweise Integration der Normalfall und der riskanteste Zustand ist. Ein Verkäufer könnte die Auftragsweiterleitung perfekt laufen haben, während die Tracking-Rückmeldung auf einem verzögerten Batch-Job läuft. Amazon zeigt dann Aufträge lange nach Verlassen des Gebäudes als nicht versendet an und verschlechtert so leise die Lieferperformance-Metriken. Ein weiterer stiller Fehler ist eine Währungs- oder Mengeneinheiten-Diskrepanz zwischen den Systemen: Xentral führt den Bestand in Einzelstücken, ein 3PL-System in Kartons – und eine in der Integrationskonfiguration versteckte Rundungsannahme lässt die Zahlen über Wochen langsam auseinanderdriften.
Mehr-Marktplatz-Verkäufer mit ChannelEngine-Integration neben Xentral haben ein ähnliches Risiko: Jeder Marktplatz-Connector hat möglicherweise eigene Synchronisationszyklen, sodass Amazon.de alle zehn Minuten aktualisiert, ein zweiter Marktplatz aber stündlich. Es entstehen kurze Fenster, in denen dieselbe Einheit technisch auf zwei Kanälen gleichzeitig verfügbar ist. Keiner dieser Fälle ist ein Fehler der Absicht, sondern ein Fehler, weil niemand die End-to-End-Timing-Map über alle verbundenen Systeme hinweg verantwortet. Der praktische Fehler ist die Annahme, dass fließende Daten auch korrekt und mit derselben Geschwindigkeit überall dort fließen, wo sie benötigt werden.
Prüfpunkte vor dem Go-Live
- SKU- und FNSKU-Zuordnung stimmt exakt zwischen Xentral und dem Lagersystem überein
- Das Synchronisationsintervall ist auf die tatsächliche Auftragsgeschwindigkeit abgestimmt und nicht auf eine Standardeinstellung
- Bundle- und Multipack-Produkte haben explizite Kommissionierregeln auf beiden Seiten
- Währungs- und Mengeneinheiten-Definitionen stimmen über alle verbundenen Systeme überein
Prüfpunkte nach dem Go-Live
- Die Tracking-Rückmeldung entspricht dem tatsächlichen Scan-Zeitpunkt und nicht einem verzögerten Batch
- Eine benannte Person prüft die Ausnahme-Warteschlange täglich und nicht nur bei Fehlermeldungen
- Bestandszahlen werden wöchentlich zwischen Xentral und dem physischen Lager abgeglichen
- Rücksendeaufträge und Retouren erzeugen ein Bestandsereignis und nicht nur einen Vermerk in einer Tabelle
Die Integration sequenzieren, ohne den Auftragsfluss zu stoppen
Die praktische Rollout-Reihenfolge ist wichtiger als die technische Architektur. Beginnen Sie ausschließlich mit der Bestandssynchronisation und führen Sie diese mindestens einen vollen Auftragszyklus parallel zum bestehenden manuellen Prozess aus. Vergleichen Sie täglich den automatisierten Feed mit dem manuellen Export, um Zuordnungsfehler zu erkennen, bevor sie einen Live-Auftrag betreffen. Sobald die Bestandssynchronisation vertrauenswürdig ist, schalten Sie die Auftragsweiterleitung zunächst für einen einzelnen Kanal frei – in der Regel den umsatzstärksten –, statt alle Kanäle gleichzeitig zu aktivieren. Die Isolierung eines Kanals erleichtert die Fehlersuche erheblich.
Die Tracking-Rückmeldung wird meist als letztes Stück aktiviert, da sie von der Zuverlässigkeit der beiden vorherigen Flüsse und von konsistent verfügbaren Frachtführer-Scan-Daten abhängt. Halten Sie während dieser gesamten Sequenz den manuellen Fallback-Prozess dokumentiert und einsatzbereit, denn eine teilweise Integration, die stillschweigend scheitert, ist schlechter als ein allen bekanntes, unvollkommenes manuelles Verfahren. Verkäufer, die von Plentymarkets-Fulfillment oder einer Billbee-basierten Lösung auf einen Xentral-zentrierten Feed wechseln, sollten dieselbe dreistufige Sequenz erwarten – angepasst an den jeweiligen Connector in der Mitte.
Ein Praxisbeispiel, das man kopieren sollte
Ein Xentral-Verkäufer mit Amazon.de und Shopware-Shop hat seinen Rollout über sechs Wochen gestaffelt: zwei Wochen parallele Bestandssynchronisations-Validierung, zwei Wochen Auftragsweiterleitung nur für Amazon, dann zwei Wochen Hinzunahme der Shopware-Auftragsweiterleitung und vollständiger Tracking-Rückmeldung. Der gestaffelte Ansatz hat in Woche drei einen Bundle-Zuordnungsfehler aufgedeckt, der sonst während einer Werbeaktion zu Fehlkommissionierungen geführt hätte. Langsamerer Rollout, weniger Live-Zwischenfälle.
Bestandssynchronisation
Lagerbestandsmengen fließen in festen Intervallen in Xentral ein und geben allen verbundenen Kanälen dieselbe verfügbare Menge.
Auftragsweiterleitung
Aufträge aus jedem Kanal werden als Kommissionieraufträge an das Lager weitergeleitet, ohne manuelle Neueingabe von SKUs oder Mengen.
Tracking-Rückmeldung
Frachtführer-Scan-Daten gelangen zurück in Xentral und werden an den Marktplatz gemeldet, sodass der Auftragszyklus ohne manuelle Aktualisierung geschlossen wird.
Entscheidung, ob manuelle Synchronisation bei Ihrem Volumen noch funktioniert
Der Entscheidungspunkt ist nicht, ob eine Integration technisch möglich ist – die meisten Xentral-Setups unterstützen sie. Der Entscheidungspunkt ist, ob der aktuelle manuelle Prozess noch günstiger ist als die Kosten seiner eigenen Fehler: stornierte Aufträge, Account-Health-Warnungen und die Stunden, die jede Woche für den manuellen Bestandsabgleich aufgewendet werden. Wenn das Auftragsvolumen den Punkt überschritten hat, an dem eine Person die Kanäle jeden Morgen nicht mehr sicher abgleichen kann, oder wenn ein kürzlicher Übersellungsfall bereits eine Marktplatz-Warnung ausgelöst hat, ist das das Signal, von CSV-Uploads zu einer echten Xentral-ERP-Integration mit Lager und Amazon-Feed zu wechseln. Verkäufer, die Fulfillment-Tools und -Dienste parallel dazu prüfen, sollten vor der Wahl eines Connectors zunächst klären, welcher der drei Flüsse – Bestand, Auftragsweiterleitung oder Tracking – derzeit die schwächste Stelle darstellt.
Wenn Übersellungs-Vorfälle, verzögerte Tracking-Updates oder manuelle Abgleichsstunden in Ihrem Xentral-Setup zum wiederkehrenden Muster werden, verbindet FLEX. Logistik deutsche und DACH-Verkäufer dabei, ERP-Systeme, Lagerbetrieb und Amazon-Feeds in einen koordinierten Fluss zu bringen. Nehmen Sie Kontakt auf, um gemeinsam zu klären, welcher Übergabepunkt in Ihrem aktuellen Prozess zuerst behoben werden muss – sei es das Timing der Bestandssynchronisation, die Auftragsweiterleitungs-Zuordnung oder die Zuverlässigkeit der Tracking-Rückmeldung.
