Neu Amazon EU-Ausland mit falscher UST (VCS-Lite)

[mesh]

Hallo,

wir nutzen Amazon VCS-Lite.

Manchmal haben wir das Problem dass EU-Ausländer bei der UST-ID einen unvollständigen oder falschen Wert eintragen.

Amazon scheint dies dann zu merken und erstellt die Rechnungen dann nicht als Netto sondern mit 19%.

Das wird dann auch in der Datev (JTL-Datev) Schnittstelle falsch ausgelesen und es wird dann ohne Sachkonto gebucht.

Unsere Lösung wäre jetzt für das Land ein Sachkonto mit 19% anzulegen (was aber eigentlich falsch ist). Dann liest es die Schnittstelle zumindest aus.

So sah es jetzt in einem Beispiel aus (es war Lebensmittel das wurde jetzt mit 19% erstellt da es in Spanien voll besteuert würde)

Gesamtpreis Netto 94,03 €
MwSt. 19,00% 17,87 €
Gesamtpreis Brutto 111,90 €
Gesamtbetrag 94,03 €
Wir weisen auf die Umkehr der Steuerschuldnerschaft (Reverse-Charge Verfahren) gemäß §13b UStG hin. Umsatzsteuer-Identifikationsnummer: HIER EIN FALSCHER WERT
Zahlung ( Amazon Pay) vom 2/12/2022 111,90 €
offener Betrag 0,00 €

wie löst ihr solche Probleme ?

 

[Pinkman]

wie löst ihr solche Probleme ?

VCS Lite nicht mehr zu benutzen. Auch ein sehr großer Lebensmittelhändler hatte mal das Problem das VCS Rechnung mit 19% ausgewiesen wurden. Der hat es vor 2 Jahren abgeklemmt ist ist seitdem glücklich

 

[Stephan K.]

Konflikt: Wawi sagt OSS mit lokaler Steuer (23%), Amazon sagt Ursprungsprinzip (19%). Es lassen sich keine Rechnungen erzeugen. Dir fehlt der Beleg. Und du kannst sie auch nicht mehr bei Amazon hochladen.
Wenn der Beleg manuell erzeugt wurde, muss das VCS- Log bereinigt werden, denn es gibt ja auch keine Zuordnungen...

Leider ein Versagen von beiden Seiten.

 

[mesh]

Konflikt: Wawi sagt OSS mit lokaler Steuer (23%), Amazon sagt Ursprungsprinzip (19%). Es lassen sich keine Rechnungen erzeugen. Dir fehlt der Beleg. Und du kannst sie auch nicht mehr bei Amazon hochladen.
Wenn der Beleg manuell erzeugt wurde, muss das VCS- Log bereinigt werden, denn es gibt ja auch keine Zuordnungen...

Leider ein Versagen von beiden Seiten.

Naja ganz so ist es nicht.

Das Versagen liegt auf Seiten des Käufers. Er hat eine falsche, unvollständige UST-ID bei Amazon hinterlegt. Amazon erkennt das und erstellt eben keine UST-freie Rechnung. Das ist ja so auch erstmal richtig und besser als eine UST-freie Rechnung mit falscher ID zu erstellen.

Das Problem was sich daraus ergibt ist, dass nicht die richtige UST des Landes verwendet wird sondern 19% (jetzt mal unabhängig von Lebensmittel oder nicht Lebensmittel). In unserem Fall hätte das Produkt in Spanien tatsächlich die volle UST.

Die Rechnung ist (unter den falschen Voraussetzungen) dann bei Amazon aber richtig und taucht in der Wawi auch genauso auf. Das funktioniert wie bei allen anderen Rechnungen auch. Da haben wir im Prinzip keine Probleme oder Fehler. Der Beleg ist dann ganz normal in der Wawi.

Das Problem tritt dann erst in der Buchhaltung auf. JTL2Datev exportiert die erstellte Rechnung aber hat dann das Problem dass es die Kombination Spanien und 19% natürlich so nicht gibt und es daher auch kein Sachkonto dafür gibt. Daher kommt hier eine Fehlermeldung beim Verarbeiten und die Rechnung wird nicht ausgelesen.
Hier liegt dann das Problem - was lässt sich mit der unveränderbaren Rechnung von Amazon machen ?! Spanien - Sachkonto mit 19% anlegen ?

Das war und ist jetzt die Frage - wie lässt sich das lösen , bzw. wie lösen das andere ?!?

 

[Stephan K.]

