Neu MIAS-Prüfung aktiviert - Steuerfrei nur bei positiver Bestätigung?

[intrinsicforce]

Hallo!

Wenn die "MIAS-Bestätigung" auf "Ja" gesetzt wird, ist die Bestellung dann nur steuerfrei wenn ID & Anschrift (??) auch positiv geprüft werden?

Hintergrund:
Wir haben hier häufiger das Problem, dass ausländische Firmen bzw. deren Einkäufer offenbar ihre eigene offizielle Firmenbezeichnung / Anschrift gar nicht genau kennen. Diese möchten jedoch fast immer Rechnungen ohne USt, und da muss dann erstmal hin und her gefragt werden wie die korrekten Daten denn nun eigentlich lauten. Und wenn es da zu keiner Übereinstimmung muss dann eben der USt Betrag noch nachträglich gezahlt werden. Das möchten wir gerne vermeiden, da es viel zu viel Zeit in Anspruch nimmt. Wir nutzen OSS, sodass der Vorsteuerabzug für den Abnehmer doch eigentlich total unproblematisch geworden ist! Korrigiert mich bitte wenn ich hier falsch liege..

Wenn eine Bestellung gar nicht erst ohne Steuer reinkommt wäre das schonmal sehr hilfreich. Ich weiß aber nicht ob das auf diese Weise unterbunden wird, und ob auch wirklich alle Daten (Name, Anschrift inkl PLZ, Straße etc.) geprüft werden.

Alternative wäre steuerfreie IGL nur für den Shop komplett abzustellen. Sodass manuelles erstellen von IGL-Aufträgen in der Wawi weiterhin möglich ist. Aber wie sich das einstellen lässt, weiß ich nicht - wie löst ihr das denn so?

Viele Grüße!

 

[intrinsicforce]

Mir ist gerade aufgefallen, dass kürzlich eine Bestellung aus EU reingegangen ist. Der Kunde hatte keine UStID angegeben - nur einen Firmennamen. Der Shop hat dennoch keine USt berechnet!

Leute, das kann jetzt aber wirklich nicht sein. Manche Kunden geben ja auch sowas wie "none" oder "-" als Firma ein, da sie privat bestellen (nein, Firmenname ist kein Pflichtfeld). Damit hätten sie ja die Möglichkeit steuerfrei auszuchecken in jedem JTL Shop, solange es der Betreiber nicht merkt!

 

[realitor]

Konnten Sie hierzu ein Ergebnis erreichen. Ich bin bei der Prüfung nun auch über einen einzelnen Kunden gestoßen, bei dem dies passiert ist.

 

[intrinsicforce]

Konnten Sie hierzu ein Ergebnis erreichen. Ich bin bei der Prüfung nun auch über einen einzelnen Kunden gestoßen, bei dem dies passiert ist.

Leider nicht. Habe das Eingabefeld für die USt ID jetzt komplett deaktivieren müssen.

Bei Bestandskunden, die schon mal eine ID eingegeben haben, hilft das allerdings auch nicht. Nur bei Neukunden.

Und noch ein weiterer Punkt: Geben Bestandskunden erst bei ihrer zweiten Bestellung die ID ein, so wird diese nicht in der Wawi gespeichert. Die Bestellung kommt aber ohne USt rein. Das darf so einfach nicht bleiben, hierzu wurde aber leider bislang kein Issue im Tracker angelegt.

 

[BodyCultGmbH]

Hi zusammen,


wir stehen aktuell vor genau dem gleichen Thema und würden das gerne einmal sauber einordnen, da wir den Eindruck haben, dass die native JTL-Logik hier nicht ganz trennscharf zwischen Datenerfassung, Validierung und Steuerberechnung arbeitet.


Unser Ziel ist konkret: 👉 Bei EU-Auslandskunden soll die MwSt. nur dann im Checkout entfernt werden, wenn eine USt-ID tatsächlich valide geprüft wurde (z. B. via externem Service wie Endereco inkl. Zeitstempel/Nachweis).


Was wir bisher verstanden haben bzw. beobachten:

• Die JTL-Einstellungen zur USt-ID (inkl. MIAS) beziehen sich primär auf Registrierung und Prüfung der Eingabe, nicht auf eine saubere Kopplung zur Steuerlogik im Checkout
• Der Shop scheint teilweise bereits bei vorhandener USt-ID (ohne echte Validierung) steuerfrei zu liefern → potenziell kritisch
• Gleichzeitig gibt es Fälle, in denen nachträglich eingegebene USt-IDs nicht sauber in die Wawi übernommen werden bzw. nicht konsistent verarbeitet werden

