Warum feste Bruttopreise bei E-Rechnungen zum Problem werden

Stand: 18. Oktober 2026. Der Beitrag erklärt die technische Berechnung, nicht die steuerliche Zulässigkeit einer bestimmten Rechnung.

Ein Preis von 9,99 Euro inklusive Umsatzsteuer steht fest. Für die E-Rechnung wird daraus ein Nettobetrag berechnet, auf Cent gerundet und die Steuer wieder hinzugerechnet. Am Ende stehen 10,00 Euro.

Der zusätzliche Cent ist kein Tippfehler. Er entsteht, weil die Rechnung zweimal durch eine Rundung geht. Wer Preise einschließlich Umsatzsteuer festlegt, muss beim Export in ein strukturiertes Rechnungsformat deshalb mehr klären als die Frage, in welches XML-Feld der Betrag gehört.

Das Thema beschäftigt inzwischen auch die Standardisierung: FeRD hat die Unterstützung von Bruttorechnungen ausdrücklich für eine Weiterentwicklung von ZUGFeRD angekündigt. Was daran technisch schwierig ist, lässt sich schon an einer einzigen Rechnungsposition zeigen.

Wie aus 9,99 Euro 10,00 Euro werden

Für das Rechenbeispiel nehmen wir genau ein Stück, eine Rechnungsposition, 20 Prozent Umsatzsteuer und keine Zu- oder Abschläge. Der aus dem Bruttopreis abgeleitete Nettobetrag wird kaufmännisch auf zwei Nachkommastellen gerundet:

Rechenschritt	Betrag
Festgelegter Preis einschließlich Steuer	9,99 €
Netto vor Rundung: 9,99 ÷ 1,20	8,325 €
Netto auf Cent gerundet	8,33 €
20 Prozent von 8,33, auf Cent gerundet	1,67 €
Netto plus neu berechnete Steuer	10,00 €

Wird die Steuer stattdessen als Rest des festgelegten Bruttopreises bestimmt, ergibt sich 9,99 − 8,33 = 1,66 Euro. Es stehen also zwei unterschiedliche Steuerbeträge im Raum, je nachdem, von welcher Seite gerechnet wird.

Das Beispiel schreibt keine Methode zur steuerlichen Berechnung vor. Es zeigt, dass die Rückrechnung aus einem Bruttopreis nach der Rundung nicht zwingend zum ursprünglichen Betrag zurückführt. Auch mit exakter Dezimalarithmetik bleibt dieser Unterschied bestehen.

Die E-Rechnung hat eine vorgegebene Rechenrichtung

Im auf EN 16931 beruhenden Peppol-BIS-Billing-Modell wird die Rechnung aus Nettobeträgen aufgebaut. Nettopositionen, Zu- und Abschläge ergeben die Bemessungsgrundlagen für die Umsatzsteuer. Die Steuer wird für jede Kombination aus Umsatzsteuerkategorie und Steuersatz aufgeschlüsselt. Erst daraus entsteht die Rechnungssumme einschließlich Steuer. OpenPeppol: Berechnung der Rechnungsbeträge

Die Regel BR-CO-17 beschreibt den Steuerbetrag einer solchen Gruppe als Bemessungsgrundlage mal Steuersatz, gerundet auf zwei Nachkommastellen. In unserem Beispiel führt dieser Rechenweg zu 1,67 Euro Steuer. OpenPeppol: BR-CO-17

Damit ist nicht gesagt, dass jeder Bruttopreis Probleme macht oder ein Validator diese konkrete Cent-Abweichung zwingend zurückweist. Prüfregeln können Toleranzen enthalten; das Ergebnis hängt vom eingesetzten Regelwerk ab. Ein bestandener Test allein beweist deshalb noch nicht, dass die ursprüngliche Preisberechnung unverändert übernommen wurde.

Warum mehr Nachkommastellen nicht immer helfen

Der Einzelpreis und der Nettobetrag der Rechnungsposition sind unterschiedliche Angaben. Peppol erlaubt beim Einzelpreis mehr als zwei Nachkommastellen. Der Nettobetrag einer Position darf dagegen höchstens zwei haben. OpenPeppol: Positionsbetrag und Dezimalstellen

Du kannst den Einzelpreis im Beispiel also mit 8,325 Euro angeben. Bei einem Stück muss der Positionsbetrag trotzdem auf Cent gebracht werden. Die zusätzliche Präzision beim Preis beseitigt diese Rundungsstelle nicht.

