Tücken bei der Mehrwertsteuerberechnung (mit Firebird)

[BlueStarHH]

Hallo,

ich habe eine Tabelle mit einzelnen Postionen von Rechnungen. Dabei ist die Gesamtsumme einer Position als Bruttosumme (also inkl. MwSt, Feldname "BruttoSumme") gespeichert. Das muss so sein, da es Endkundenpreise sind, die auf den Cent genau sein müssen.

Ich möchte nun die Bruttogesamtsumme einer Rechnung ermitteln. Daraus die enthaltene MwSt. und den zugehörigen Nettobetrag. Bisher lief das so:

Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto - (Brutto / 1,19)

In SQL für die MwSt:

Code:

cast(
  round(BruttoSumme, 2) - round((round(BruttoSumme, 2) / (MwStSatz / 100 + 1)), 2)
as NUMERIC(18,2)) as Mwst

Entsprechend für Netto:

Code:

cast(
  round((round(BruttoSumme, 2) / (MwStSatz / 100 + 1)), 2)
as NUMERIC(18,2)) as Netto

Ergibt mit meinen Beispieldaten diese Werte:

Code:

MwStSatz:         19,00
Brutto: 150.000.000,00
MwSt:     23.949.579,83
Netto:   126.050.420,17

Laut meinem Steuerberater und diversen Quellen im Internet (Finanzamt!, Wirtschaftsprüfer) darf das aber so *nicht* berechnet werden. Viele würden das falsch machen.

Richtig wäre:

Richtige Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto * (19/119)

Erklärung:

Zitat:

Die Umsatzsteuer errechnet sich durch Anwendung des jeweiligen Steuersatzes auf die sogenannte Bemessungsgrundlage. Der geleistete Bruttobetrag ist deshalb in die Bemessungsgrundlage und die Umsatzsteuer aufzuteilen. Ist bei der Leistung die Umsatzsteuer im Preis enthalten, etwa im Preis einer Eintrittskarte, muss die Umsatzsteuer aus den Einnahmen herausgerechnet werden. Dies geschieht über einen speziellen „Multiplikator für das Herausrechnen der Umsatzsteuer“. Dieser beträgt bei einem Umsatzsteuersatz von 7 Prozent 6,54... (= 7/107) und bei einem Steuersatz von 19 Prozent 15,97... (= 19/119) Prozent des Bruttoentgelts.

In SQL wäre das mit diesem Multiplikator:

Code:

cast(
  round(round(BruttoSumme, 2) * (MwStSatz / (MwStSatz + 100)), 2)
as NUMERIC(18,2)) as Mwst,
  
cast(
  round(BruttoSumme, 2) - (round(round(BruttoSumme, 2) * (MwStSatz / (MwStSatz + 100)), 2))
as NUMERIC(18,2)) as Netto

Wenn ich das aber so mache, fehlen signifikante Stellen (verglichen mit den Zahlen oben):

Code:

MwStSatz:         19,00
Brutto: 150.000.000,00
MwSt:     23.940.000,00
Netto:   126.060.000,00

Was mache ich falsch?
(Die Zahlen müssen so groß sein, um den Effekt zu sehen.)

Ich habe eine fertige Beispieldatenbank angehängt mit der man direkt testen kann. Alternativ die vollständige SQL-Datenbankdefinition der Testdatenbank inkl. Testdaten für mein Beispiel oben.
Das ganze teste ich direkt im IBEXPERT. Hat also nichts mit Problem in Delphi oder der DB-Komponenten zu tun.

Danke!

[peterbelow]

Meiner Meinung nach rundest Du zu oft. Versuch mal

Delphi-Quellcode:

cast(
  round(BruttoSumme * (MwStSatz / (MwStSatz + 100)), 2)
as NUMERIC(18,2)) as Mwst,
 
cast(
  BruttoSumme - (round(BruttoSumme * (MwStSatz / (MwStSatz + 100)), 2))
as NUMERIC(18,2)) as Netto

Kann's momentan nicht selbst testen, sorry.

[Olli73]

Geb mal anstatt +100 +100.00 ein.
Ein Ergebnis in firebird ist abhängig von den Nachkommastellen in der Berechnung.

[BlueStarHH]

Zitat:

