JTL Amazon Schnittstelle

Was eine JTL-Amazon-Anbindung wirklich leistet

In JTL-Wawi liegen Ihr Sortiment, Ihre Bestände, Preise und Aufträge. Amazon Seller Central ist der Kanal, in dem ein großer Teil des Umsatzes entsteht - in einem System mit eigener Sprache aus Verkäufer-SKUs, ASINs, Marktplätzen, FBA gegen FBM und einer strengen, ratenbegrenzten API. Die Aufgabe einer JTL-Amazon-Anbindung ist, diese beiden Welten ehrlich zueinander zu halten, ohne dass jemand Tabellen exportiert oder sich per Hand durch Seller Central klickt.

Konkret heißt das zwei Flüsse, die dauerhaft laufen. Ausgehend: JTL sendet Artikellistings, Preise und verfügbare Bestände an jeden Amazon-Marktplatz. Eingehend: Amazon liefert neue Bestellungen, Positionen und Erstattungen zurück, sodass JTL die maßgebliche Quelle dafür bleibt, was verkauft, kommissioniert, versendet und gutgeschrieben wurde. Stimmen beide Richtungen, bleibt JTL-Wawi die operative Drehscheibe und Amazon ist nur ein weiterer Verkaufskanal, den sie versorgt und ausliest.

Welche Daten fließen

Objekt / Vorgang in JTL	Wird auf Amazon zu	Hinweis
Artikel	Listing über Listings- / Produkt-Feed	Je Marktplatz über Verkäufer-SKU gematcht, zur ASIN aufgelöst
Preis (je Marktplatz)	Preis-Feed	Marktplatzwährung und ggf. kanalspezifischer Preis
Verfügbarer Bestand (FBM)	Bestands-Feed (Menge)	Mit Sicherheitspuffer gegen Überverkäufe gesendet
Versand / Tracking	Versandbestätigung zur Bestellung	Versanddienst auf Amazon-Carrier-Codes gemappt
Amazon-Bestellung	Auftrag in JTL	Eine Bestellung zu einem Auftrag; Käuferadresse per Restricted Data Token
Amazon-Bestellposition	Auftragsposition	Verkäufer-SKU zurück auf den JTL-Artikel gemappt
Amazon-Erstattung	Gutschrift in JTL	Gleiche Positionen und Steuerbehandlung wie der Ursprungsauftrag
FBA-Bestand und Gebühren	Nach JTL abgestimmt	FBA-Mengen gehören Amazon; Gebühren aus SP-API-Finanzdaten

SKU-Mapping, Preisregeln, Bestandspuffer und Carrier-Übersetzungen stimmen wir einmalig ab und hinterlegen sie in der Pipeline. Danach tippt sie niemand mehr nach.

Die Details, an denen naive Syncs scheitern

Ein schneller Feed-Upload oder ein generischer Connector bringt den Happy Path zum Laufen und überlässt Ihrem Team die teuren Sonderfälle im Produktivbetrieb:

