Rundungsfehler

[Sven Hansen]

Hi NG,

gibt es eine Vorschrift wie bei FiBu-Programmen gerundet werden muss oder
was als Abweichung erlaubt ist?

Darf ein FiBu-Programm (wie man es mit der Hand machen würde) jeden
Buchungssatz runden, buchen und dann addieren/saldieren?

Das Problem ist (1), wenn ich intern bei jeder Buchung mit Fließkommazahlen
arbeite, stimmen die Salden der Konten nicht mehr genau mit der Summe der
Teilbeträge in den Kontenblättern überein (2), wenn ich jede Buchungs runde
stimmen zwar die Salden, aber die Summen der Umsatzsteuer haben eine
Abweichung von ca. bis zu 0,06%. Also statt 19% USt der Nettosumme bekomme
ich z. B. nur 18,94%.

Kann mir jemand etwas dazu sagen?

Dank im Voraus.

Lieben Gruß
Sven

[Matthias Hanft]

Post by Sven Hansen
Das Problem ist (1), wenn ich intern bei jeder Buchung mit Fließkommazahlen
arbeite, stimmen die Salden der Konten nicht mehr genau mit der Summe der
Teilbeträge in den Kontenblättern überein (2), wenn ich jede Buchungs runde
stimmen zwar die Salden, aber die Summen der Umsatzsteuer haben eine
Abweichung von ca. bis zu 0,06%. Also statt 19% USt der Nettosumme bekomme
ich z. B. nur 18,94%.

Die gängigen Fibu-Softwaren wenden jedenfalls Lösung (2) an. Werden
schon einen Grund dafür haben :-)

Umsatzsteuer stimmt am Jahresende sowieso nie ganz. Selbst wenn man
100% exakt rechnen würde, bliebe trotzdem etwas übrig, da man in der
USt-Erklärung nur volle EUR-Beträge einträgt und man daher eh bis zu
19 Cent (19% von 99 Cent, die untern Tisch fallen) ausbuchen muß.

Und der Rest, unter den vermutlich auch Deine 0,06% fallen, mittelt
sich i.d.R. übers Jahr gesehen (wenn man nicht extra Dinge tut, die
das verhindern, wie z.B. zwischen 1999 und 2001 millionenfach einen
Pfennig zwischen zwei Bankkonten zu überweisen, der dann als ein
Cent ankommt).

Mehr als ca. 37 Cent Differenz in der Umsatzsteuerverprobung ist mir
in den letzten zwanzig Jahren jedenfalls nie passiert...

Gruß Matthias.

[Sven Hansen]

Hi Matthias,

Post by Matthias Hanft
Die gängigen Fibu-Softwaren wenden jedenfalls Lösung (2) an. Werden
schon einen Grund dafür haben :-)

Da fällt mir ein Stein vom Herzen. Ich hatte schon gedacht ich müsste da
soetwas rundherum programmieren:

Aus
http://de.wikipedia.org/wiki/Rundung

Summenerhaltendes Runden:
Beim summenerhaltenden Runden werden die Teilbeträge so gerundet, dass die
Summe der gerundeten Teilbeträge der Summe der ursprünglichen Beträge
entspricht. Dieser Ansatz ist beispielsweise notwendig, wenn auf einer
Rechnung zu jedem Posten einzeln die Mehrwertsteuerbeträge aufgeführt sind.
Da die Summe der gerundeten Steuerbeträge der Einzelposten der
Mehrwertsteuer aus der Summe der Nettobeträge entsprechen soll ist hier
summenerhaltendes Runden zwingend notwendig.

