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.

[BlueStarHH]

Mein letzter Wissenstand ist:
Bruttopreise können in E-Rechnungn nicht abgebildet werden. Da E-Rechnung nur B2B-Rechnung sind, wird auch von mehreren Stellen behauptet, dass man das nicht brauchen würde, da im B2B-Bereich Nettopreise üblich seien. Daher werden Bruttpreise nicht in den Standard aufgenommen. Irgendwo bei der DATEV stand z.B. dass ausschließlich mit Nettopreislisten gearbeitet werden soll.

Einfach mehr Nachkommastellen zu verwenden, lößt das Problem evtl. in Einzelfällen. Es wird aber Preise geben, wo auch mehr Nachkommastellen nicht reichen werden. Mein Steuerberater hat mal gesagt: Im B2B-Bereich gibt es einfach bestimmte Bruttopreise nicht. Sie sind nicht darstellbar und existieren daher nicht.

Also nur mit Nettopreisen arbeiten und privaten Endkunden keine E-Rechnung geben. Dann hat sich das Problem erledigt.

[Harry Stahl]

Na, erzhähl das mal z.B. dem Hotelgewerbe, die weisen ihre Preise in Brutto aus. Empfänger der Rechnungen sind sowohl Private, als auch Unternehmen. Auch wenn die E-Rechnung nur an Unternehmen geht, sollte die Druck-Rechnung bei beiden Empfängern ja gleich sein (und somit eben auch keine Abweichung zur E-Rechnung haben).

Oder falls Du recht hast (Chat-GPT stimmt Dir zu), welche Lösung würde man in einem solchen Falle für das Hotelgewerbe nutzen?

[sh17]

Auch der Buchhandel mit Buchpreisbindung ist betroffen, da gibt es durchaus B2B-Beziehungen (Verlag - Buchhandel).

Mehr Kommastellen wären theoretisch eine Lösung, dann müsste man aber 100% auf XRechnung setzen ohne PDF-Bild, weil das PDF sieht dann verwirrend aus.
Und man müsste unter Umständen sehr viele Nachkommastellen nehmen, weil bei Mengen größer 1 gibts trotzdem Rundungsfehler.

Beispiel Brutto 9,99 EUR:

1 x 8,395 EUR + 19% = 9,99005 EUR gerade so richtig

1000 x 8,395 EUR + 19% = 9990,05 EUR "falsch"
1000 x 9,99 = 9990,00 EUR richtig

[Harry Stahl]

Beim Cross Industustry Invoice Format (CII) habe ich bislang immer die Summe der Nettozeilen bei Rundungsdifferenzen in 0,01 Cent Schritten angepasst, wenn es mal Rundungsdifferenzen gab. Jetzt habe ich noch gemerkt, dass es auch

das Feld ram:SpecifiedTradeSettlementHeaderMonetarySummatio n/ram:RoundingAmount, gibt, wo man den Differenzbetrag (also die Rundungsabweichung) angeben kann.

In Svens Implementation wäre das "PayableRoundingAmount : Currency; //BT-114"

in den Demos (XRechnungUnit2estCases) gibt es allerdings kein Beispiel (da steht momentan noch ein TODO)

Anpassung der Summe der Nettozeilen geht aber im UBL-Format nicht, da man dann dort (anders wohl als beim CII) die Fehlermeldung "PEPPOL-EN16931-R120" erhält, wo der Validator dann noch mal rückrechnet, ob sich aus der Summe einer Nettozeile wieder der gleiche Netto-Einzelbetrag ergibt, wenn man den GesamtNettobetrag durch die Anzahl teilt (mit dem Ergebnis, dass gleiche von mir erzeigte Beträge im CII-Format vom Validator akzeptiert werden, im UBL-Format aber nicht).

Ich werde also jetzt mal mein Glück versuchen, indem ich im UBL-Format keine Rundungsanpassung auf Netto-Zeilen-Ebene vornehme, sondern am Ende den Betrag der Rundungsabweichung auf Rechnungsebene angebe.

Aber prinzipiell sieht es so aus, als ob ich für UBL (oder X-Rechnung) möglicherweise nur die Nettoberechnungsmethode verwenden kann. Das wirft aber wie erwähnt verschiedene Probleme auf, da ich alle meine EinzelPreise in Brutto ausweise und je nachdem, ob ein Privatkunde kauft oder ein Unternehmer unterschiedliche Berechnungsmethoden anwenden müsste.

Insgesamt alles echt nicht einfach, die unterschiedlichen Anforderungen unter einen Hut zu bekommen...