Buchhaltung - Rundungen

[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 von Furtbichler:

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!

[Furtbichler]

Zitat von MeierZwoo:

Das gilt für das Erstellen von Rechnungen...

Möglich (bzw. sehr wahrscheinlich ) wir haben dann diese Beträge in der DB gespeichert (logischerweise) und 1:1 an die Buchhaltungssoftware übertragen.

Zitat:

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

Damit sollte klar sein, wie es geht und warum.

[MeierZwoo]

Zum Ab/Aufrunden und Vorschriften/Gesetzen/Verordnungen dazu:

Es ist dem FA u.a. ziemlich egal, ob man kaufmännisch oder mathematisch rundet, sich also über 1/10 Cent Rundung un damit über +/- 1 bis 3 Cent pro Rechnung Gedanken macht (theoretisch bis 3 Cent bei bis drei MWSt-Arten in den verschiedenen Ländern).

Denn wenn der Kreditor 1 Cent weniger MWSt ausweist, kann der Debitor auch nur 1 Cent weniger Vorsteuer geltend machen - und umgekehrt.

Und wenn die Fälle auftreten, daß der Debitor die MWSt neu mit Rundungsdifferenz berechnet und überweist (+/- 1 bis 3 Cent), wird dies eben als Skonto oder Differenz verbucht, damit das RN-Soll augeglichen ist.

Die einzige Vorschrift über runden, die es gegeben hat, war in dem Zeitraum, als es den EUR schon als Buchgeld gab aber die nationalen Währungen der am EUR teilnehmenden Länder noch ges. Zahlungsmittel waren - also in diesen drei Jahren des Übergangs, als es zwischen den teilnehmenden Länderwährungen und dem EUR einen festen Umrechnungsfaktor gab (NICHT KURS, darauf wurde extra hingewiesen, daß dies ein FAKTOR war). Damals war vorgeschrieben, daß wenn von einer nationalen, teilnehmenden Währung zu einer anderen nationalen, teilnehmenden Währung umgerechnet wurde nicht direkt mit den zwei Faktoren umgerechnet werden durfte (und einmal gerundet), sondern die eine Währung erst mit deren Faktor in EUR incl. Rundung umgerechnet werden mußte, dann diese gerundeten EUR mit dem zweiten Faktor in die andere Währung, wieder mit Rundung. Das war mehr eine juristische Spitzfindigkeit denn eine sinnvolle Vorgabe, weil es rein juristisch zwischen zwei nationalen Währungen ja keinen Umrechnunsgfaktor gab - immer nur jeweils von nationaler Währung zum EUR.

Ansonsten gibt es (zumindest in D) nur noch die KANN-Vorgabe, daß Endsummen von Steuererklärungen pro Erklärungsart auf ganze EUR ABgerundet werden dürfen.

Und ein Programmmierer hat sich darüber eh nur Gedanken zu machen, als er den Vorgaben der Fachleute zu folgen und diese umzusetzen hat - eigene Entscheidungen an den Prinzipien der Buchhaltung vorbei sind eh nicht zulässig!

[ralfschwalbe]

Wir haben in unserem Programm mehrere Finanzbuchhaltungen angebunden...

Da gibt es wirklich riesige Unterschiede! Von "die FiBu rechnet selbst" bis hin zu "ich muss alles aufsplitten und selber richtig rechnen". Im letzteren Fall buchen wir die Rundungsdifferenzen automatisch auf ein steuerfreies Konto in der FiBu. Da die Differenzen mal positiv und mal negativ sein können, hat man am Ende des Abrechnungszeitraumes immer nur wenige Cent auf diesem Konto. Und die dürfen dann gern (auch wenn später mal geprüft wird) vernachlässigt werden.

[arnof]

Zitat von ralfschwalbe:

Wir haben in unserem Programm mehrere Finanzbuchhaltungen angebunden...

Da gibt es wirklich riesige Unterschiede! Von "die FiBu rechnet selbst" bis hin zu "ich muss alles aufsplitten und selber richtig rechnen". Im letzteren Fall buchen wir die Rundungsdifferenzen automatisch auf ein steuerfreies Konto in der FiBu. Da die Differenzen mal positiv und mal negativ sein können, hat man am Ende des Abrechnungszeitraumes immer nur wenige Cent auf diesem Konto. Und die dürfen dann gern (auch wenn später mal geprüft wird) vernachlässigt werden.

Mal abgesehen, das normale fragen hier anscheinend immer zu Grundsatzdiskussion Führen, die der Antwort nicht näher kommen, ist deine Antwort die Lösung für die Ursprüngliche Frage

[MeierZwoo]

Zitat von ralfschwalbe:

hat man am Ende des Abrechnungszeitraumes immer nur wenige Cent auf diesem Konto. Und die dürfen dann gern (auch wenn später mal geprüft wird) vernachlässigt werden.

Vernachlässigt werden darf in der Buchhaltung kein einziger Cent! Alle Einzelzeilen und alle Summenzeilen müssen immer Summe=0 haben.

Und ein Differenz-KTO ist normal, hatte ich oben (bei RN) als Skonto oder allgemein als Differenz angeführt.

Nur ist es ein ganz normales KTO, welches in die Bilanzsumme eingeht! Und eben NICHT vernachlässigt wird, sonst würde die Salden-Prüfung Fehler auswerfen.

Denn was einige Leute nicht bedenken, wenn ein klassischer Buchhalter bei einer Salden-Differenz von einem Pfennig auch tagelang nach dem Fehler sucht: ein Pfennig Salden-Differenz kann auch aus mehreren fehlerhaften Buchungen mit großen Beträgen entstanden sein.