• SKU-zu-ASIN-Zuordnung. Amazon denkt in Verkäufer-SKUs und ASINs, JTL in Artikelnummern. Eine einzige falsche oder doppelte Zuordnung listet einen Artikel auf der falschen ASIN oder spaltet ihn über Marktplätze hinweg. Varianten und Bundles müssen explizit gemappt werden, nicht erraten.
• Mehrere Marktplätze und Währungen. Ein Pan-EU-Händler hat Amazon.de, .fr, .it, .es und oft .nl, .se oder .pl - je mit eigenem Preis, eigener Währung und eigenem Listing-Status. Die Anbindung muss den Marktplatz als eigene Dimension behandeln, nicht überall denselben Preis ausspielen.
• FBA gegen FBM. FBM-Bestand verwalten Sie selbst und muss mit Puffer gesendet werden. FBA-Bestand gehört Amazon und muss zurückgeholt, nie überschrieben werden. Wer beides verwechselt, überverkauft das eigene Lager oder streitet mit Amazon um dessen eigenen Bestand.
• Rate-Limits und Restricted Data der SP-API. Die Selling Partner API ist je Operation nach einem Token-Bucket-Modell gedrosselt, und Käufer-PII liegt hinter einem Restricted Data Token. Ein naiver Sync, der die API überrennt oder personenbezogene Daten hortet, bricht Quoten und DSGVO zugleich.
• Bestellstatus und Timing. Bestellungen im Status Pending haben weder bestätigte Zahlung noch Käuferadresse; sie als versandfertig zu importieren ist ein Fehler. Amazon-Daten haben zudem Verzug, daher brauchen Delta-Abrufe auf Basis des Änderungszeitstempels Überlappung und Deduplizierung statt eines simplen Seit-Zeitstempels.
• USt und Marketplace-Facilitator-Regeln. Je nach Marktplatz und Amazon VAT Calculation Service wird die Steuer von Amazon oder von Ihnen einbehalten und abgeführt. Die Bestelldaten müssen die richtige Steuerbehandlung mitführen, damit JTL und jede nachgelagerte Buchhaltung stimmen.
• Teilweise fehlgeschlagene Feeds. Amazon nimmt einen Feed an und meldet die Ergebnisse dann je SKU asynchron zurück. Eine Pipeline muss diesen Verarbeitungsbericht auswerten, nur die fehlgeschlagenen SKUs erneut senden und nie annehmen, dass ein angenommener Feed jede Zeile erfolgreich verbucht hat.

Wie wir sie bauen und betreiben

Wir bauen das als Pipeline, nicht als geplanten Export. Ausgehende Listing-, Preis- und Bestandsänderungen werden entprellt und als Feeds an die SP-API übergeben; eingehende Bestellungen und Erstattungen holen wir im kurzen Intervall ab, auf Basis des Änderungszeitstempels mit Überlappung, und schreiben sie nach JTL. Jeder Vorgang trägt eine stabile Kennung, sodass ein erneuter Lauf nie einen doppelten Auftrag anlegt oder eine Erstattung doppelt bucht - die Pipeline ist idempotent by design.

Sie läuft auf cloud-nativer, vollständig EU-gehosteter AWS-Infrastruktur, sodass Bestell- und Käuferdaten die EU nicht verlassen - das hält AVV und Ihre DSGVO-Pflichten sauber. Personenbezogene Käuferdaten holen wir nur, wenn der Versand sie braucht, und speichern nur das nötige Minimum.

Und dann halten wir sie am Laufen. Monitoring, Alerting, Incident Response und - entscheidend - das Beobachten von Änderungen an der Amazon SP-API und an JTL liegen vertraglich bei uns. Wenn Amazon einen Feed-Typ abkündigt oder ein Rate-Limit verschärft, ist das unser Problem, nicht eine böse Überraschung, die Ihr Betriebsteam mitten im Weihnachtsgeschäft entdeckt. Sie bekommen einen festen Ansprechpartner und ein SLA statt eines Skripts, an dessen Ausführung jemand denken muss.

Wann sich diese Anbindung lohnt

Wenn Sie über ein einzelnes Amazon.de-Konto verkaufen und JTL-eazyAuction das abdeckt, ist das völlig in Ordnung - und wir sagen Ihnen das auch. Eine betriebene Pipeline lohnt sich, wenn der Kanal ernst wird: mehrere Verkäuferkonten zusammenführen, Pan-EU-FBA über Marktplätze, individuelle oder kanalspezifische Preise, hohe SKU-Zahlen, bei denen Überverkäufe echtes Geld kosten, oder der Bedarf, Bestell- und Abrechnungsdaten in ein Warehouse, die Buchhaltung oder ein Reporting weiterzureichen, das eazyAuction nie berührt. Ab da lautet die Frage nicht mehr, ob Sie die Daten bewegen können, sondern wer sie verantwortet, wenn Amazon die Regeln ändert.