Tücken bei der Mehrwertsteuerberechnung (mit Firebird)

[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

[BlueStarHH]

Zitat von arnof:

gerundet werden nur die Endsummen und nicht einzelne Artikel

Ja, das mache ich auch nur.

Zitat von arnof:

bei Preisen incl. MwSt

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

MwSt=Brutto-Netto

Genau die Formel ist falsch (nicht bezogen auf die Rundung) sagt mein StB und mehere Quellen. Ich hänge die mal an. Hast Du Quellen für Deine Formel?

Es muss ein "Multiplikator für das Herausrechnen der Umsatzsteuer" benutzt werden.

[Sherlock]

Brutto zu Netto = Brutto / 1,19
Netto zu Brutto = Netto * 1,19

Quelle und darin Herleitung sowie weiterführende Quellen und Referenzen: https://www.blitzrechner.de/mehrwert...rechnen/#falle

[BlueStarHH]

Zitat von Sherlock:

Brutto zu Netto = Brutto / 1,19
Netto zu Brutto = Netto * 1,19

Quelle und darin Herleitung sowie weiterführende Quellen und Referenzen: https://www.blitzrechner.de/mehrwert...rechnen/#falle

Glaubst Du blitzrechner.de oder eher den "Finanzämtern Baden-Württemberg":
https://finanzamt-bw.fv-bwl.de/,Lde/...uer+berechnet_
und meine andere Quelle (siehe PDF oben, ein Wirtschaftsprüfer)

Diskussion mit dem Prüfer vom Finanzamt: "Ja, aber auf blitzrechner.de stand, dass ich das so machen soll/kann."

Die Artikel von blitzrechner.de und co. werden in der Regel von Copywritern verfasst, die gut im Marketing sind und Texte über alles mögliche schreiben.

[gubbe]

Zitat von BlueStarHH:

Glaubst Du blitzrechner.de oder eher den "Finanzämtern Baden-Württemberg":
https://finanzamt-bw.fv-bwl.de/,Lde/...uer+berechnet_
und meine andere Quelle (siehe PDF oben, ein Wirtschaftsprüfer)

Diskussion mit dem Prüfer vom Finanzamt: "Ja, aber auf blitzrechner.de stand, dass ich das so machen soll/kann."

Die Artikel von blitzrechner.de und co. werden in der Regel von Copywritern verfasst, die gut im Marketing sind und Texte über alles mögliche schreiben.

Da musste ich jetzt echt lachen.

Finanzämtern und Steuerberatern glaube ich gar nichts, sondern rechne lieber selbst nach.
Und warum sollte ich jemandem glauben, der mit einem gerundeten Faktor rechnet?

Zitiert aus Deinem zweiten Dokument:

Zitat:

Beispiel für die Berechnung der Bemessungsgrundlage
Ein kleines Beispiel soll dies erläutern:
Einnahmen eines Vereins aus einer kulturellen Veranstaltung: 7.850,00 Euro (Bruttobetrag)
Umsatzsteuer (ermäßigter Umsatzsteuersatz) über Multiplikator, hier 6,54% (7.850 Euro x 6,54%) = 513,39 Euro
Nettoentgelt (Bemessungsgrundlage) = 7.850 - 513,39 = 7.336,61 Euro

7/107 ergeben gerundet (!) 6,54%. Mit diesem Faktor macht man es erst richtig falsch.
Zurückgerechnet 7.336,61 + 7% MwSt. = 7.850,17
Ohje, 17 Cent Unterschied.

Also das taugt wohl kaum als Begründung, warum die Berechnung mit der "Multiplikation" besser ist.

Brutto - (Brutto/1,19) und Brutto * 19/119 sind äquivalent, kannst Du ineinander umrechnen, schöne Übung, wenn die Mathekenntnisse schon länger her sind
Letzteres ist nur etwas einfacher zu rechnen, z.B. mit dem Taschenrechner, weil man den Bruttobetrag nur einmal eingeben muss.

Zitat:

Ich denke wir als Softwareentwicker können und sollten das nicht entscheiden, welche Formel verwendet werden solle.

Gerade wir sollten das entscheiden oder was hat uns ein Steuerberater mit seinem Halbwissen hier voraus?
Und auch wenn es mathematisch keinen Unterschied macht, kann es bei der konkreten Umsetzung bei der Softwareentwicklung durchaus Unterschiede geben, wie man auch an der Berechnung in der Datenbank gesehen hat.

[t2000]

Die Rechnerei ist doch alles kompletter Blödsinn.
Solange man "richtig" rechnet, sind beide Verfahren identisch. (* 0,15966... zu /1,19*0,19)
Wenn aber zwischendurch gerundet wird, ist es immer unterschiedlich.
Das bedeutet, wenn mit 0,1597 gerechnet wird ist das natürlich ganz anders als bei 0,1596638...

In den "hier geposteten" Texten steht 15,97 (= 19/119). Das ist ja nicht ganz in Ordnung. Soll man mit 15,97 rechnen oder mit 19/119 ??
Im zweiten Fall sind alle Ergebniss gleich als wenn man geteilt durch 1,19 rechnen würde.

Ich hatte schon Fälle, da haben die Prüfer auf Endsummen in Rechnungen geschaut und damit gerechnet. Im Fall von 15,97 bei den Einzelpositionen hätte das vermutlich mächtig Ärger gegeben.

[BlueStarHH]

Zitat von t2000:

Die Rechnerei ist doch alles kompletter Blödsinn.
Solange man "richtig" rechnet, sind beide Verfahren identisch. (* 0,15966... zu /1,19*0,19)

Nein, sind sie eben nicht. Ich habe beides über tausende reale Rechnungen laufen lassen und es gibt Unterschiede von +/-1 Cent. Das summiert sich auf.

Auch mein Steuerberater sagt, rechne mit dem Multiplikator, wie es in dem Dokument vom den "Finanzämtern Baden-Württemberg" steht. Fragt doch mal euren Steuerberater, was der dazu sagt. Ich denke wir als Softwareentwicker können und sollten das nicht entscheiden, welche Formel verwendet werden solle. Die Frage hier ist ja, warum kommt mit einer von zwei Formeln das falsche Ergebnis raus.

[Delphi.Narium]

Das Problem liegt nicht in den Rechenverfahren sondern in der Datenbank bzw. in FireBird:

SQL-Code:

select
  RENR,
  MWSTSATZ,
  cast(round(BruttoSumme, 2) as NUMERIC(18,2)) as Brutto,
  (MwStSatz / (MwStSatz + 100)) as mwst_1,
  round((MwStSatz / (MwStSatz + 100)),2) as mwst_2,
  BruttoSumme * (MwStSatz / (MwStSatz + 100)) as mwst_3,
  BruttoSumme * MwStSatz / (MwStSatz + 100) as mwst_4,
  round(BruttoSumme * MwStSatz / (MwStSatz + 100),2) as mwst_5,
  cast(round(round(BruttoSumme, 2) * (MwStSatz / (MwStSatz + 100)), 2) as NUMERIC(18,2)) as Mwst,
  cast(round(round(BruttoSumme, 2) * MwStSatz / (MwStSatz + 100), 2) as NUMERIC(18,2)) as Mwst_Cast,  
  cast(round(BruttoSumme, 2) - (round(round(BruttoSumme, 2) * (MwStSatz / (MwStSatz + 100)), 2)) as NUMERIC(18,2)) as Netto
from
(
  select
    RENR,
    MwStSatz,
    sum(BruttoSumme) as BruttoSumme
  from RePos
  group by RENR, MwStSatz
)
;

Habe mal eine der Views "erweitert" und dann die Ergebnisse verglichen.

Mathematisch sind

  cast(round(round(BruttoSumme, 2) * (MwStSatz / (MwStSatz + 100)), 2) as NUMERIC(18,2)) as Mwst,
und
  cast(round(round(BruttoSumme, 2) * MwStSatz / (MwStSatz + 100), 2) as NUMERIC(18,2)) as Mwst_Cast,
identisch.

Die Klammerung von (MwStSatz / (MwStSatz + 100)) ist nicht zwingend erforderlich, es würde auch MwStSatz / (MwStSatz + 100) ausreichen.

Das Problem dabei ist: FireBird liefert mit bzw. ohne diese Klammern unterschiedliche Ergebnisse.

Bei FireBird ist BruttoSumme * (MwStSatz / (MwStSatz + 100)) was anderes als BruttoSumme * MwStSatz / (MwStSatz + 100) .

Aus für mich nicht nachvollziehbaren Gründen ist der Ergebnis der Berechnung BruttoSumme * (MwStSatz / (MwStSatz + 100)) bei FireBird falsch.

[gubbe]

Zitat von Delphi.Narium:

Die Klammerung von (MwStSatz / (MwStSatz + 100)) ist nicht zwingend erforderlich, es würde auch MwStSatz / (MwStSatz + 100) ausreichen.

Das Problem dabei ist: FireBird liefert mit bzw. ohne diese Klammern unterschiedliche Ergebnisse.

Bei FireBird ist BruttoSumme * (MwStSatz / (MwStSatz + 100)) was anderes als BruttoSumme * MwStSatz / (MwStSatz + 100) .

Aus für mich nicht nachvollziehbaren Gründen ist der Ergebnis der Berechnung BruttoSumme * (MwStSatz / (MwStSatz + 100)) bei FireBird falsch.

Rein intuitiv hätte ich auch die Klammern weggelassen. Wenn ich erst dividiere rechne ich mit einem möglicherweise ungenauen Wert weiter, denn ich verliere Nachkommastellen je nach Datentyp. Die brauche ich aber bei den hohen Werten im Beispiel.
Multipliziere ich erst mit 19 und Teile dann durch 119, habe ich wenigstens im ersten Schritt einen genauen Werte und das zweite Ergebnis runde ich dann sowieso.

Also das ist letztlich genau das gleiche Problem wie in dem Beispiel des Steuerberaters, der mit einem gerundeten Faktor ungenau rechnet. Nur eben mit ein paar Nachkommastellen mehr.

[Uwe Raabe]

23.940.000,00/150.000.000,00 ergibt exakt 0,1596. Das ist (19/119) nach 4 Nachkommastellen abgeschnitten. Das kann natürlich kein korrektes Ergebnis liefern.

Zitat von BlueStarHH:

Zitat von Olli73:

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

Genau das möchte man ja nicht machen, wenn man mit Geld-Beträgen arbeitet. Deswegen ja numeric, damit keine Genauigkeit verlorgen geht, da intern mit Integern gerechnet wird.

Offenbar verwendet FireBird bei den Zwischenergebnissen gerundete oder abgeschnittene Werte. Deswegen ist der Hinweis auf den float-Cast vielleicht doch nicht so abwegig.

Die Formel Brutto*(MWStSatz/(MWStSatz + 100) muss schon ohne Rundung der Zwischenergebnisse durchgeführt werden. Wenn Zwischenergebnisse gerundet werden sollen, dann wird das in der Regel auch so beschrieben. Andernfalls muss man mit der erforderlichen Genauigkeit rechnen, zwar mit den eingegebenen Integer- bzw. Round(x,2)-Werten aber nicht gerundeten Zwischenwerten.

Ich zitiere hier mal aus dem offiziellen Programmablaufplan für die Einkommensteuerberechnung:

Zitat:

Bei der Steuerberechnung werden Gleitkommafelder verwendet.