Zitat von peterbelow (Beitrag 1538459)

Meiner Meinung nach rundest Du zu oft. Versuch mal

Delphi-Quellcode:

cast(
  round(BruttoSumme * (MwStSatz / (MwStSatz + 100)), 2)
as NUMERIC(18,2)) as Mwst,
 
cast(
  BruttoSumme - (round(BruttoSumme * (MwStSatz / (MwStSatz + 100)), 2))
as NUMERIC(18,2)) as Netto

Kann's momentan nicht selbst testen, sorry.

Es muss so oft gerundet werden, da sonst mit den falschen Werte gerechnet wird. BruttoSumme (das ist Positionsumme) kann bis zu 4 Nachkommastellen haben. Vor dem weiterrechnen muss die auf 2 Stellen gerundet werden, da die Gesamtsummen der Rechnung 2 Nachkommastellen haben müssen. Wenn ich das Runden zum Testen mal *komplett* entferne, stimmt MwSt aber Netto ist immer noch unverändert falsch. Edit: BruttoSumme ist hier die Summe aller einzelnen Rechnungspositionen. Die Summe wird hier gerundet. Und nicht die einzelnen Rechnungspositionen.

[BlueStarHH]

Zitat:

Zitat von Olli73 (Beitrag 1538460)

Geb mal anstatt +100 +100.00 ein.
Ein Ergebnis in firebird ist abhängig von den Nachkommastellen in der Berechnung.

Hat keine Auswirkungen. Ergebnis ist unverändert falsch.

[Gausi]

Zitat:

Zitat von BlueStarHH (Beitrag 1538458)

Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto - (Brutto / 1,19)

[...]

Laut meinem Steuerberater und diversen Quellen im Internet (Finanzamt!, Wirtschaftsprüfer) darf das aber so *nicht* berechnet werden. Viele würden das falsch machen.

Richtig wäre:

Richtige Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto * (19/119)

Da wird doch in beiden Fällen das gleiche berechnet, wenn man mal von potentiellen Rundungsfehlern wegen Maschinengenauigkeit und Darstellung von Gleitkommazahlen absieht.

Oder ist es im Finanzwesen wie in der Musik, wo ein 2/4-Takt auch was anderes ist als ein 4/8-Takt? Wo liegt der Unterschied in den beiden Berechnungen?

[BlueStarHH]

Zitat:

Zitat von Gausi (Beitrag 1538463)

Zitat:

Zitat von BlueStarHH (Beitrag 1538458)

Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto - (Brutto / 1,19)

[...]

Laut meinem Steuerberater und diversen Quellen im Internet (Finanzamt!, Wirtschaftsprüfer) darf das aber so *nicht* berechnet werden. Viele würden das falsch machen.

Richtig wäre:

Richtige Formel (vereinfacht) für die Ermittlung des MwSt-Betrags:
MwSt = Brutto * (19/119)

Da wird doch in beiden Fällen das gleiche berechnet, wenn man mal von potentiellen Rundungsfehlern wegen Maschinengenauigkeit und Darstellung von Gleitkommazahlen absieht.

Oder ist es im Finanzwesen wie in der Musik, wo ein 2/4-Takt auch was anderes ist als ein 4/8-Takt? Wo liegt der Unterschied in den beiden Berechnungen?

Geanu, es geht um die Rundungsfehler. Und es sei vorgeschrieben, dass die zweite Formel benutzt wird. Wenn die Rundungsfehler sich aufsummieren und dann eine Diskussion mit dem FA-Prüfer stattfindet, kann man nur verlieren, wenn man nicht die richtige Formel verwendet. Aber das hier ist ein ganz anderes Thema. Thema ist: Warum fehlen in der zweiten Formel signifikante Stellen?

[Olli73]

Zitat:

Zitat von BlueStarHH (Beitrag 1538462)

Zitat:

Zitat von Olli73 (Beitrag 1538460)

Geb mal anstatt +100 +100.00 ein.
Ein Ergebnis in firebird ist abhängig von den Nachkommastellen in der Berechnung.

Hat keine Auswirkungen. Ergebnis ist unverändert falsch.

Jedenfalls hat es damit zu tun. siehe:

Code:

select
  1/3 as test1,
  1/3.00 as test2,
  1.00/3.00 as test3