Daher unsere konkreten Fragen:

1. Nach welcher Logik entscheidet JTL nativ, ob eine Bestellung steuerfrei (innergemeinschaftliche Lieferung) erfolgt?
   → Reicht die Existenz einer USt-ID + Auslandslieferadresse?
2. Gibt es irgendeine native Möglichkeit, die Steuerbefreiung an eine erfolgreiche (externe oder interne) Validierung zu koppeln?
3. Falls nicht:
   → An welchen Stellen ( Shop / Checkout / Wawi) würdet ihr erfahrungsgemäß ansetzen, um eine robuste Lösung zu bauen?
   (z. B. Hook im Checkout, Anpassung Kundengruppe, Steuerlogik etc.)

Unser aktueller Ansatz wäre:

• Externe Validierung (z. B. Endereco API)
• Ergebnis → entscheidet im Checkout, ob MwSt. entfernt wird
• Speicherung des Prüfergebnisses für Nachweiszwecke

Bevor wir das aber individuell entwickeln lassen, würden wir gerne verstehen, wie weit man mit der nativen JTL-Logik überhaupt kommt bzw. wo deren Grenzen liegen. Kann jemand dazu was genaueres sagen?


Vielen Dank euch!

 

[intrinsicforce]

JTL ist ein totes Pferd, siehst ja wie sehr das Thema neben anderen hier ernstgenommen wird.

Wartet noch ein bisschen und baut euch dann euer eigenes ERP auf. LLM bedienen kannst du ja schon.

 

[Morimus]

wenn eine USt-ID tatsächlich valide geprüft wurde

Das wirst du so kaum umgesetzt bekommen.
Dafür müssten deine Kunden die Daten nun einmal korrekt hinterlegen.

Wir verkaufen zu etwa 90 % B2B.
Viel davon läuft als innergemeinschaftliche Lieferung und über den Shop.

Gott sei Dank prüft der Shop nicht auf Richtigkeit und winkt die Bestellungen einfach durch.
Denn in den meisten Fällen stimmt das, was die Kunden eingeben, nicht mit dem überein, was tatsächlich registriert wurde.

Das prüfen wir dann, sobald die Bestellung eingeht.
Dafür haben wir ein eigenes Tool, welches die USt-IdNr. und die im Auftrag hinterlegten Daten über VIES prüft.

Wir ändern die Daten dann bei Bedarf.

 

[intrinsicforce]

Das wirst du so kaum umgesetzt bekommen.
Dafür müssten deine Kunden die Daten nun einmal korrekt hinterlegen.

Mit einem Shopsystem welches das Land richtig erkennt, dann das richtige Eingabeschema anzeigt und dessen Eingabe erzwingt wie bei VIES und dann erst die Validierung durchführt (und Ergebnis vollständig ausgibt) ist das alles eigentlich ganz easy. So wissen die Kunden dann auch direkt warum es an der Stelle nicht weitergeht.

Kunden, die ihre richtige B2B Adresse nicht eingeben können oder gar nicht erst kennen, gehören zu der Klasse, die auch mal ihre Rechnungen nicht bezahlen oder ähnlich nachlässig arbeiten. Die kann man an dieser Stelle außen vor lassen.

 

[BodyCultGmbH]

danke euch erstmal für die Rückmeldungen – ich glaube, wir sprechen hier teilweise von unterschiedlichen Zielzuständen.


Unser Ansatz ist nicht, das Thema komplett ins Backend zu verlagern und nachgelagert zu prüfen, sondern bewusst im Checkout sauber zu lösen.


Die Idee wäre technisch wie folgt:

• Kunde gibt im Checkout / bei Registrierung seine Daten ein (USt-ID, Firma, Adresse)
• diese werden über eine externe API (z. B. Endereco / VIES) validiert
• bei erfolgreicher Validierung wird die Bestellung direkt als innergemeinschaftliche Lieferung behandelt (netto)
• bei fehlgeschlagener Validierung bleibt sie brutto oder der Kunde bekommt einen Hinweis zur Korrektur

Also im Prinzip ähnlich wie bei einer Adressvalidierung, nur mit dem Unterschied, dass das Ergebnis direkt Einfluss auf die Steuerlogik hat.