Bei größeren Mengen können zusätzliche Preisnachkommastellen durchaus helfen. Daraus folgt aber keine allgemeine Lösung für jeden festgelegten Bruttopreis. Entscheidend ist, an welcher Stelle gerundet wird: beim Einzelpreis, beim Positionsbetrag oder bei der Steuer auf die zusammengefasste Bemessungsgrundlage.

Was das Rundungsfeld tatsächlich korrigiert

Für einen Rundungsausgleich gibt es ein eigenes Feld: BT-114, den Rundungsbetrag. Er geht in die Berechnung des zu zahlenden Betrags ein. Dieser ergibt sich aus der Rechnungssumme einschließlich Steuer, abzüglich bereits gezahlter Beträge, zuzüglich des Rundungsbetrags. OpenPeppol: Zahlbetrag, BR-CO-16

Rechnerisch ließen sich die 10,00 Euro aus unserem Beispiel mit einem Rundungsbetrag von −0,01 Euro wieder auf einen Zahlbetrag von 9,99 Euro bringen. Die 8,33 Euro netto und die 1,67 Euro Steuer bleiben dabei aber bestehen. Das Feld korrigiert nicht rückwirkend deren Berechnung.

Das ist eine wichtige Unterscheidung, wenn dein Rechnungsprogramm einen „Rundungsausgleich“ anbietet. Frage nach, ob damit nur der Zahlbetrag angepasst wird oder ob das Programm zuvor auch Positionen und Steuer neu berechnet. Die Rechnung muss in sich nachvollziehbar bleiben. Das Feld ist keine pauschale Erlaubnis, Steuerdifferenzen auszugleichen.

„Gross price“ heißt im Datenmodell etwas anderes

Eine weitere Stolperfalle steckt im Feldnamen Item gross price, BT-148. Gemeint ist dort nicht der Preis einschließlich Umsatzsteuer, sondern der Einzelpreis vor einem Preisnachlass und ohne Umsatzsteuer. OpenPeppol: Definition von BT-148

Wer ein als „Bruttopreis“ bezeichnetes Feld aus dem eigenen Warenwirtschaftssystem allein wegen des ähnlich klingenden Namens dorthin überträgt, kann also den falschen Wert liefern. Die Bedeutung eines Feldes ist wichtiger als seine Übersetzung.

Was ZUGFeRD dazu angekündigt hat

Am 19. Mai 2026 teilte FeRD das geplante ZUGFeRD-Release in zwei Schritte auf. Die angekündigte Bruttorechnung wurde dem späteren Schritt zugeordnet; als Grund nannte FeRD zusätzliche Anforderungen aus der Überarbeitung der EN 16931 und weiteren Testbedarf. FeRD: Veröffentlichung in zwei Schritten

Auch die Veröffentlichung zu ZUGFeRD 2.5.2 vom 4. August 2026 nennt die Unterstützung von Bruttorechnungen noch als erwarteten Bestandteil eines folgenden Releases, voraussichtlich im Herbst 2026. Das ist eine Ankündigung, kein Beleg für eine bereits verfügbare Umsetzung in deinem Rechnungsprogramm. FeRD: ZUGFeRD 2.5.2 und Ausblick

Aus diesen Meldungen lässt sich auch nicht ableiten, dass jeder Empfänger eine solche Erweiterung bereits verarbeiten kann. Dafür brauchst du eine konkrete Version, ein unterstütztes Profil und eine passende Implementierung auf beiden Seiten.

Was du bei deiner Software prüfen solltest

Wenn du mit festen Bruttopreisen arbeitest, reichen vier konkrete Fragen für ein wesentlich besseres Gespräch mit deinem Softwareanbieter:

• Was bedeutet die Brutto-Eingabe? Bleibt der eingegebene Endpreis maßgeblich, oder wird er lediglich in einen Nettopreis umgerechnet?
• Wann wird gerundet? Lass dir Einzelpreis, Positionsbetrag, Steuer und Zahlbetrag an derselben Rechnung zeigen.
• Wo steht eine Differenz? Ist ein Rundungsausgleich ausdrücklich ausgewiesen, und welche Beträge verändert er?
• Was akzeptiert der Empfänger? Entscheidend sind das vereinbarte Format, seine Version und das Profil, nicht allein die Bezeichnung „E-Rechnung“.

Ein brauchbarer Test vergleicht deshalb nicht nur die sichtbare Endsumme. Vergleiche auch die Nettopositionen, die Steueraufschlüsselung und den Zahlbetrag im exportierten Datensatz mit deinem Ausgangsbeleg. Sind beide Endsummen 9,99 Euro, können die Beträge darunter trotzdem voneinander abweichen.

Zum Weiterlesen: Wie sich die Rechnungsformate unterscheiden und warum neue Anforderungen auch das Datenmodell der XRechnung verändern.