Rundungsfehler in der XRechnung: Warum 1 Cent zur Ablehnung führt

Ein XRechnung Rundungsfehler entsteht, wenn eine Summe in der Datei nicht exakt zu den Beträgen passt, aus denen sie gebildet wird. Die Prüfregeln der EN 16931 (BR-CO-10, BR-CO-13, BR-CO-14, BR-CO-15) vergleichen auf den Cent genau. Eine Abweichung von 0,01 Euro ist ein Fehler der Stufe „fatal“, und der KoSIT-Validator empfiehlt dann „reject“.

Dieser Beitrag rechnet ein Beispiel mit drei Positionen vollständig durch und zeigt, welche Rundungsvariante welche Regel auslöst. Sie finden danach die Ursache in Ihrer eigenen Datei und wissen, wo im Rechnungsprogramm Sie sie beheben.

Wie lautet die Fehlermeldung?

Im Prüfbericht oder im XRechnung Validator erscheint eine dieser Meldungen. Der Text ist der Originaltext aus dem CEN-Schematron 1.3.16, das die KoSIT-Konfiguration 2026-08-31 für XRechnung 3.0.2 verwendet:

[BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131).
[BR-CO-13]-Invoice total amount without VAT (BT-109) = Σ Invoice line net amount (BT-131) - Sum of allowances on document level (BT-107) + Sum of charges on document level (BT-108).
[BR-CO-14]-Invoice total VAT amount (BT-110) = Σ VAT category tax amount (BT-117).
[BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).

Alle vier Regeln haben die Stufe „fatal“. Die XRechnung-eigenen Regeln (XRechnung-Schematron 2.6.0) enthalten keine weiteren Rechenregeln für Standardrechnungen. Nur die Extension prüft mit BR-DEX-09 zusätzlich den Zahlbetrag mit Drittzahlungen.

Die Summenkette: Welche Regel prüft welchen Betrag?

Jede Summe in einer XRechnung baut auf der vorherigen auf. Wer die Kette kennt, findet den Fehler in Minuten:

Die Spalte „Toleranz“ stammt aus den Testausdrücken der Regeln im CEN-Schematron. BR-CO-17 und BR-S-09 prüfen, ob der angegebene Steuerbetrag größer als „berechneter Wert minus 1“ und kleiner als „berechneter Wert plus 1“ ist. BR-S-08 prüft die Bemessungsgrundlage mit derselben Spanne. Alle anderen Regeln vergleichen mit Gleichheit.

Zwei Details aus der Tabelle überraschen viele:

• Schritt 1 wird nicht geprüft. Keine Regel der Konfiguration 2026-08-31 rechnet nach, ob BT-129 (Menge) × BT-146 (Nettopreis) den Betrag in BT-131 ergibt. Geprüft werden nur die höchstens zwei Nachkommastellen. Der Einzelpreis BT-146 darf mehr Nachkommastellen haben.
• In der Extension ist BR-CO-16 herabgestuft. Das Szenario „XRechnung Extension“ setzt BR-CO-16 per customLevel auf „information“ und prüft den Zahlbetrag stattdessen mit BR-DEX-09.

Beispiel: Drei Positionen, neun Varianten

Die Muster GmbH stellt der Beispiel AG Büromaterial zu 19 % in Rechnung:

Korrekt gerechnet ergibt das: BT-106 = 39,52 €, BT-116 = 39,52 €, BT-117 = 39,52 × 0,19 = 7,5088, also 7,51 €, BT-110 = 7,51 €, BT-112 = 47,03 €.

Wir haben diese Rechnung als XRechnung 3.0 (UBL) gebaut und neun Varianten mit der Prüf-Engine unseres Viewers geprüft. Sie wendet die Regeln der KoSIT-Konfiguration 2026-08-31 an. Die Ergebnisse vom 02.11.2026:

Drei Erkenntnisse aus dem Test:

1. Ein einziger Cent in BT-106, BT-110 oder BT-112 führt zur Ablehnung (B, D, E).
2. Beide Rundungsmethoden für die Steuer sind technisch zulässig (A und C), solange Sie eine davon durchgängig verwenden.
3. „Gültig“ heißt nicht „richtig“. Variante H ist um 1 Cent zu niedrig berechnet, Variante I weist 0,99 € zu viel Steuer aus. Beide bestehen die Prüfung.

Variante I ist steuerlich ernst. Nach § 14 Abs. 4 Satz 1 Nr. 8 UStG (öffnet in neuem Tab) gehört der auf das Entgelt entfallende Steuerbetrag auf die Rechnung. Wer einen höheren Betrag ausweist, schuldet nach § 14c Abs. 1 UStG (öffnet in neuem Tab) auch den Mehrbetrag. Die Validierung ersetzt also keine inhaltliche Prüfung. Wie das BMF technische Fehler und Inhaltsfehler unterscheidet, erklärt der Beitrag Formatfehler oder Inhaltsfehler.

Warum entstehen Rundungsfehler?

Die Ursachen, nach Häufigkeit in der Praxis geordnet:

