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...

[Harry Stahl]

Ich denke ich mache es jetzt so, dass der Anwender sich für das ZUGFeRD-format (mit CII) aussuchen kann, ob er die Brutto oder Nettorechnungsmehtode verwendet, beide Ergebnisse kann ich im Druck und in der XML kongruent abbilden. Bei der X-Rechnung (bzw. UBL) muss der Anwender aber die Nettomethode verwenden, da ich hier wegen der Regel 120 keine Rundungskorrekturen auf Invoice-Line Ebene vornehmen kann.

Aus dem Netto von 8,39 ergibt sich ein Brutto von 9,98, während aus der Bruttoberechnungsmethode eben der Ausgangspunkt 9,99 bleibt (beides mal aber das Netto von 8,39 haben).

Anliegend mal zwei Beispiele für die jeweilige Berechnungsvariante. Bei hohen Mengen und Krummen Beträgen ergeben sich deutlich andere Zahlen, aber das ist eben so.

Aus meiner Sicht ist es eine Variante, die allen Wünschen gerecht wird: Der Hotellier kann seinen Privatgästen und auch den Firmenkunden für die Brutto-Preise, die er angibt, für gleiche Leistungen die gleichen Rechnungsbeträge in Rechnung stellen.

Will man eine X-Rechnung (UBL) erstellen, dann kann man eben nur die Nettoberechnungsmehtode verwenden (die ja offenbar da auch vorgeschrieben ist).

[TUhr]

Hallo,

warum rechnest Du aus deinen Brutto-Preisen nicht jede Position der X-Rechnung individuell aus.

Nehmen wir doch mal das schöne Beispiel von Sven :

Delphi-Quellcode:

<cbc:InvoicedQuantity unitCode="C62">1000</cbc:InvoicedQuantity> (1000 Stk.)
<cbc:LineExtensionAmount currencyID="EUR">8394.957983193277</cbc:LineExtensionAmount> (9990 / 1.19)
<cbc:Percent>19.00</cbc:Percent>
<cbc:PriceAmount currencyID="EUR">8.394957983193277</cbc:PriceAmount> (8394.957983193277 / 1000)

Wenn Du nun den Netto-Einzelpreis * 1000 * 1,19 nimmst, bekommst Du wieder die 9990 €

Oder denke ich hier komplett falsch ?

MfG
Thorsten Uhr

[BlueStarHH]

Die Idee mit vielen Nachkommastellen scheint in der Praxis nicht zu funktionieren. Letzte Woche war ich bei einem Kunden (Behörde), der einen Validator einsetzt, der alle Rechnungen ablehnt, wenn:
-Die Rechnungspositionen mehr als 4 Nachkommastellen haben.
-Alle anderen Beträge mehr als 2 Nachkommastellen haben.

[Harry Stahl]

Zitat:

Zitat von BlueStarHH (Beitrag 1547644)

Die Idee mit vielen Nachkommastellen scheint in der Praxis nicht zu funktionieren. Letzte Woche war ich bei einem Kunden (Behörde), der einen Validator einsetzt, der alle Rechnungen ablehnt, wenn:
-Die Rechnungspositionen mehr als 4 Nachkommastellen haben.
-Alle anderen Beträge mehr als 2 Nachkommastellen haben.

Wahrscheinlich hat man die E-Rechnung eingeführt, damit die öffentliche Verwaltung einen Grund hat, keine Rechnungen mehr bezahlen zu müssen, weil die Anforderungen zur Rechnungserstellung quasi nicht erfüllbar sind...:wink:

Was natürlich ganz toll ist, dass unterschiedliche Validatoren unterschiedliche Ergebnisse haben. Mal wieder alles super geplant...

Na, der Unit-Price sollte aber mit mehr als 2 Stellen möglich sein, oder?
Das andere sollte man mit der Netto-Berechnungsmethode und dem Rounding-Amount hinbekommen können.

[Rollo62]

Zitat:

Zitat von Harry Stahl (Beitrag 1547661)

Wahrscheinlich hat man die E-Rechnung eingeführt, damit die öffentliche Verwaltung einen Grund hat, keine Rechnungen mehr bezahlen zu müssen, weil die Anforderungen zur Rechnungserstellung quasi nicht erfüllbar sind...:wink:

:thumb: Exakt.
Da wird hart um 1/10 Cents gekämpft, während auf der Ausgabseite Billionen und Miliarden in irgendwelchen schwarzen Löchern vaporisieren, für's Allgemeinwohl.
Das interessiert aber niemanden ...
Da muss es dann wohl entsprechend viele Rundungsfehler geben, um das wieder auszugleichen :-D:-D