Eine Mögliche Umsetzung ist das Mitführen des kumulierten Rundungsfehlers:
Beim Runden der ersten Zahl entsteht ein Rundungsfehler. Der Rundungsfehler
wird vor dem Runden der zweiten Zahl zu dieser addiert. Der neue
Rundungsfehler ist dann die Differenz dieser Summe zu ihrem gerundeten Wert.
Dieses Verfahren setzt man fort bis zur letzten Zahl. Der kumulierte Fehler
liegt dabei immer im Interval ] ? 0,5..0,5[. Das Verfahren ist einfach, aber
statistisch betrachtet nicht optimal, da die erste Zahl anders behandelt
wird als die Folgenden. Andere Ansätze benutzen eine quadratische
Ausgleichsrechnung um den Rundungsfehler auf die Teilbeträge zu verteilen.


Danke

Gruß
Sven

[Martin Schoenbeck]

Hallo Sven,

Post by Sven Hansen
Beim Runden der ersten Zahl entsteht ein Rundungsfehler. Der Rundungsfehler
wird vor dem Runden der zweiten Zahl zu dieser addiert. Der neue
Rundungsfehler ist dann die Differenz dieser Summe zu ihrem gerundeten Wert.
Dieses Verfahren setzt man fort bis zur letzten Zahl. Der kumulierte Fehler
liegt dabei immer im Interval ] ? 0,5..0,5[. Das Verfahren ist einfach, aber
statistisch betrachtet nicht optimal, da die erste Zahl anders behandelt
wird als die Folgenden.

Wenn Du Zollabrechnungen nachvollziehen willst, dann mußt an bestimmten
Stellen das genauso implementieren. ;-)

Gruß Martin

[Martin Schoenbeck]

Hallo Sven,

Post by Sven Hansen
Beim Runden der ersten Zahl entsteht ein Rundungsfehler. Der Rundungsfehler
wird vor dem Runden der zweiten Zahl zu dieser addiert. Der neue
Rundungsfehler ist dann die Differenz dieser Summe zu ihrem gerundeten Wert.
Dieses Verfahren setzt man fort bis zur letzten Zahl. Der kumulierte Fehler
liegt dabei immer im Interval ] ? 0,5..0,5[. Das Verfahren ist einfach, aber
statistisch betrachtet nicht optimal, da die erste Zahl anders behandelt
wird als die Folgenden.

Wenn Du Zollabrechnungen nachvollziehen willst, dann mußt an bestimmten
Stellen das genau so implementieren. ;-)

Gruß Martin

[Ron Baker]

Post by Sven Hansen
Hi NG,
gibt es eine Vorschrift wie bei FiBu-Programmen gerundet werden muss oder
was als Abweichung erlaubt ist?

Es gibt mathematische Regeln, die haben wir shcon in der Schule gelernt,
oder?
Hier ein Beispiel:
0,049 ist gleich 0,05
0,044 ist gleich 0,04

Noch Fragen?

ŽRon

[Sven Hansen]

Post by Ron Baker

Post by Sven Hansen
Hi NG,
gibt es eine Vorschrift wie bei FiBu-Programmen gerundet werden muss
oder was als Abweichung erlaubt ist?

Es gibt mathematische Regeln, die haben wir shcon in der Schule
gelernt, oder?
0,049 ist gleich 0,05
0,044 ist gleich 0,04
Noch Fragen?

Hi Ron,

es ging mir eher um:

1. 2.
Tatsächliche Werte: Gerundetet Werte:
5,599 5,60
5,457 5,46
Summe1 gerundet: Summe2:
11,06 11,06

Beide Rechnungen haben in diesem Fall dasselbe Ergebnis. Im 1. Fall wurde
erst hinterher gerundet im 2. sofort und dann, falls nötig, zum Schluss noch
einmal.
Das Problem taucht auch nur bei umsatz- und vorsteuerrelavanten Konten auf,
da diese Werte berechnet werden. Recherisch besser ist 1. aber es hat einige
unangenehme Seiteneffekte deshalb würde ich 2. vorziehen.

Danke und Gruß
Sven

[Martin]

"Sven Hansen" schrieb im Newsbeitrag

Post by Sven Hansen
Das Problem taucht auch nur bei umsatz- und vorsteuerrelavanten Konten auf,
da diese Werte berechnet werden. Recherisch besser ist 1. aber es hat einige
unangenehme Seiteneffekte deshalb würde ich 2. vorziehen.

Buche exakt den Betrag, der auf der Rechnung angedruckt ist.
Dann gibt es keine Abweichungen oder "Schneideffekte"

