Rundungsbehandlung in der E-Rechnung

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

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

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 von Harry Stahl:

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

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