Hallo zusammen,
ich möchte hier eine wichtige Erfahrung teilen, die uns über längere Zeit fast zur Verzweiflung (und einer drohenden Kontosperrung durch Amazon) getrieben hat. Vielleicht rettet das dem ein oder anderen hier die Rate an Rechnungsmängeln (IDR) oder hilft bei der Argumentation gegenüber der Amazon Verkäuferleistung.
Das Problem:
Wir nutzen für Amazon den Modus VCS Lite / IDU (Amazon berechnet die Steuer, JTL erstellt und lädt die eigene Rechnung hoch). Seit Längerem hatten wir das Problem, dass wir von Amazon Warnungen über fehlende Rechnungen erhielten und unsere IDR massiv in die Höhe schoss. Wir haben dazu etliche Fälle beim Verkäuferservice eröffnet, die aber alle erfolglos blieben (die üblichen Textbausteine).
In der JTL-Wawi sah es so aus:
Die Fehlersuche & Der Beweis:
Nachdem wir unsere JTL-Einstellungen, Startdaten und Workflows zigmal geprüft hatten, haben wir uns die Rohdaten direkt von Amazon gezogen.
Weg: Seller Central -> Berichte -> Steuerdokumentbibliothek -> Amazon Umsatzsteuer-Berechnungen (CSV-Download).
In diesem Export haben wir dann "das eigentliche Problem" gefunden:
Amazon hat bei völlig normalen Inlandsbestellungen (z. B. DE nach DE) in der Spalte "Is Amazon Invoiced" fälschlicherweise ein TRUE übermittelt. Gleichzeitig standen die Felder "VAT Invoice Number" und "Invoice URL" aber auf N/A.
Was bedeutet das technisch?
Die Amazon-API meldete an JTL: "Stopp, wir haben das Rechnungs-Recht übernommen!" – hat aber im Hintergrund gar kein PDF erzeugt. JTL hat sich (völlig korrekt!) an das TRUE-Flag gehalten und den Upload blockiert, um uns vor Doppel-Fakturierung zu schützen. Die Wawi ist hier also komplett unschuldig!
Die Lösung / Aktueller Stand:
Wir haben einen finalen, sehr technischen Fall eröffnet und dem Support exakt diesen Widerspruch in ihrer eigenen API (TRUE aber N/A) dargelegt.
Wir haben zwar keine direkte Antwort auf dieses spezifische Ticket erhalten, aber plötzlich hat sich das Problem in Luft aufgelöst:
Wir hoffen stark, dass Amazon hier kürzlich einen globalen Fix für dieses API-Routing-Problem ausgerollt hat.
Fazit:
Falls ihr in letzter Zeit ähnliche Probleme hattet und eure Aufträge grundlos bei "Externe Rechnungen" landen: Checkt den VAT Calculation Report auf das TRUE-Flag! Es war ein massiver Bug seitens Amazon. Solltet ihr wegen der Mängelrate Probleme mit eurem Konto bekommen, könnt ihr genau diesen Report-Export nutzen, um gegenüber Amazon nachzuweisen, dass ihr durch falsche API-Flags blockiert wurdet.
Hoffe, das hilft dem ein oder anderen!
ich möchte hier eine wichtige Erfahrung teilen, die uns über längere Zeit fast zur Verzweiflung (und einer drohenden Kontosperrung durch Amazon) getrieben hat. Vielleicht rettet das dem ein oder anderen hier die Rate an Rechnungsmängeln (IDR) oder hilft bei der Argumentation gegenüber der Amazon Verkäuferleistung.
Das Problem:
Wir nutzen für Amazon den Modus VCS Lite / IDU (Amazon berechnet die Steuer, JTL erstellt und lädt die eigene Rechnung hoch). Seit Längerem hatten wir das Problem, dass wir von Amazon Warnungen über fehlende Rechnungen erhielten und unsere IDR massiv in die Höhe schoss. Wir haben dazu etliche Fälle beim Verkäuferservice eröffnet, die aber alle erfolglos blieben (die üblichen Textbausteine).
In der JTL-Wawi sah es so aus:
- Der Worker hat für bestimmte Aufträge einfach keine Rechnungen erstellt.
- Diese Aufträge landeten in der Wawi hartnäckig im Reiter Versand -> Rechnungen -> Externe Rechnungen.
- Die Wawi dachte also: "Amazon hat die Rechnung schon geschrieben, ich darf keine mehr hochladen."
Die Fehlersuche & Der Beweis:
Nachdem wir unsere JTL-Einstellungen, Startdaten und Workflows zigmal geprüft hatten, haben wir uns die Rohdaten direkt von Amazon gezogen.
Weg: Seller Central -> Berichte -> Steuerdokumentbibliothek -> Amazon Umsatzsteuer-Berechnungen (CSV-Download).
In diesem Export haben wir dann "das eigentliche Problem" gefunden:
Amazon hat bei völlig normalen Inlandsbestellungen (z. B. DE nach DE) in der Spalte "Is Amazon Invoiced" fälschlicherweise ein TRUE übermittelt. Gleichzeitig standen die Felder "VAT Invoice Number" und "Invoice URL" aber auf N/A.
Was bedeutet das technisch?
Die Amazon-API meldete an JTL: "Stopp, wir haben das Rechnungs-Recht übernommen!" – hat aber im Hintergrund gar kein PDF erzeugt. JTL hat sich (völlig korrekt!) an das TRUE-Flag gehalten und den Upload blockiert, um uns vor Doppel-Fakturierung zu schützen. Die Wawi ist hier also komplett unschuldig!
Die Lösung / Aktueller Stand:
Wir haben einen finalen, sehr technischen Fall eröffnet und dem Support exakt diesen Widerspruch in ihrer eigenen API (TRUE aber N/A) dargelegt.
Wir haben zwar keine direkte Antwort auf dieses spezifische Ticket erhalten, aber plötzlich hat sich das Problem in Luft aufgelöst:
- Es kommen keine falschen TRUE-Flags mehr rein.
- Der JTL-Worker lädt wieder sauber hoch.
- Unsere zerschossene Rate an Rechnungsmängeln (IDR) steht im Seller Central nun plötzlich auf "Nicht verfügbar" (Wir vermuten: Amazon scheint die fehlerhaften Daten aus der Historie gelöscht zu haben bzw. setzt das Fenster gerade zurück).
Wir hoffen stark, dass Amazon hier kürzlich einen globalen Fix für dieses API-Routing-Problem ausgerollt hat.
Fazit:
Falls ihr in letzter Zeit ähnliche Probleme hattet und eure Aufträge grundlos bei "Externe Rechnungen" landen: Checkt den VAT Calculation Report auf das TRUE-Flag! Es war ein massiver Bug seitens Amazon. Solltet ihr wegen der Mängelrate Probleme mit eurem Konto bekommen, könnt ihr genau diesen Report-Export nutzen, um gegenüber Amazon nachzuweisen, dass ihr durch falsche API-Flags blockiert wurdet.
Hoffe, das hilft dem ein oder anderen!