[Rüdiger Silberer]

Post by Martin
"Sven Hansen" schrieb im Newsbeitrag

Post by Sven Hansen
Das Problem taucht auch nur bei umsatz- und vorsteuerrelavanten Konten auf,
da diese Werte berechnet werden. Recherisch besser ist 1. aber es hat einige
unangenehme Seiteneffekte deshalb würde ich 2. vorziehen.

Buche exakt den Betrag, der auf der Rechnung angedruckt ist.
Dann gibt es keine Abweichungen oder "Schneideffekte"

Es gibt aber auch Beleg auf denen keine Mehrwertsteuer ausgewiesen ist.

[Martin]

"Sven Hansen" schrieb im Newsbeitrag

Post by Sven Hansen
gibt es eine Vorschrift wie bei FiBu-Programmen gerundet werden muss oder
was als Abweichung erlaubt ist?

Im Prinzip gilt, daß die Summe der Einzelzeilen des Kontenblattes exakt
der angedruckten Summe entsprechen muß.

BSP: 0,33 + 0,33 + 0,33 = 0,99 und nicht 1,00 (= 3* 1/3)

Post by Sven Hansen
Darf ein FiBu-Programm (wie man es mit der Hand machen würde) jeden
Buchungssatz runden, buchen und dann addieren/saldieren?

Es muß exakt das gebucht werden, was auch angedruckt wird.
d.H. Wenn Du zwei Nachkommastellen druckst, sollte auch Intern
rechtzeitig vor dem Buchen gerundet worden sein.

Post by Sven Hansen
Das Problem ist (1), wenn ich intern bei jeder Buchung mit
Fließkommazahlen
arbeite, stimmen die Salden der Konten nicht mehr genau mit der Summe der
Teilbeträge in den Kontenblättern überein

-> Wenn Du jetzt manuell eine Umbuchung tätigst, landest Du im Wald,
und am Schluß weicht Aktiv- und Passiv in der Bilanz um 2 Cent ab...

Post by Sven Hansen
(2), wenn ich jede Buchungs runde
stimmen zwar die Salden, aber die Summen der Umsatzsteuer haben eine
Abweichung von ca. bis zu 0,06%. Also statt 19% USt der Nettosumme
bekomme ich z. B. nur 18,94%.

Hinweis: Du mußt genau den UST- Betrag buchen, der auf der Rechnung
angedruckt ist, darfst aber max 19% Vst ziehen. Wenn die UST 3- stellig
gedruckt wäre, würde ich kein Problem sehen...

Notfalls kannst Du die Einzelbeträge Deiner Einnahmen vor der UST- Be-
rechnung addieren, um anschließend die UST der Summe mit 19% zu buchen
(Macht nur bei sehr vielen Kleinstbeträgen ohne Rechnung wirklich Sinn.)

[Martin Schoenbeck]

Hallo Martin,

Martin schrieb:
^^^^^^ könntest Du da noch Deinen vollen Namen eintragen?

Post by Martin
-> Wenn Du jetzt manuell eine Umbuchung tätigst, landest Du im Wald,
und am Schluß weicht Aktiv- und Passiv in der Bilanz um 2 Cent ab...

Das ist nun einmal bei allen Gewinnen und Verlusten so. Auch bei
Rundungsgewinnen oder -verlusten. Ok, in den anderen Fällen sind es
hoffentlich mehr als 2 Cent.

Post by Martin
Notfalls kannst Du die Einzelbeträge Deiner Einnahmen vor der UST- Be-
rechnung addieren, um anschließend die UST der Summe mit 19% zu buchen
(Macht nur bei sehr vielen Kleinstbeträgen ohne Rechnung wirklich Sinn.)

Man kann sich auch einen Knopf an die Backe nähen, und drehen bis UKW
kommt. Nein, im Ernst, niemand macht das so. Bei der Anmeldung wird's dann
natürlich so gerechnet und dann gibt's eben eine Differenz zwischen dem
entsprechenden Konto und der Anmeldung. Das gleicht man dann beim
Jahresabschluß aus.

Gruß Martin