Uns ist bewusst, dass das nicht „out of the box“ im JTL- Shop funktioniert und eine Custom-Implementierung erfordert – die Frage ist für uns eher:


👉 Hat jemand so etwas schon konkret im JTL-Umfeld umgesetzt (inkl. Kopplung von Validierung → Steuerlogik im Checkout)?
👉 Und wenn ja, wo lagen die größten Stolperfallen (z. B. Daten-Matching, UX, Timing der Prüfung etc.)?


Uns geht es weniger darum, das Thema komplett neu zu erfinden, sondern eher darum, vorhandene Erfahrungen mitzunehmen, bevor wir das selbst bauen lassen.


Danke euch!

 

[Morimus]

Ich verstehe deinen Ansatz grundsätzlich sehr gut.
Genau diesen Gedanken hatte ich damals bei Einführung von OSS auch.

Die öffentliche VIES-Prüfung liefert einem eben keine vollständigen Kundendaten zurück.
Man kann nicht abfragen: „Welche Adresse gehört denn zu dieser UID?“ oder „Wie lautet der korrekte Firmenname zu dieser USt-IdNr.?“ Man kann im Grunde nur prüfen lassen, ob die eingegebene Kombination korrekt ist oder eben nicht.

Genau daran scheitert meiner Meinung nach auch die Vorstellung, dass man das komplett zuverlässig im Checkout automatisieren kann.
Bei einfachen Fällen funktioniert das natürlich.
Der kleine Betrieb aus Italien trägt seine italienische UID und seine Firmendaten korrekt ein, die Prüfung läuft durch und alles ist super.

In der Realität haben wir aber sehr viele innergemeinschaftliche Lieferungen und dort sieht man regelmäßig, dass Kunden ihre eigene Firmenstruktur gar nicht so sauber kennen.
Gerade bei größeren Unternehmensgruppen ist das immer ein Graus.

Eine Mitarbeiterin aus dem Einkauf registriert sich bei uns im Shop, trägt als Rechnungsadresse die Adresse der Unternehmensgruppe ein, verwendet aber die UID einer kleineren Tochterfirma innerhalb der Gruppe, bei der sie tatsächlich arbeitet und an die auch geliefert werden soll.

Wenn man dann nur die öffentlichen Möglichkeiten wie VIES/MIAS nutzt, kann man eben lediglich prüfen, ob genau diese Kombination aus Firmendaten und UID bestätigt wird.
Wird sie negativ abgelehnt, gibt es keine offizielle Möglichkeit, einfach „nachzufragen“, wie die korrekten Daten denn lauten müssten.

Es gibt sehr wohl Anbieter, die solche Informationen als Dienstleistung bereitstellen. ustidsuche z.b.

Rechtlich ist das aber ein Thema für sich.
Es hat aus meiner Sicht schon seinen Grund, warum qualifizierte Abfragen in Deutschland inzwischen nur noch digital erfolgen und nicht mehr wie früher per Brief.

Für uns ist es daher einfacher, mit eigenen Tools und Wawi-Workflows die Bestellungen auf Richtigkeit zu prüfen.
Für eine innergemeinschaftliche Lieferung musst du die Richtigkeit der Daten ja sowieso bei Abschluss des Vertrags prüfen.
Das erfolgt über eine qualifizierte Abfrage in Kombination aus der UID des Kunden und dessen Adresse sowie deiner eigenen UID und deiner eigenen Adresse.

Als Antwort erhältst du dann einen eindeutigen Schlüssel, der exakt zu deiner Anfrage erzeugt wurde.
Dieser ersetzt im Grunde den Brief, den du vor einigen Jahren noch erhalten, abgeheftet und viele Jahre aufbewahrt hast.

 

[BodyCultGmbH]

Guter Punkt, das deckt sich auch mit unserer Erfahrung, gerade die Datenqualität auf Kundenseite ist in der Praxis oft das eigentliche Problem.
Teilweise geben die bei uns sogar offensichtlichen Quatsch nur um zu hoffen, dass das einen Steuerabzug triggert, so sieht zumindest manchmal aus.


Unser Ansatz wäre deshalb auch gar nicht, „jeden Fall sauber durch den Checkout zu bekommen“, sondern eher:

• valide Kombination → sauber netto im Checkout
• nicht valide → Bestellung läuft ganz normal brutto durch