from
  rdb$database

ergibt 0 0.33 0.3333

Am besten funktioniert noch alle Zahlen in float zu casten und dann zurück in numeric.

Da mir das cast(...) dafür immer zu lang war, habe ich mir mal UDF-Functions gecshrieben, die nichts anderes taten, als diesen cast durchzuführen, aber besser lesbar und kürzer schreibbar waren.

[Delphi.Narium]

Mit dem Kettensatz ergibt sich folgende Rechnung.

? € Mwst = 19%
119% = 150.000.000,00 € Brutto

Mwst := 19 * 150.000.000,00 / 119

Mwst := 23949579,831932773109243697478992

Mwst := Round(23949579,831932773109243697478992,2)

Mwst := 23949579,83

Mit dem Windowsrechner kommt 23.949.579,83 € als Mehrwertsteuer heraus.

Hierbei ist es egal ob 19 * Brutto / 119 gerechnet wird oder Brutto * (19 / 119). Was mathematisch ja durchaus korrekt ist.

Aber mit Firebird sieht das anders aus:

SQL-Code:

select
  Round(150000000.000 * (19.000 / 119.000),2) as A,
  Round(19.000 * 150000000.000 / 119.000,2) as B
from RDB$DATABASE;

Hier sind die Werte für A = 23949450,000000000 und für B = 23949579,829999998.
Das entspricht einem Fehler von 129,829999998 €.

Ein zweiter Versuch:

SQL-Code:

select 
Round(150000000.00 * (19.00 / 119.00),2) as a,
Round(19.00 * 150000000.00 / 119.00,2) as b
from RDB$DATABASE;

Hier sind die Werte für A = 23940000,000000 und für B = 23949579,830000.
Das entspricht einem Fehler von 9579,83 €.

Ein dritter Versuch:

SQL-Code:

select 
Round(150000000.00 * (19 / 119),2) as a,
Round(19 * 150000000.00 / 119,2) as b
from RDB$DATABASE;

Hier sind die Werte für A = 0,00 und für B = 23949579,83.
Das entspricht einem Fehler von 23949579,83 €.

Ein vierter Versuch:

SQL-Code:

select 
Round(150000000.00 * 19 / 119,2) as a,
Round(19 * 150000000.00 / 119,2) as b
from RDB$DATABASE;

Hier sind die Werte für A = 23949579,83 und für B = 23949579,83.
Das entspricht einem Fehler von 0,00 €.

Es sind hier mehrere "Besonderheiten" zu beobachten.

Die Reihenfolge der Berechnungen hat wesentliche Auswirkungen auf das Rechenergebnis.
Die Anzahl der Nachkommastellen der Eingabewerte hat wesentliche Auswirkungen auf das Rechenergebnis.
Die Klammersetzung hat wesentliche Auswirkungen auf das Rechenergebnis.

FireBird scheint zwar die Reihenfolge bei der Berechnung (zuerst die Klammerausdrücke) zu beachten, dabei aber bei einer Division von Werten ohne Nachkommastellen auch ein Ergebnis ohne Nachkommastellen zu liefern. Integer / Integer = Integer. Deshalb ergibt Fließkomma * Integer / Integer etwas anderes als Fließkomma * (Integer / Integer).

150.000.000,00 * (19 / 119) ergibt bei FireBird 150.000.000,00 * 0 und nicht 150.000.000,00 * 0,15966386554621848739495798319328.

Die Rechenergebnisse von FireBird sind abhängig von der Anzahl bzw. dem Vorhandensein der Nachkommastellen der Eingabewerten.

Mein Fazit: Rechnen mit FireBird sollte man eher unterlassen oder es muss sehr genau auf die Eigenheiten von FireBird bei der Auswertung der Datentypen und der Klammersetzung geachtet werden.

[arnof]

gerundet werden nur die Endsummen und nicht einzelne Artikel

Summe von allem:

bei Preisen ohne MwSt

Netto=Round(Netto,2)
brutto=Round(Netto*1.19,2)

MwSt=Brutto-Netto


bei Preisen incl. MwSt

brutto=Round(Brutto,2)
Netto=Round(Brutto/1.19,2)

MwSt=Brutto-Netto