Rundungsbehandlung in der E-Rechnung

[Harry Stahl]

Rundungsbehandlung in der X-Rechnung

Ich kämpfe immer noch mit der richtigen Vorgehensweise mit Rundungsfehlern in der X-Rechnung.

Bislang habe ich immer meine Rechnungen immer nach der (Brutto) Summenmethode berechnet.

Beispiel: Ich habe ein Produkt, das kostet 7,35 Euro, enthält 19% MWSt.

Nun soll eine Rechnung erstellt werden, wo der Artikel 16 mal verkauft wird.

16 x 7,35 = 117,60 Brutto.

Daraus der berechnete Nettobetrag beträgt 98,82 Euro ( Brutto / 1,19).

MWst also 117,60 - 98,82 = 18,78.

In der X-Rechnung muss ich aber den Nettopreis eines Artikels angeben = 6,18 (gerundet aus 6,17647).
und die Summe aus der Anzahl (also 6,18 x 16 : 92,88).

Hier sieht man also schon, dass aufgrund der Rundungsdifferenzen sich ein höherer Nettosummenbetrag ergibt, als von mir nach
der Summen-Methode berechnet.

Wie gehe ich jetzt damit in der X-Rechnung um?

Meine gedruckte Rechnung, die als Summe 117,60 auseist, sollte das ja auch in der X-Rechnung entsprechend wiedergeben.

Aber wenn ich als Invoice.Lineamount (also summe netto) die 98,82 angebe, beschwert sich der Validator natürlich, weil er die 92,88 berechtnet hat (aus 6,18 * 16).

[Harry Stahl]

Oder ist es erlaubt bei "ivl.GrossPriceAmount" den Wert "6,17625" als Einzel-Nettobetrag anzugeben?
Dann geht die Rechnung auf.

Würde ja eigentlich Sinn machen, da die E-Rechnung die Zahlen ja an einigen Stellen (z.B. bei Basiswerten) mit 4 Nachkommazahlen ausgibt.

[TUhr]

Hallo,

lt Spezifikation :
https://xeinkauf.de/app/uploads/2024...2024-06-20.pdf

Auf Seite 21 siehst Du das Deine Annahme mit den Nachkommastellen korrekt ist.

MfG
Thorsten Uhr

[sh17]

Nach vielem recherchieren und diskutieren ist der aktuelle Stand meines Wissens immer noch: "Es geht mit der aktuellen Spezifikation nicht".

[jaenicke]

Ich kann mich nicht so genau erinnern, aber war bei X-Rechnung nicht eine Rundungskorrektur in einer separaten Zeile dafür möglich? Der Validator prüft ja jede Zeile einzeln, so dass das dann durchgehen sollte.

So viele Möglichkeiten gibt es ja in der Theorie nicht. Mein Favorit wären allerdings auch mehr Nachkommastellen, denn eine Rundung ist ja nur dort erforderlich, wo der Wert auch als Endpreis sichtbar ist.

Die Frage ist nur, was nicht nur durch den Validator geht, sondern auch als korrekt angesehen wird.

[Harry Stahl]

Vielen Dank an Thorsten für den konkreten Verweis auf die Spezifikation.

Das alles passend hinzubekommen (so dass also Werte in den angezeigten Dialogen, beim Druck / in der XML immer kongruent sind), hat mich echt Nerven gekostet (weil mein bisheriger Rechnungsausdruck halt andere Positionen ausgibt, als man in der E-Rechnung angeben muss). Insbesondere hat man Spaß mit dem Validator bei unterschiedlichen Mehrwertsteuersätzen, krummen Werten und Artikelmengen größer 1.

Durch konsequente Verwendung von RoundCurrency (Kaufmännisches Runden) und anschließender eigener Kontrolle der InvoiceLines und ggfflls. Anpassung bein Rundungsfehlern in 0,01 Cent-Schritten bei den Nettobeträgen kann man es passend machen, aber was für ein insgesamt irrer Aufwand.

Und ich möchte drauf wetten, dass mir irgend ein Kunde in naher Zukunft trotzdem wieder eine Rechnung vorlegt, wo so eine blöde Cent-Abweichung drin ist.

Wenn man schon so einen Standard gesetzlich vorschreibt, wäre es angemessen gewesen, eine allgemeine DLL mitzuliefern, welche nur die Preise, Artikel, Mengen und MWSt-Sätze entgegennimmt und dann direkt selbst die XML erzeugt. So gibt es unterschiedliche Librarys, sich ständig ändernde technische Spezifikationen, was die Sache insgesamt nicht gerade einfach macht.

Gut, dass es für uns Delphi-Entwickler die Library von Sven gibt (hier hat es ja in den letzten Wochen viele Aktualisierungen und Anpassungen gegeben), ohne die hätte ich das wohl überhaupt nicht hinbekommen.