Hallo Fakturama Team,
nach wie vor leistet Ihr hier eine tolle Arbeit.
Ich weiss, dass die Mehrwertsteuer in Ausnahmefällen falsch gerundet werden kann und dass das wohl nie ganz abgestellt werden kann.
Es muss sich aber wieder etwas geändert haben: Ich habe heute eine Rechnung geschrieben, wo die Summe falsch berechnet wurde.
Im Angebot und in der Auftragsbestätigung ein - paar Tage - zuvor ( noch mit Fakturama V 2.1.1b erstellt) war folgendes gestanden:
Produkt (netto) : 439,50
Versand (netto): 31,20
MwSt: 89,43
Summe: 560,13
Heute habe ich mit Fakturama V2.1.2 die Rechnung erstellt und hatte folgende Werte:
Produkt (netto) : 439,50
Versand (netto): 31,20
MwSt: 89,43
Summe: 560,14
Also Auftragsbestätigung und Rechnung unterscheiden sich um 1 Cent, wobei die Rechnung in V2.1.2 meiner Ansicht nach falsch gerechnet hat. Alles andere ist gleich geblieben.
Auch wenn ich z.B. ein neues Angebot mit den obigen Daten erstelle (egal, ob in Linux oder Windows) komme ich auf die falsche Summe.
Ich habe jetzt vorerst wieder die Version 2.1.1b installiert.
Vielleicht hilft mein Beitrag den Fehler zu finden.
Gruß
Stephan
Hallo Stephan, ich hab an der Stelle tatsächlich was gemacht, weil mich die Rundungsfehler selber auch stören. Dazu habe ich dann eigentlich auch ziemlich viele Tests gemacht, wo das alles gepaßt hat. Ich hab mir das jetzt mal angesehen. Die Ursache liegt daran, daß ich nach den einzelnen Zwischenschritten runde und die Gesamtsumme aus den gerundeten Werten ermittle. Also:
439,50€ + 19% = 523,005€
31,20€ + 19% = 37,128€
Rechnet man die ungerundeten Beträge zusammen, kommt man auf 560,133€, bei den gerundeten sind es 560,14€. Ich muß mal sehen, wie man das am besten geradebiegen kann. Es gab glaube ich irgendwo eine Vorschrift, nach der man nach den Zwischenschritten runden soll. Muß mal schauen, ob ich das wiederfinde.
Alternativ wäre ich auch für eine verbindliche Vorschrift offen...
Anbei mal der Stand, den ich gerade mal als Arbeitsversion hätte...
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?
Hallo Ralf,
danke für Deine Antwort. Es ist auf jeden Fall eine undankbare Aufgabe und ich bin froh, dass Du Dich darum kümmerst.
Ich glaube, das Problem wird immer mal wieder auftauchen, wenn man mehrere gerundete Werte addiert. Eine Lösungsmöglichkeit (in meinem Fall) wäre eventuell, erst eine Nettosumme zu bilden und die Mehrwertsteuer aus dieser Nettosumme zu berechnen und dann zu runden.
Nettosumme : 439,50 € + 31,20 € = 470,70 €
Mwst aus 470,70€ = 89,433 € (gerundet 89,43€)
Brutto: 560,13 €
Die Nettosumme muss ja nicht erscheinen, sondern wird nur für die Berechnung intern verwendet.
Genauso geht es auch anders herum, falls man mit Bruttobeträgen arbeitet.
Vielleicht funktioniert das besser.
Gruß
Stephan
Ich nehme an, dass dies nicht so trivial ist.
Es gibt bei uns in Österreich in der Durchführungsverordnung des Umsatzsteuergesetzes ganz konkrete Vorschriften wie und wann gerundet werden muss/darf. Wahrscheinlich ist das in Deutschland (und anderen Ländern) ganz ähnlich geregelt.
Diese Regelungen muss man wohl oder übel einhalten, und daher wird es wie du schon sagtest öfters zu "unschönen" Rundungsdifferenzen kommen.
Ich weiss nicht ob sich das damit lösen lässt, dass man vorgibt (oder eine Auswahlmöglichkeit schafft) auf wie viele Stellen gerundet werden soll.
LG
Jürgen
microangelo
Produktivsysteme:
LinuxMint Debian Edition (LMDE) 6, Fakturama 2.1.3c, MariaDB, Java 17, SingleUser
LinuxMint Debian Edition (LMDE) 6, Fakturama 2.1.3c, MariaDB, Java 17, MultiUser
RaspberryPi OS 12 (Bookworm, 64Bit), Fakturama 2.1.3c, MariaDB, Java 17, Multiuser
auf Raspberry Pi 400, 4GB RAM
Testsystem(e):
LinuxMint Debian Edition (LMDE) 6, Fakturama 2.1.3 (Beta), HSQLDB, Java 17
dzt. kein Windows-System zum testen verfügbar
Alpha-Test:
RaspberryPi OS (64Bit), Fakturama 2.1.3, HSQLDB, Java 11
auf Raspberry Pi 4B, 8GB RAM
Die Anzahl der Stellen ist nicht das Problem, glaube ich. Ich bin eben auch der Meinung, daß es eine Vorschrift gibt, aber ich finde es einfach nicht mehr 🙁 Nach meiner Erinnerung war das Runden nach jedem Zwischenschritt erforderlich. Vielleicht kann ja hier jemand aushelfen, der da besser drin steckt?
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?
microangelo
Produktivsysteme:
LinuxMint Debian Edition (LMDE) 6, Fakturama 2.1.3c, MariaDB, Java 17, SingleUser
LinuxMint Debian Edition (LMDE) 6, Fakturama 2.1.3c, MariaDB, Java 17, MultiUser
RaspberryPi OS 12 (Bookworm, 64Bit), Fakturama 2.1.3c, MariaDB, Java 17, Multiuser
auf Raspberry Pi 400, 4GB RAM
Testsystem(e):
LinuxMint Debian Edition (LMDE) 6, Fakturama 2.1.3 (Beta), HSQLDB, Java 17
dzt. kein Windows-System zum testen verfügbar
Alpha-Test:
RaspberryPi OS (64Bit), Fakturama 2.1.3, HSQLDB, Java 11
auf Raspberry Pi 4B, 8GB RAM
Hallo,
ich habe mal im Internet gegoogelt, habe aber auch keine Antwort gefunden.
Die Rundung der Beträge kann aber in jedem Mitgliedsstaat unterschiedlich gehandhabt werden ( https://datenbank.nwb.de/Dokument/Anzeigen/343016/).
Die Suche nach "rund", "runden", "rundet" in den deutschen Gesetzestexten (UStG, Durchführungsverordnung des Umsatzsteuergesetzes) hat kein Ergebnis geliefert.
Früher haben wir den falschen Centbetrag einfach immer ausgebucht. Die Steuerprüfungen haben dies noch nie bemängelt. Daher vermute ich, dass es steuerlich kein allzu großes Problem darstellt, wenn kein System zur Steuervermeidung erkennbar ist. Was mich (und vermutlich auch Ralf) stört, ist, wenn man die gerundeten Beträge addiert und dies nicht mit der Gesamtsumme übereinstimmt.
Ich muss morgen auf Geschäftsreise. Wenn ich zurück bin, frage ich unseren Steuerberater, ob er eine Regelung kennt, wie gerundet werden muss/soll.
Gruß
Stephan
Hallo,
mein Steuerberater hat geantwortet:
mit Urteil vom 10.7.2008 (C-484/06 – Fiscale eenheid Koninklijke Ahold NV, UR 2008, 660) hat der EuGH bezüglich der Rundung von Mehrwertsteuerbeträgen entschieden, dass es – in Ermangelung einer spezifischen Gemeinschaftsregelung – Sache der Mitgliedstaaten ist, die Regeln und Methoden für die Rundung der Mehrwertsteuerbeträge zu bestimmen. Dabei müssen sie darauf achten, dass die Grundsätze, auf denen das gemeinsame Mehrwertsteuersystem beruht, insbesondere die Grundsätze der steuerlichen Neutralität und der Proportionalität, eingehalten werden. Das Gemeinschaftsrecht enthält bei seinem derzeitigen Stand keine spezifische Verpflichtung, wonach die Mitgliedstaaten den Stpfl. die Abrundung des Mehrwertsteuerbetrages pro Artikel gestatten müssen.
Auch das deutsche Umsatzsteuerrecht sieht – insbesondere in § 16 UStG (Steuerberechnung) – keine Rundungsregelung vor. Deutschland hat das Rundungsproblem mit Hilfe der USt-Erklärungen so gelöst, dass die jeweiligen Umsätze nur in vollen Euro-Beträgen zu erklären sind, die USt selbst ist auf zwei Dezimalstellen genau zu berechnen. Durch den Ansatz voller Euro-Beträge bei den Umsätzen können sich bei der Berechnung der USt keine weiteren Dezimalstellen ergeben, so dass sich die Rundungsfrage – z. B. das kaufmännische Rundungsverfahren – im Rahmen der Steuererklärungen nicht stellt.
Da es sich in Ihrem Falle um Kleinstbeträge handelt, spricht also nichts gegen die kaufmännische Rundung auf zwei Dezimalstellen.
Ich hatte mich auf dieses Beispiel bezogen bei meiner Anfrage:
Beispiel:
Nettosumme Warenwert : 439,50€ + 19% = 523,005€
Nettosumme Versandkosten : 31,20€ + 19% = 37,128€
Berechnet man die ungerundeten Beträge zusammen, kommt man auf 560,133€, bei den gerundeten Bruttobeträgen sind es 560,14€.
So wie ich es verstanden habe, sollte es in Deutschland kein Problem sein. Es gibt hier auch keine Vorschrift, die einzuhalten wäre. Dann wäre meiner Meinung nach das Ziel, dass die Beträge auf den Dokumenten nach dem kaufmännischen Runden, mathematisch korrekt dargestellt werden.
Aber vielleicht kann @Jürgen uns weiterhelfen, wie die Rundung in Österreich zu handhaben ist. Eventuell kommen wir so weiter.
Gruß
Stephan