Das Versagen liegt nicht auf Seiten des Käufers. Er hat eine in seinem Land gültige UST-ID, nur wird die eben nicht international anerkannt und Amazon baut fälschlicherweise kein OSS-Fallback dazu ein, sondern ein altes Gesetz (ganz so, als ob man die Lieferschwelle in diesen Fällen nicht überschritten hätte und OSS gar nicht anwendet -> 19% Ursprungslandprinzip).

Das Versagen liegt bei Amazon, dass es das zulässt und du in Spanien mit 21% steuerpflichtig bist (und Amazon den 19%-Anteil für dich auf Deutschland meldet).

Weiterhin kommt das Versagen von JTL hinzu: Die Rechnungen sind gesperrt. Du kannst sie auch nicht erzeugen (sag mir, wie das geht mit VCS-Lite und schau in deinen VCS- Log unter "Error") - denn auch hier müsste die Wawi bereits meckern und nicht erst in JTL2Datev.
Du kannst sie loslösen von VCS und manuell erzeugen - mit 21%. Und dann müssen sie aus VCS manuell heraus gelöst werden.
Also: Falsch erzeugen, da geblockt, und stornieren. Neu ausstellen.
Aber das geht mit VCS UND mit der Wawi nicht.

Wenn du für Spanien ein Sachkonto mit 19% anlegen möchtest - bitte. Du kannst dir sicher sein, dass das mit OSS unvereinbar ist. Und Spanien und Deutschland andere Werte gemeldet bekommen durch die Plattform (was ab 2028 laut derzeitiger Planung sowieso für jede Transaktion verpflichtend wird)

Seid ihr auf der 1.5? Bevor hier Missverständnisse entstehen.

 

[mesh]

naja...wir haben alle betreffenden Rechnungen manuell geprüft, es sind nur sehr wenige und bei allen war keine korrekte UST-ID hinterlegt. Mal fehlte ein Buchstabe , mal eine Zahl..ect..also definitiv ein Fehler des Kunden und sicher auch von Amazon dass dort keine Prüfung auf Richtigkeit stattfindet.

Aber dennoch wurde die Rechnung "normal" über VCS-Lite erstellt. Unsere Wawi 1.5.55 liest die auch normal ein so wie alle anderen auch.
Ja das große Problem ist dass die Rechnung über VCS gesperrt sind. Damit haben wir keine Möglichkeit diese zu korrigieren.

Daher meine Frage noch eine Lösung die unter diesen eingeschränkten Gegebenheiten möglich ist.

 

[Stephan K.]

Ah, die gute, alte 1.5, als die Zeiten mit VCS noch händelbar waren.
Dann mal viel Spaß mit dem Update auf die 1.6. Wir haben es an Weihnachten getan. Ich glaube, ich melde noch immer wöchentlich einige Tickets... und die ersten drei Wochen waren Chaos pur. Mit VCS ist ein Alptraum geworden.
Die Fehler, die es gibt und die man unternehmerisch auf seine Kappe nehmen muss, lassen sich im ERP in keiner Weise anfassen. Die Logiken sind von JTL einfach unvollständig implementiert.

Was du jetzt aber ansprichst, sind zwei verschiedene paar Schuhe.
Das eine sind unvollständige UST-IDs, die man manuell ergänzen muss, das andere EU-weit ungültige UST-IDs, für die amazonintern ein falscher Schritt ausgeführt wird. Oder aber eine insolvente Unternehmerin, die trotzdem nochmal mit UST-ID einkauft, welche bereits ungültig ist, aber Amazon nicht täglich prüft... was dir in der 1.5 so übrigens nicht angezeigt wird. Da die UST-ID in der 1.6 schonmal in der Wawi geprüft wird und solche Aufträge dann auch als "Rechnungsanlage nicht möglich" geflagged werden Da ja z.B. 0% b2b und UST-ID ungültig, also OSS - aber wie mit 0%.



Und jetzt nochmal, da du ja eigentlich schon Zuhauf mit Informationen gefüttert wurdest, aber auf wenig eingehst.

1. USt ist egal, wer den Fehler verursacht hat. Du bist verantwortlich dafür. In Masse.
2. Du musst die Rechnung mit spanischer Steuer ausstellen. Und theoretisch mit 19%, denn da die erste (VCS-)Rechnung falsch, aber das FA nicht wissen kann, welche richtig ist, doppelte Umsatzsteuer.


Derzeit (1.5) sieht es so aus, als ob auf Amazon die 19% gemeldet werden und ihr 22% Rechnungen hochladet. Korrekt?
Was willst du da mit nem UST-Individualkonto für Spanien in Datev jonglieren.


