Buchhaltung - Rundungen

[Olli73]

Mal von dem eigentlichen Problem abgesehen: Was hat eigentlich die Mehrwertsteuer in der Kostenrechnung zu suchen?

[Phoenix]

Das Problem tritt ja grundsätzlich nur bei der Steuer auf (die einzelnen Preise müssen ja immer den korrekten Wert ergeben).

Es gibt da zwei Möglichkeiten:
1.) Die Steuer nicht als Betrag, sondern als Merkmal übergeben (-> 20%, oder 19%, oder 7,5% etc.). Damit ist die Buchhaltung in der Pflicht, die Steuer selber zu berechnen.

2.) Beim Export nimmst Du die Einzelposten, rechnest pro Posten die Steuer aus, und merkst sie Dir im Programm mit *allen* Nachkommastellen.
Du rundest und exportierst erst jetzt die Summe der ungerundeten Steuerbeträge (sollte die Buchhalterisch richtige Summe ergeben).

Damit hast Du auch eine Kontrollmöglichkeit: Du kannst das nochmal nachprüfen in dem Du die Steuer nochmal auf die Gesamtsumme berechnest - das müsste dem Wert dann entsprechen. Achtung: Das funktioniert nur solange, wie Du einen einheitlichen Steuersatz hast. In DE mit Einzelposten mit dem verminderten Umsatsteuertsatz klappt das z.B. nicht.

[arnof]

Zitat:

Zitat von Olli73 (Beitrag 1225316)

Mal von dem eigentlichen Problem abgesehen: Was hat eigentlich die Mehrwertsteuer in der Kostenrechnung zu suchen?

Wenn er (von was auch immer ) was in die Buchhaltung automatisch bringen will und es aufteilen will z.B. für die Kostenrechnung, so muss er die Buchung splitten, sonst kriegt man das da nicht rein. Deshalb muss er das von einer Buchung in zwei aufteilen und dann schlägt das Rundungsproblem zu, da 2 mal gerundet nicht einmal gerundet sind und ein cent dann die Rundungsdifferenz ist!

[sx2008]

Man müsste die Rundungsdifferenzen auffangen und dann die Teilbeträge korrigieren.
Dann sind die Teilbeträge zwar nicht mehr genau kaufmänisch gerundet aber die Summe der Teilbeträge ergibt wieder den Gesamtbetrag.
Das ist nicht so einfach aber ich denke es lohnt sich hier eine Klasse zu bauen denn das Problem gibt es bei allen Rechnungen bei denen Teilbeträge aus Prozentrechnung entstehen.

[Olli73]

Zitat:

Zitat von arnof (Beitrag 1225318)

Zitat:

Zitat von Olli73 (Beitrag 1225316)

Mal von dem eigentlichen Problem abgesehen: Was hat eigentlich die Mehrwertsteuer in der Kostenrechnung zu suchen?

Wenn er (von was auch immer ) was in die Buchhaltung automatisch bringen will und es aufteilen will z.B. für die Kostenrechnung, so muss er die Buchung splitten, sonst kriegt man das da nicht rein. Deshalb muss er das von einer Buchung in zwei aufteilen und dann schlägt das Rundungsproblem zu, da 2 mal gerundet nicht einmal gerundet sind und ein cent dann die Rundungsdifferenz ist!

Das ist mir schon klar. Meine Frage bezog ich darauf, dass hier wohl die Schnittstelle nicht optimal ausgelegt ist: Eine Aufteilung auf Kostenstellen macht nur Sinn, wenn es sich um Kosten handelt; da gehören weder Umsatzsteuer noch Anschaffung von Anlagevermögen u.Ä. rein. Natürlich geht das nur, wenn es die Schnittstelle erlaubt, lediglich Aufwand/Kosten (Nettobetrag) zu verteilen.

[Blup]

Da der Mehrwertsteuerbetrag scheinbar auf den Rechnungsbetrag(je Mwst.) berechnet wird,
sollte auch die Buchung in vergleichbarer Form erfolgen.

Code:

