Netto/Brutto und Umsatzsteuer: Rundungsgenauigkeit - Berechnungsgenauigkeit

  • Ich habe in meiner kleinen Wäscherei B2C-Kunden und B2B-Kunden.
    Auf meinem Wäschezettel stehen nur Bruttopreise (weil nur diese für die Kundenmehrheit (B2C) interessant sind und um es übersichtlich zu halten und um Papier zu sparen.

    Für die Kunden, die eine Rechnung bekommen und die dann überweisen, kommt ja nun die E-Rechnung.

    Wenn ich Zugferd/XRechnung nutzen will, muss ich ja nun in der Rechnungserstellung mit Nettopriesen arbeiten.

    Dabei ist mir nun augefallen, dass die Berechnung nicht in jedem Fall auf dem Bruttopreis des Wäschezettels landet.

    ein Beispiel, bei dem ich mit keiner "Preisgestaltung" auf die erforderlichen 94,10 € Bruttopreis komme (nur ein Posten, es sollte also auch nicht ander Frage von zeilen- oder spaltenweiser Berechnung der USt. liegen):

    Der Wäschezettel (Bruttopreise) sagt, die Gesamtsumme beträgt 94,10 €

    94,10 € / 1,19 = 79,075630

    In den Einstellungen für Artikelpreise kann ich maximal 4 Nachkommastellen einstellen, aber es wird offenbar der Bruttobetrag nicht korrekt berechnet.
    Ich füge Screenshots an:
    2 aus Taxpool und eine Tabelle, in der eine Beispielreihe gezeigt wird.

    Frage/n:
    Ist das nun ein Fehler in Taxpool oder in der Bedienung durch mich oder in meinem Verständnis?

    Was kann ich tun, um ein korrektes Ergebnis zu bekommen?


             

  • Für die Kunden, die eine Rechnung bekommen und die dann überweisen, kommt ja nun die E-Rechnung.

    Warum willst Du freiwillig E-Rechnungen erstellen? Es gibt doch für Dich vermutlich keine Notwendigkeit dazu.

    Bevor bis Ende 2026 Unternehmen über 800.000,00 € Umsatz E-Rechnungen verpflichtend ausstellen müssen bleibt genügend Zeit, sich Gedanken darüber zu machen, ob es für Dich wirklich sinnvoll ist freiwillig E-Rechnungen zu erstellen.


    Du willst aus Vereinfachung mit Bruttopreisen für Deine Kunden arbeiten, weil im B2C nur Bruttopreise interessant sind. Andererseits hast Du aber B2B Kunden, denen Du E-Rechnungen erstellen willst. Um Rundungsdifferenzen wirst Du so nicht herumkommen.


    In den Einstellungen für Artikelpreise kann ich maximal 4 Nachkommastellen einstellen, aber es wird offenbar der Bruttobetrag nicht korrekt berechnet.

    Ich erkenne nicht, was bei der Berechnung in Taxpool nicht korrekt sein soll.

    Aus einem Netto-Einzelpreis eines einzelnen Artikels mit Preis von 79,0749 € (mal Menge 1) ergibt sich eine Positionssumme von netto 79,07 €.

    Darauf ist USt zu berechnen und nicht auf 79,0749 €.


    Mit den 4 Nachkommastellen der Preise kann immer nur ein Nettobetrag berechnet werden, der auf Cent gerundet wird. Erst auf den gerundeten Nettobetrag wird die USt berechnet. Das ist unabhängig von zeilen- oder spaltenweiser Berechnung.

    Beiträge stellen keine rechtliche Beratung dar, sie sind lediglich Meinungsäußerung des Verfassers. Das Urheberrecht für durch mich erstellte Inhalte in Themen und Beiträgen verbleibt, ungeachtet der eingeräumten Rechte an den Forenbetreiber, bei mir. Weitere Infos über mich.

  • Versteh ich nicht.

    Nachdem, was ich weiß, wird erst gerechnet und dann gerundet.

    Weshalb soll ich denn sonst 4 Stellen hinter dem Komma angeben können, wenn dann nicht mit dieser Genauigkeit gerechnet wird?
    ja, ich weiß, wegen Mengenpreisen (36 Stück des Artikels a + 174 Stück von Artikel b...).

  • Ich hatte sowas vor knapp 30 Jahren. Wenn ich mich richtig erinnere, ist der korrekte Weg, den Nettobetrag zu nehmen, hiervon die USt zu ermitteln, und diese dann zum Nettobetrag zu addieren.


    Also

    79,08 + (79,08 * 0,19) = 79,08 + 15,03 (gerundet) = 94,11


    Das kann, wieder soweit mich das Gedaechtnis nach so langer Zeit nicht truegt, im Extremfall von Netto*1,19=Brutto abweichen.


    War mit damals aufgefallen, weil das neue Kassensystem eines grossen Buerofachmarktes die USt tatsaechlich falsch berechnet hatte.

    • Official Post

    Es ist zu erwähnen, dass in Kürze in Taxpool auch Bruttowerte bei E-Rechnung möglich sind, das neue E-Rechnungsformat ermöglicht dies und es gibt dort ein zusätzliches Feld 'Rounding amount' (BT-114).


    WIKO hat bzgl. des Pflichttermins zur Erstellung von E-Rechnungen natürlich Recht, aber E-Rechnungen haben den wichtigen Vorteil, daß sich die Rechnungsdaten ganz einfach vom Käufer einlesen lassen. Ich teste gerade die Beta von Taxpool 19.02 (noch nicht online), in der das Einlesen von E-Rechnungen möglich ist und es ist außerordentlich praktisch.


    Warum gibt es Unterschiede bei der Berechnung von Netto- und Bruttowert?

    Ein Kunde könnte sich wundern, warum er nicht exakt zum ursprünglichen Bruttobetrag zurückkommt, wenn er zuerst den Netto-Wert aus einem Brutto-Wert berechnet und anschließend wieder den Brutto-Wert berechnet.



    🧮 Ursache: Rundungsdifferenzen durch die Mehrwertsteuer

    Beim Umrechnen von Brutto zu Netto und zurück entstehen kleine Rundungsabweichungen, weil:

    • Der Netto-Wert auf zwei Nachkommastellen gerundet wird.
    • Die Mehrwertsteuer wieder auf den gerundeten Netto-Wert berechnet wird.
    • Auf- und Abrundungen im Cent-Bereich unvermeidlich sind.

    💡 Das passiert besonders oft, wenn der ursprüngliche Brutto-Wert keine saubere Netto-Zahl ergibt.

    📌 Lösung: Wie kann man das dem Kunden erklären?

    🔹 Die Rundung erfolgt auf zwei Nachkommastellen (auf- oder abgerundet).

    🔹 Das ist kein Fehler, sondern eine normale mathematische Eigenschaft der Mehrwertsteuerberechnung.

    🔹 Ein Unterschied von 0,01 € ist völlig normal und tritt in vielen Rechnungen auf.

    🔹 Es gibt keine exakte Umkehrfunktion, da beim ersten Schritt Information verloren geht (durch Rundung).

    🚀 Fazit:

    🔹 Brutto → Netto → Brutto führt oft zu kleinen Differenzen.

    🔹 Grund: Rundung auf zwei Nachkommastellen beim Netto-Betrag.

    🔹 Keine exakte Umkehrfunktion – aber kein Fehler, sondern mathematisch unvermeidbar.

    Die Beträge des Autors dienen ausschließlich dem Zweck der Information oder Meinungsäußerung und stellen keine rechtliche oder andersweitige Beratung oder Zusicherung dar.

    Änderungen und Irrtümer sind vorbehalten.

  • ich danke euch für eure Mühe.

    Ich stelle fest, im "Kaufmännischen" wird nicht mathematisch korrekt gerechnet. Das mag an vielen Stellen vereinfachend sein, aber es führt an ebenso vielen Stellen zu Verwirrung.
    Mathematisch sollte es egal sein, wie herum gerechnet wird:

    Netto aus Brutto (mathematisches Rechnen):
    94,10 / 1,19 = 79,0756 -> kaufmännisch gerundet: Netto: 79,08
    79,0756 * 0,19 = 15,0243 -> kaufmännisch gerundet: MwSt.: 15,02
    79,08 + 15,02 = 94,10

    79,0756 + 15,0243 = 94,0999 -> kaufmännisch gerundet: 94,10

    Wenn ich (im B2B-Geschäft) eine Nettopreisliste habe, dann summiere ich auf meiner Rechnung die Nettopreise und ziehe dann (zeilenweise oder spaltenweise) die Umsatzsteuer. Dann ist der Nettopreis meine Vorgabe und ich habe gar kein Problem damit, wenn "krumme Centbeträge" rauskommen.

    Aber wenn ich (im B2C-Verkehr) absichtlich "gerade/saubere/schöne" Endpreise haben will, rechne ich anders herum - ich ziehe aus dem Brutto- den Nettopreis und die Umsatzsteuer.
    Wohl nur in sehr seltenen Fällen rechnet man von einer Seite zur anderen und dann wieder zurück umd DANN dieses Ergebnis zweier Umrechnungen zu verwenden.

    Wenn in einem Programm eine Anzahl Nachkommastellen möglich ist, die über die Standardanzahl hinausgeht, dann sollte auch mit disen intern gerechnet werden. Es ist UNLOGISCH, 4 Kommastellen anzubieten, um dann (nicht mathematisch korrekt) mit nur zwei Nachkommastellen zu rechnen, nachdem kaufmännisch (also mathematisch NICHT korrekt) gerundet wurde.
    Kaufmännisches Runden ist nur dann korrekt, wenn das Endergebnis gerundet wird und nicht schon bei Zwischenschritten.

    Wenn ich statt einer Mengeneinheit mehrere habe, sähe das ja dann so aus:
    nach der Taxpool-Logik (und wie ihr es mir oben erklärt habt):

    vom Netto zum Brutto:

    79,0756 -> 79,08 x 73 Stück = 5.772,84 x 0,19 = 1.096,8396 -> 1.096,84
    Netto: 5.772,84
    USt.: 1.096,84
    Brutto: 6.869,68

    / 73 Stück = 94,1052 -> 94,11


    vom Brutto zum Netto:

    94,10 x 73 Stück = 6.869,30 / 1,19 = 5.772,5210 -> 5.772,52 x 0,19 = 1.096,7788 -> 1.096,78

    Brutto: 6.869,30

    USt.: 1.096,78
    Netto: 5.772,52

    / 73 Stück = 79,0756 -> 79,08

    -------------------------------------

    mathematisch korrekt gerechnet und am Ende kaufmännisch gerundet:

    vom Netto zum Brutto:

    79,0756 x 73 Stück = 5.772,5188 x 0,19 = 1.096,7786 -> 1.096,78
    Netto: 5.772,52

    USt.: 1.096,78

    Brutto: 6.869,30

    / 73 Stück = 94,10


    vom Brutto zum Netto:

    94,10 x 73 Stück = 6.869,30 / 1,19 = 5.772,5210 x 0,19 = 1.096,7789

    Brutto: 6.869,30

    USt.: 1.096,7789 -> 1.096,78

    Netto: 5.772,5210 -> 5.772,52

    / 73 Stück = 79,0756 -> 79,08

    Beim Nettostückpreis haben wir also Übereinstimmung, aber beim Bruttostückpreis einen Cent Differenz bei der "Taxpool-Methode", die üblich zu sein scheint bei kaufmännischen Berechnungen.
    Bei der Umsatzsteuer hingegen habe ich bei der mathematisch korrekten Berechnung in beide Richtungen Gleichstand, während beim "Runden zwischendurch" doch klare Unterschiede entstehen, wie viel nun an Umsatzsteuer entsteht - bei 73 Stück sicher nicht "kriegsentscheidend", aber wenn man das hochrechnet...
    Ja, für meinen Zwergenumsatz ist das wahrscheinlich unerheblich und nur an seltenen Beträgen überhaupt sichtbar, aber es ist da, das Fehlerchen.


    Um zu einem Ende zu kommen (und, weil ICH das vorherrschende Berechnungssystem wahrscheinlich eher nicht ändern kann) beherzige ich eure Empfehlung, mich wie gewohnt mit meinen Brutto-Rechnungen zu befassen und das Thema E-Rechnung zumindest so lange ruhen zu lassen, bis dies auch für mich mit meinen Bruttorechnungen in Taxpool nutzbar sein wird.


    :)


    Nochmals danke für Eure Zeit und Mühe.

    • Official Post

    Erst noch abzuwarten, wie sich die E-Rechnungen in Taxpool entwickeln ist eine kluge Entscheidung.

    Für andere mitlesende User will ich nur klarstellen, worin das eigentliche Problem besteht und warum Taxpool durchaus korrekt rechnet.

    Ich stelle fest, im "Kaufmännischen" wird nicht mathematisch korrekt gerechnet.

    Das stimmt natürlich nicht!


    Allerdings kann die Netto-Summe einer Position die einem Mehrwertsteuersatz zu unterwerfen ist nicht Cent-Bruchteile beinhalten. Schließlich kann ein Umsatz von beispielsweise 0,0056 € nicht verbucht werden.

    Das ist der Grund dafür, dass am Ende einer Position die Netto-Summe der Position auf 2 Nachkommastellen gerundet wird.


    Deine Darstellung ist falsch...

    Wenn ich statt einer Mengeneinheit mehrere habe, sähe das ja dann so aus:
    nach der Taxpool-Logik (und wie ihr es mir oben erklärt habt [So wurde es aber nicht erklärt.]:(

    vom Netto zum Brutto:

    79,0756 -> 79,08 x 73 Stück = 5.772,84 x 0,19 = 1.096,8396 -> 1.096,84
    Netto: 5.772,84
    USt.: 1.096,84
    Brutto: 6.869,68

    / 73 Stück = 94,1052 -> 94,11

    Taxpool rechnet (kaufmännisch und mathematisch völlig korrekt):

    Anzahl x Netto-Einzelpreis (ungerundet!) = Netto-Positionssumme (zu runden auf 2 Nachkommastellen)

    73 x 79,0756 € = 5.772,5188 €, gerundet 5.772,52 €


    Es wird also nicht der Netto-Einzelpreis gerundet, wie von Dir verstanden, sondern die Netto-Positionssumme wird gerundet. So wurde es auch beschrieben.

    Aus einem Netto-Einzelpreis eines einzelnen Artikels mit Preis von 79,0749 € (mal Menge 1) ergibt sich eine Positionssumme von netto 79,07 €.


    Auf die Netto-Positionssumme (Bemessungsgrundlage der USt) erfolgt dann der USt-Aufschlag:

    19 % auf 5.772,52 € = 1.096,7788 €, gerundet 1.096,78 €.


    Da bei Anzahl 1 und Netto-Einzelpreis 79,0756 € auch die Netto-Positionssumme zu runden ist fällt die Rundungsdifferenz dabei deutlicher auf. In den Rechnungen von Taxpool wird aber der exakte Netto-Einzelpreis bis zur Netto-Positionssummenberechnung verwendet.


    Wenn in einem Programm eine Anzahl Nachkommastellen möglich ist, die über die Standardanzahl hinausgeht, dann sollte auch mit disen intern gerechnet werden. Es ist UNLOGISCH, 4 Kommastellen anzubieten, um dann (nicht mathematisch korrekt) mit nur zwei Nachkommastellen zu rechnen, ...

    In den Rechnungen von Taxpool wird tatsächlich der exakte Netto-Einzelpreis (4 Kommastellen) zur Netto-Positionssummenberechnung verwendet. Du erkennst es nur nicht. Dass allerdings die Positionssumme (als Bemessungsgrundlage der USt) nicht Cent-Bruchteile beinhalten kann liegt in der Logik der Steuergesetze/Buchhaltung und nicht in der der Mathematik. Wenn es andere Programme nicht so handhaben machen die etwas falsch.


    Wenn Du mit Deiner eigenen Berechnung vergleichst wirst Du feststellen, dass Taxpool nicht nur mathematisch korrekt arbeitet, sondern auch verwertbare Berechnungsgrundlagen für die Steuerbuchungen bereitstellt.


    Melde Dich gern, wenn Du das Thema Rechnungsstellung per E-Rechnung wieder aufgreifst. Vorerst mache ich das Thema zu.

  • Taxoloop

    Closed the thread.
    • New
    • Official Post

    Bruttopreise bei E-Rechnungen sind in Version 19.04 nun möglich:


    Es ist zu empfehlen, E-Rechnungen immer basierend auf Nettopreisen zu erzeugen. Bruttopreise werden vom Programm zwar unterstützt, aber dabei ist zu beachten, dass das Programm derzeit die Rechnungs-PDF bei Bruttopreisen mit Bruttowerten erstellt.

    Da E-Rechnungen auf Nettowerten basieren, kann es zu einer geringen Rundungsdifferenz durch die Umrechnung kommen, die in der erstellten XML-Datei in diesem Fall als separater Posten (RoundingAmount, BT-114) ausgewiesen wird, um auf den Bruttobetrag der Brutto-PDF-Rechnung auszugleichen.

    Beispielsweise könnte der Nettowert in der Brutto-PDF-Rechnung um 0,1 Währungseinheiten von dem Nettowert in der XML-Datei abweichen.

    Die Beträge des Autors dienen ausschließlich dem Zweck der Information oder Meinungsäußerung und stellen keine rechtliche oder andersweitige Beratung oder Zusicherung dar.

    Änderungen und Irrtümer sind vorbehalten.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!