Edit: Keine steuerliche BEratung etc, nur Hinweise auf mögliche Schwierigkeiten in der Technik und im Gesetz.

 

[mesh]

okay. Ja dann lasse ich die 1.6 mal sein.

Nein die Rechnung wurde tatsächlich mit 19% erstellt - auch in der Wawi.
Da die Daten von Amazon kommen wird die OSS-Einstellung für die UST in der Wawi übergangen.

Denn alle anderen Belege , Onlineshop, Ebay ect., werden in der Wawi immer korrekt mit den Landessteuern angelegt.

Das ist dann auch unser Problem:
Es gibt dann in der Wawi eine Rechnung für Spanien mit 19% UST. Diese Rechnung lässt sich nicht ändern, weil gesperrt.
JTL2Datev versucht diese zu exportieren, aber bringt eine Fehlermeldung weil es für Spanien kein Sachkonto für 19% UST hat.
-> genau an diesem Punkt hängen wir jetzt

Eine Lösung war ein Sachkonto für Spanien und 19% UST anzulegen - damit lief der Datev-Export durch.

Natürlich ist das steuerlich so nicht richtig. Daher die Frage ob jemand da noch eine andere Lösung hat die wir auch ohne JTL Support nutzen könnten.

 

[Stephan K.]

Ja, die Belege neu ausstellen mit richtiger Steuer.

Und Referenz. Was es in der 1.6 gibt, dir aber in diesem Fall nichts nützt, da VCS und gesperrt (muss man nicht verstehen, wenn man sie ja eigentlich für die Rechnungserstellung entsperren darf). Gutschriften lassen sich mit der 1.6 schonmal gar nicht korrigieren...

Mit SQL könntest du die Aufträge korrigieren, aber dann machst du alles noch schlimmer.
Stornieren und neu ausstellen wäre der richtige Weg.

 

[mesh]

okay, dann schaue ich mal ob und wie wir das hinkriegen.

Danke !

 

[Stephan K.]

Die Sache ist einfach die: Amazon ist verpflichtet eure steuerlichen Daten zu melden. Also die 19% für diese Bestellung.
Das ist bei einer Rechnung nicht weiter schlimm.

Aber wenn dem FA nach 4 Jahren auffällt, dass ihr hier 7.000 Ust-Schulden angesammelt habt und so die über Jahre gemeldete Differenz zum von Marktplätzen gemeldeten "Soll" lautet, wäre das ne Prüfung wert.
Und dann müsst ihr schön säuberlich dokumentiert vorweisen, wieso alle Rechnungen keine 19% haben und ihr den Staat nicht mit Steuern hinterzogen habt. Denn um solch gravierenden Sachverhalte geht es hier.


Daher ist mir der "Kundenfehler" ziemlich popelig im Vergleich zu dem, wohin JTL uns hier rein reitet, weil es mit der 1.6 keine durchdachte Logik gibt, um das "bequem" zu lösen.
Natürlich ist Amazon der ursächliche Fehler. Aber JTL bietet keine manuelle Korrekturoption in der 1.6, die auch funktioniert.

Wir führen derzeit doppelt ab. Und schalten VCS erstmal aus, weil das zu teuer wird... wir haben aber auch nur 1% b2b Kunden auf Amazon. Da ist der Zugewinn verschmerzbar.

 

[Pinkman]

wir haben aber auch nur 1% b2b Kunden auf Amazon. Da ist der Zugewinn verschmerzbar.

Wir haben auch einen Zugewinn an B2B Kunden ohne VCS. Aus Erfahrungen mit anderen Händler die VCS nutzen oder genutzt haben, ist das wohl eine gute Entscheidung es nicht zu nutzen.

 

[mesh]

Ja die steuerrechtliche Seite ist uns natürlich bekannt. In unserem Fall waren das in 3 Monaten 3 Rechnungen mit einem Steuerbetrag von ca. 30 Euro.

Die Fehlerquelle Kunde wird es immer geben, genau bei den 20% aller Amazonkunden bei uns die nicht wissen wo sie wohnen.

Aber natürlich ist JTL in der Pflicht, vor allem im Hinblick auf die Gebühren, diesen Fehler zu beheben, bzw. uns Endanwender eine Möglichkeit zu geben die Fehler in den Rechnungen zu korrigieren.

 

[Pinkman]

genau bei den 20% aller Amazonkunden bei uns die nicht wissen wo sie wohnen.

ja das wird auch immer schlimmer...