xRechnung und Zugferd werden falsch ausgestellt

[sebjo82]

Siehe meine Nachricht von zuvor ... nicht die Ausgabe der 4 Stellen ist das Problem, das kann man auch selbst, zumindest in der XRechnung, beheben. Das Problem ist, dass JTL mit 4 Stellen rechnet, "alle anderen" nur mit 2 Stellen.

Beispiel:
in JTL 10 x 0,2440 EUR = 2,44 EUR + 0,4636 EUR USt = 2,90(36) EUR
rest der Welt. 10 x 0,24 = 2,40 EUR + 0,46 EUR USt = 2,86 EUR

Berechnung seitens JTL auf JTL Grundlage.
Prüfung laut Welt im Hinblick auf 2 Stellen. Hier entsteht der Widerspruch.

Bei JTL kommt in der Position eine andere Summe zusammen als in der Validierung. Umsatzsteuer im Beispiel zufällig "gleich", trotzdem unterscheidet sich die Endsumme.
Deswegen nutzt auch ein Runden im Formular auf 2 Stellen nichts, da der Betrag in der Positions-Summe und in der Endsumme und meist auch in der Steuer nicht mit den erwarteten Daten in der Validierung übereinstimmt. Also so in etwa denke ich.

Korrekt, es muss eine Korrektur-Position von in der Regel +-1 Cent in die X-Rechnung geschrieben werden, um den Rundungsfehler der bei Summierung der Netto-Einzelpositionen auftritt auszugleichen, damit der Vergleich mit Gesamt-Netto nicht fehlschlägt

Die bislang angesprochenen Lösungen greifen diese Problematik nicht auf

X-Rechnung Einzelposition darf max 2 Nachkommastellen haben
Wawi speichert 4
Also wird gerundet in der X-Rechnungsvorlage
Gesamt-Netto wurde mit 4 Nachkommastellen berechnet
Es kommt zur Differenz, wenn Lexware die Einzelpositions-Nettos aufsummiert und mit Gesamt-Netto vergleicht

Wie vermeidet man diese Differenz ohne 5 Jahre auf JTL zu warten?
Immer nur Netto-Preise mit 2 Nachkommastellen in der Wawi pflegen.
Und oder man arbeitet mit den angesprochenen Korrektur-Positionen von +- 1 Cent

Wenn jemand Hilfe bei der Implementierung braucht, sodass diese auch in Lexware importiert werden können, gerne per Nachricht melden

 

[Richard von Eggstätt]

Ich zitiere hier meine Buchhalterin, die seit Jahrzehnten im Geschäft ist: „Rundungsfehler sind ein alter Hut. Die gab es schon immer und die wird es immer geben.“
Also wir verkaufen z.B. auch Meterware mit einem Preis ab 0,03 EUR / Meter. Wie will man mit 3 Ct die korrekte MwSt. rechnen? Ich halte das für nicht so tragisch. Wichtig wäre tatsächlich, dass die X-Rechnung valide ist.

 

[sebjo82]

Ich zitiere hier meine Buchhalterin, die seit Jahrzehnten im Geschäft ist: „Rundungsfehler sind ein alter Hut. Die gab es schon immer und die wird es immer geben.“
Also wir verkaufen z.B. auch Meterware mit einem Preis ab 0,03 EUR / Meter. Wie will man mit 3 Ct die korrekte MwSt. rechnen? Ich halte das für nicht so tragisch. Wichtig wäre tatsächlich, dass die X-Rechnung valide ist.

Genau, es geht auch eher darum, dass X-Rechnungen ohne Meckern in Programme wie Lexware importiert werden können. Online-Validatoren, wie https://erechnungsvalidator.service-bw.de/ prangern diese Art Fehler nicht an. Daher ist es auch völlig ok diese Korrekturpositionen in die Rechnung zu schreiben

 

[marsblau]

Immer nur Netto-Preise mit 2 Nachkommastellen in der Wawi pflegen.

Problematisch wenn man glatte Preise haben möchte. Importiert man Brutto gerundet, rechnet JTL beim Netto auf 4-Stellen nach dem Komma runter anstatt beispielsweise Brutto und Netto zweistellig aus einem Import zu übernehmen. Ärgerlich, denn krumme Preise (und seinen es nur x,x9) möchte man ggf. nicht.

 

[Richard von Eggstätt]

Ich sehe die vierstellige Rechengrundlage duchaus als Vorteil. Bei sehr geringen Preisen, wie bei uns z.B. 3 Ct / Meter ist eine Steuerrechnerei nur zweistellig gar nicht wirklich möglich. Nur so, hatten wir 2024 eine Steuerdifferenz von nur 25 EUR (Rundungsfehler). Ich möchte mir das gar nicht ausmalen was wäre, wenn ausschliesslich mit zwei Nachkommastellen gerechnet werden sollte. Mir persönlich wäre nur wichtig, das in der E-Rechnung eben nur zwei Nachkommastellen ausgewiesen sind, damit das überkandidelte Lexware das auch frisst. Mehr muss von mir aus gar nicht sein.

 

[sah]

Im Guide heißt es etwas lapidar "Vorlagen der Ausgabe 2.0" verwenden, wie erstelle/konvertiere ich diese mit wenig Aufwand?

 

[frankell]

Hallo @sah,

kommt darauf an, was genau Dein Ziel ist. Eine X-Rechnung "erzeugst" Du einfach, indem Du eine neue Exportvorlage vom Typ X-Rechnung anlegst. Möchtest Du ein ZUGFeRD, musst Du auch eine neue Speichervorlage (das sind die, die nicht mit dem Zusatz "(Veraltet)" versehen sind) anlegen. Nur dass die Speichervorlage für ein ZUGFeRD noch nicht editierbar ist. Das ist erst ab der Version 1.11 möglich.

 

[sebjo82]

Bedenkt bei Zugpferd, dass diese nur für B2B, NICHT für B2G gedacht sind (in Deutschland zumindest). B2G benötigt (falls überhaupt eine E-Rechnung gefordert wird) unbedingt XRechnung, d.h. eine .xml Datei

 

[Print-Green]

Leider können noch immer keine ordnungsgemäßen E-Rechnungen erstellt werden, wir haben schon viele Kundenanfragen immer mal wieder.

 

[faceofboh]

versteh nicht das sowas keine Priorität hat. Ich kann kaum an eine Behörde ne richtige Rechnung senden. Diese (schlechte) Lösung hier aus dem Beitrag macht rundungsfehler, und wieder muss die XML "Bearbeitet" werden. Das ist doch keine Lösung!

Rheinland-Pfalz ist ebenfalls besonders pingelig.

 

[sebjo82]

Ich habe eine funktionierende XRechnungs-Export-Vorlage erstellt, welche ich für einen kleinen Obolus anbieten kann. Bei Interesse gerne via DM melden