1. Summe aus ungerundeten Werten. Das Programm hält intern 16,415 und 8,125, summiert und rundet erst die Summe. Ergebnis: BT-106 = 39,51 €, die Positionen in der XML ergeben 39,52 € (Variante B).
2. Zwei Steuermethoden in einer Datei. Die Aufschlüsselung (BT-117) kommt aus einem Modul, das je Position rundet, die Kopfsumme (BT-110) aus einem anderen, das auf die Gesamtsumme rechnet (Variante D).
3. Bruttorechnung. Kassen- und Shopsysteme rechnen oft mit Bruttopreisen und ermitteln BT-112 als Summe der Bruttopositionen. Die XRechnung verlangt aber BT-112 = BT-109 + BT-110 (Variante E).
4. Gleitkommazahlen. Viele Programmiersprachen speichern 16,415 binär als 16,41499999… und runden dann auf 16,41. In Python liefert round(8.125, 2) den Wert 8,12, weil Python bei exakt halben Werten zur geraden Ziffer rundet. Kaufmännisch richtig wäre 8,13.
5. Nachlässe auf Belegebene. Ein Rabatt von 3 % auf die Gesamtsumme (BT-92) wird in BT-107 anders gerundet als in der Aufschlüsselung je Satz. Dann scheitern BR-CO-11 oder BR-CO-13.
6. Zahlungsrundung ohne BT-114. Wer den Zahlbetrag auf volle 5 Cent rundet, muss die Differenz in BT-114 (Rundungsbetrag) angeben. Sonst passt BT-115 nicht zu BR-CO-16.

Fehlersuche Schritt für Schritt

So finden Sie die fehlerhafte Stelle in einer abgelehnten Datei:

1. Regel-ID notieren. BR-CO-10 zeigt auf BT-106, BR-CO-14 auf BT-110, BR-CO-15 auf BT-112. Die XRechnung Fehlercodes helfen bei der Zuordnung, die Bedeutung entnehmen Sie dem Originaltext oben.
2. Positionen nachrechnen. Öffnen Sie die Datei im XML Viewer und schreiben Sie alle cbc:LineExtensionAmount der cac:InvoiceLine-Elemente ab. Rechnen Sie zusätzlich Menge × Preis nach, denn das prüft kein Validator.
3. Kette von oben nach unten prüfen. BT-106 gegen Σ BT-131, dann BT-109, dann BT-117 je Satz, BT-110, BT-112, BT-115. Der erste Schritt, der nicht passt, ist die Ursache. Spätere Fehler sind oft nur Folgefehler.
4. Methode bestimmen. Vergleichen Sie BT-117 mit BT-116 × Satz. Weicht der Wert um ein paar Cent ab, rundet Ihr Programm je Position. Dann muss BT-110 dieselbe Summe zeigen.
5. Im Quellsystem korrigieren. Ändern Sie die Rundungseinstellung oder den Export im Rechnungsprogramm, nicht die XML-Datei von Hand. Sonst kommt der Fehler mit der nächsten Rechnung zurück.
6. Neu exportieren und erneut prüfen. Erst wenn kein Fehler der Stufe „fatal“ bleibt, versenden Sie die Rechnung.

Weitere Fehlerbilder rund um Summen und Pflichtfelder beschreibt der Leitfaden XRechnung Fehler beheben.

Wie verhindern Sie Rundungsfehler dauerhaft?

Diese Regeln im Rechnungsprogramm oder im eigenen Code verhindern die meisten Fälle:

Wer viele Rechnungen erzeugt, sollte einen Testfall wie unser Beispiel dauerhaft in die eigene Testsuite aufnehmen. Werte mit einer 5 an der dritten Nachkommastelle (16,415 und 8,125) decken fehlerhafte Rundung zuverlässig auf. Wie ein vollständiger Testablauf vor dem ersten Versand aussieht, steht im Beitrag E-Rechnung testen. Wie Sie dieselben Regeln lokal mit dem offiziellen Werkzeug prüfen, erklärt der Beitrag zum KoSIT-Validator. Weitere Ratgeber finden Sie unter Validierung und Fehler.

So prüfen Sie Rundungen mit docutools.pro

1. Öffnen Sie den XRechnung Viewer und laden Sie die XML-Datei hoch. Die Datei wird zur Prüfung an unseren Server übertragen. Die „KoSIT-Prüfung“ prüft wie der KoSIT-Validator (Konfiguration 2026-08-31) und zeigt die Regel-IDs, etwa BR-CO-10, mit dem Originaltext. Kostenlos sind 2 Uploads pro Tag bis 500 KB.
2. Die Zeile „Summe der Positionen (BT-106)“ unter den „Positionen“ addiert die Positionsbeträge aus der Datei. Vergleichen Sie diesen Wert mit „Summe der Positionen“ und „Nettobetrag“ in der Tabelle „Extrahierte Daten“, die die Summen so zeigt, wie sie in der XML stehen. Eine Cent-Differenz fällt dabei sofort auf.
3. Bei einer selbst erstellten Rechnung mit einem einzigen Steuersatz klicken Sie auf „Positionen bearbeiten“. Nach dem Speichern berechnet Smart Repair die Kette von BT-106 bis BT-115 aus den Positionen neu und vermerkt die Änderung in der XML. Kostenlos ist 1 Smart Repair pro Tag. Mehr Prüfungen und Reparaturen bietet der Pro-Tarif.
4. Für neue Rechnungen können Sie mit dem Generator eine E-Rechnung erstellen. Er bildet die Summen aus den eingegebenen Positionen.

Quellen

• CEN-Schematron für EN 16931, Version 1.3.16 (Regeltexte und Testausdrücke): github.com/ConnectingEurope/eInvoicing-EN16931 (öffnet in neuem Tab)
• KoSIT-Prüfkonfiguration für XRechnung 3.0.2, Release 2026-08-31: github.com/itplr-kosit/validator-configuration-xrechnung (öffnet in neuem Tab)
• XRechnung-Spezifikation und Versionen: xeinkauf.de/xrechnung (öffnet in neuem Tab)
• § 14 UStG und § 14c UStG: gesetze-im-internet.de (öffnet in neuem Tab)

Stand: November 2026

Dieser Beitrag dient der allgemeinen Information und ersetzt keine Steuer- oder Rechtsberatung.