Soll            Haben           Steuersatz      KST     Betrag
Debitor         Zwischenkonto   20%                     Rechnungs(teil)betrag 20%
Zwischenkonto   Erlöskonto1     -               Kst1    Nettoteilbetrag1
Zwischenkonto   Erlöskonto2     -               Kst2    Nettoteilbetrag2
Debitor         Zwischenkonto   10%                     Rechnungs(teil)betrag 10%
Zwischenkonto   Erlöskonto3     -               Kst3    Nettoteilbetrag3
Zwischenkonto   Erlöskonto4     -               Kst4    Nettoteilbetrag4
usw.

[arnof]

:thumb:

[MeierZwoo]

Was hat die MWSt in den Kostenstellen zu suchen? Die MWst ist ein eigenes KTO, die KST bekommen eh nur Nettowerte. D.h. bei der Buchung werden Nettowert und Vorsteuer eh schon getrennt gebucht und dort müssen, wenn dies mit Abschlagsverfahren gerechnet wird, auf den RN-Betrag angepaßt werden. Dann wird der Netto-Betrag auf die KST verteilt.

Rundungsfehler können eh nur entstehen, wenn statt der Einzelbuchung Netto und Vorsteuer im Abschlagsverfahren gebucht wird, was grundsätzlich falsch ist und seit zig Jehren überholt. Außerdem gibt man keine Gleitkommawerte in der Buchhaltung ein, sondern nur Integerwerte, die nur in der Anzeige und Ausdruck ein Komma (und Dezimalpunkt) spendiert bekommen. Eine Schnittstelle, die Gleitkommawerte erwartet, kannst Du getrost in die Tonne hauen.

[Furtbichler]

Vor ettlichen Jahren hatte ich mal ein ähnliches Problem und habe einfach gegoogelt. Danach gibt es eine -in Deutschland- verbindliche Vorgehensweise bei der Berechnung Netto/Brutto, die auch die bekannten Rundungsdifferenzen erschlägt. Das Finanzamt/Buchhaltung ist ja nicht nur blöd.

Soweit ich mich erinnere, wird stinknormal gerundet, und zwar auf den nächstgelegenen Centbetrag. Die Bruttosumme wird also gerundet und zur Anzeige der MwSt-Steuer Netto von Brutto abgezogen.

Peitscht mich, wenn ich mich irre, aber ich bin mir 100% sicher, das das eindeutig geregelt ist. Auch in anderen Ländern.

[MeierZwoo]

Zitat:

Zitat von Furtbichler (Beitrag 1225395)

Soweit ich mich erinnere, wird stinknormal gerundet, und zwar auf den nächstgelegenen Centbetrag. Die Bruttosumme wird also gerundet und zur Anzeige der MwSt-Steuer Netto von Brutto abgezogen.

Das gilr für das Erstellen von Rechnungen.

Hier wird aber das "Problem" buchen von eingehenden (Dritt)Rechnungen behandelt, in denen Netto, MWst und Brutto ja ausgewiesen sind und vom Ersteller der Rechnung bereits gerundet wurden.

Diese Werte nocheinmal im Ab- oder Aufschlagsverfahren neu zu berechnen ist schon schlichtwegs falsch!

Bei einem meiner Kunden tritt so ein Fall auch immer wieder auf: Einer dessen Kunden überweist ständig einen Cent mehr, als in den Rechnungen ausgewiesen ist, weil die dort wohl auch nicht Netto und MWSt als Beträge buchen sondern neu berechnen.

Und da es dabei nicht nur auf den CPU/CoCPU-Typ (FPU) ankommt, sondern auch auf dessen Settings und auf die von deren Programm intern verwendeten Typen oder gar Software-Rundungsalgorithmen wird es nie zu einer Übereinstimmung kommen. Ist auch garnicht nötig, wenn man korrekt bucht.

Es wird nicht die selbst errechnete MWSt als Vorsteuer gebucht, sondern die in der Rechnung ausgewiesene und vom Rechnunsgsteller als MWSt abgeführte.

Nur bei groben Schnitzern wird neu berechnet und dann "Bitte buchen Sie gleichlautend ..." ein entspr. Schriftverkehr eingeleitet. Dieses bei jedem Rundungs-Cent zu tun, wäre wohl etwas overdressed.

Und Buchhaltungs-Soft oder Schnittstellen, die nicht die ausgewiesenen Netto- und MWSt-Beträge buchen/übertragen kann, sondern unbedingt neu berechnen will, gehört einfach in die Tonne!