Also eher eine klare Trennung statt zu versuchen, jeden Edge Case technisch zu lösen. Die „unsaubere Realität“ (Holding / Tochter / falsche Adresse etc.) würde dann bewusst nicht automatisiert behandelt werden, sondern wie bisher im Backend.

Uns geht es im ersten Schritt vor allem darum, die sauberen Fälle direkt im Checkout zu erkennen und durchzuschleusen, um genau den manuellen Aufwand zu reduzieren, den du beschreibst.

Aber gut, ich denke an dem Punkt muss ich mich direkt dann mit unserem Entwickler und Endereco auseinandersetzen, dass die prüfen, was tatsächlich technisch möglich ist.

Dann ist immer noch die Frage, ob die Friction, die durch unser angedachtes "sauberes" Szenario entsteht (fehlgeschlagener Validierung bleibt brutto + Fehlermeldung), zu Abbrüchen führt. Aber das ist dann ein anderes Thema.

 

[Morimus]

Dann ist immer noch die Frage, ob die Friction, die durch unser angedachtes "sauberes" Szenario entsteht (fehlgeschlagener Validierung bleibt brutto + Fehlermeldung), zu Abbrüchen führt. Aber das ist dann ein anderes Thema.

Ein wichtiges Thema.

Würden deine Kunden sich per E-Mail melden, wenn die Registrierung nicht funktioniert?
Oder kaufen sie dann einfach woanders?
Woran ist die Prüfung gescheitert?

Die Abfrage einer französischen UID braucht in der Regel einige Sekunden länger als zum Beispiel die einer italienischen UID.
Die Abfragen werden von den einzelnen Ländern direkt verarbeitet.
Die Qualität und Geschwindigkeit ist daher von Land zu Land unterschiedlich.

Wie genau dokumentierst du die automatischen qualifizierten Abfragen, wenn der Steuerprüfer später einmal sehen möchte, ob die IGL auch berechtigt war?

Und so weiter und so fort.

Das alles hat mich am Ende dazu gebracht, IGL einfach manuell abzuwickeln.

 

[BodyCultGmbH]

Ein wichtiges Thema.

Würden deine Kunden sich per E-Mail melden, wenn die Registrierung nicht funktioniert?
Oder kaufen sie dann einfach woanders?
Woran ist die Prüfung gescheitert?

Die Abfrage einer französischen UID braucht in der Regel einige Sekunden länger als zum Beispiel die einer italienischen UID.
Die Abfragen werden von den einzelnen Ländern direkt verarbeitet.
Die Qualität und Geschwindigkeit ist daher von Land zu Land unterschiedlich.

Wie genau dokumentierst du die automatischen qualifizierten Abfragen, wenn der Steuerprüfer später einmal sehen möchte, ob die IGL auch berechtigt war?

Und so weiter und so fort.

Das alles hat mich am Ende dazu gebracht, IGL einfach manuell abzuwickeln.

Verstehe deinen Ansatz.


Unserer wäre aber nicht, das komplett sauber durch den Checkout zu „erzwingen“, sondern eher:

• valide Kombination → netto
• nicht valide → ganz normal brutto weiter

Also kein Hard-Blocking, sondern eher eine saubere Trennung. Die „unsauberen“ Fälle (Holding / falsche Kombination etc.) würden wir weiterhin im Backend behandeln und gar nicht versuchen, das technisch komplett zu lösen.


Zum Thema VIES / Performance:
Laut Anbieter (Endereco) wird da über Cache bzw. historische Abfragen gelöst, sodass nicht jede Prüfung live über die EU-Systeme laufen muss. Sollte das Thema Geschwindigkeit etwas entschärfen.


Dokumentation wäre über die qualifizierten Abfragen inkl. Zeitstempel gegeben (Nachweise als PDF), also wie früher die Bestätigung, nur digital. Haben da schon einen Dummy gesehen, Steuerbüro meinte: Passt so.


Uns geht’s im Kern darum, die sauberen Fälle direkt im Checkout rauszuziehen und dadurch den manuellen Aufwand zu reduzieren – nicht darum, jeden Edge Case zu erschlagen.

Falls jemand im JTL-Umfeld sowas (Validierung + Steuerlogik im Checkout) schon umgesetzt hat, wären ein paar Praxis-Insights spannend – gerade wo es gehakt hat.