Rundungsdifferenzen zwischen Shop, ERP und E-Rechnung lösen

Nehmen wir den Warenkorb aus der Einleitung, alle Artikel zum Regelsteuersatz von 19 Prozent (§ 12 Abs. 1 UStG) und alle Preise brutto ausgezeichnet. Der Shop rechnet so, wie es im Endkundengeschäft naheliegt: Er zieht die Steuer aus jedem Positionsbetrag heraus, rundet je Position und addiert. Aus 238,80 Euro für die zwölf Stück werden 38,13 Euro Steuer, aus 7,49 Euro werden 1,20 Euro und aus 4,99 Euro 0,80 Euro. Zusammen sind das 40,13 Euro Steuer, 211,15 Euro netto und 251,28 Euro brutto. Diesen Betrag sieht der Kunde im Checkout, und diesen Betrag zahlt er.

Die Warenwirtschaft übernimmt die Nettobeträge der Positionen, 200,67 Euro, 6,29 Euro und 4,19 Euro, und rechnet die Steuer einmal auf die Summe: 211,15 Euro mal 19 Prozent sind 40,1185 Euro, gerundet 40,12 Euro. Die Rechnung lautet damit auf 251,27 Euro. Genau so verlangt es die E-Rechnung: Der Steuerbetrag je Steuersatz ist die Bemessungsgrundlage je Steuersatz mal Steuersatz durch 100, gerundet auf zwei Nachkommastellen (Peppol BIS Billing 3.0). Der Kunde hat 251,28 Euro überwiesen, die Rechnung fordert 251,27 Euro, und in der Debitorenbuchhaltung steht ein Cent Überzahlung.

Beide Rechenwege sind für sich schlüssig. Der Unterschied entsteht, weil drei Rundungen je Position zusammen nicht dasselbe ergeben wie eine Rundung auf die Summe. Jede einzelne Rundung verschiebt um höchstens einen halben Cent; über drei Positionen addiert sich das hier zu einem Cent, über viele Positionen zu mehreren. Wer 40 einzelne Positionen zu je 0,99 Euro brutto Zeile für Zeile rechnet, kommt auf 6,40 Euro Steuer und 33,20 Euro netto. Auf die Summe der Nettobeträge gerechnet sind es 6,31 Euro Steuer, und die Rechnung endet bei 39,51 statt 39,60 Euro. Das sind neun Cent, die niemand bestellt hat.

Im Kern gibt es zwei Rechenwege. Beim ersten wird die Steuer je Position berechnet, gerundet und anschließend addiert. Beim zweiten werden die Nettobeträge aller Positionen mit demselben Steuersatz addiert, und die Steuer entsteht einmal auf diese Summe. Der erste Weg liegt nahe, wenn Preise brutto ausgezeichnet werden: Wer Verbrauchern Waren anbietet, hat die Gesamtpreise anzugeben (§ 3 PAngV), und jede Zeile im Warenkorb ist dann bereits ein Endpreis. Der zweite Weg ist der, den die E-Rechnung nachrechnet.

Für Geschäftskunden spricht deshalb viel dafür, den Shop auf Nettopreise und die Steuer auf die Summe umzustellen. In Shopware lässt sich für jede Kundengruppe einzeln festlegen, ob Preise brutto oder netto angezeigt und berechnet werden (Shopware-Dokumentation). Wer eine Kundengruppe für Geschäftskunden führt, kann dort netto rechnen und für Endkunden bei Bruttopreisen bleiben. Welche Gruppe ein Kunde bekommt, gehört in den Kundenstamm des ERP und nicht in eine Einstellung, die jemand im Shop von Hand pflegt. Wie das mit der Steuerfindung im B2B-Shop zusammenspielt, steht in einem eigenen Beitrag.

Die zweite Quelle für Cent-Differenzen sind Preise, die zu früh gerundet werden. Die E-Rechnung unterscheidet zwischen dem Nettopreis eines Artikels (BT-146) und dem Nettobetrag einer Position (BT-131). Für den Positionsbetrag, die Bemessungsgrundlage und den Steuerbetrag je Satz gilt die Grenze von zwei Nachkommastellen (Peppol BIS Billing 3.0); den Artikelnettopreis betrifft keine der Dezimalregeln BR-DEC. Ein ERP kann den Nettopreis also mit vier Nachkommastellen führen und übergeben, und es sollte das tun, wenn Bruttopreise die Ausgangsgröße sind.

Im Beispiel kostet ein Stück 19,90 Euro brutto, netto sind das rechnerisch rund 16,72269 Euro. Mit zwei Nachkommastellen gespeichert, werden daraus 16,72 Euro, und zwölf Stück ergeben 200,64 Euro statt 200,67 Euro. Die ganze Rechnung landet dann bei 251,23 Euro, fünf Cent unter dem Betrag im Shop. Mit vier Nachkommastellen, 16,7227 Euro, ergibt dieselbe Menge 200,6724 Euro und gerundet 200,67 Euro. Der Unterschied entsteht allein aus der Speicherung des Preises und wächst mit der Menge. Peppol beschreibt den Rechenweg ausdrücklich: Menge mal Preis je Preisbasismenge wird auf zwei Nachkommastellen gerundet, Nachlässe und Zuschläge auf der Position werden getrennt gerundet (Peppol BIS Billing 3.0).

Bei sehr kleinen Stückpreisen hilft die Preisbasismenge (BT-149). Eine Schraube für 0,0123 Euro netto lässt sich als 12,30 Euro je 1.000 Stück auszeichnen; der Positionsbetrag ergibt sich dann aus Preis geteilt durch Basismenge mal Menge (Peppol BIS Billing 3.0). Die Einheit der Basismenge muss dort dieselbe sein wie die der berechneten Menge (Peppol BIS Billing 3.0). Wie Einheiten und Gebinde sauber vom ERP in den Shop kommen, steht im Beitrag zu Mengeneinheiten und Gebinden. Er erklärt auch, warum Beträge in einen Dezimaltyp gehören und nicht in eine Gleitkommazahl.

Auch der Shop hat Stellschrauben. In Shopware wird je Währung festgelegt, wie Preise im Warenkorb und in den Zwischensummen gerundet werden, getrennt davon die Gesamtsumme, und ein eigener Schalter entscheidet, ob die Rundung der Positionen auch für Nettokunden gilt (Shopware-Dokumentation). Diese Einstellungen gehören in dieselbe Rechenvorschrift wie die des ERP. Weichen sie voneinander ab, rechnen beide Systeme korrekt und trotzdem verschieden. Die Ursache steckt dann in der Preissynchronisation oder im Daten-Mapping zwischen ERP und Shop.

Alle bisherigen Fälle haben eine gemeinsame Ursache: Zwei Systeme rechnen denselben Vorgang, jedes nach seiner Logik. Die Lösung ist deshalb organisatorisch, nicht mathematisch. Ein System rechnet Positionsbeträge, Nachlässe, Steuer je Satz und Summen, alle anderen übernehmen die Beträge und prüfen sie, ohne neu zu rechnen. Welches System die Rechnung ausstellt, ist dafür eine Vorfrage, die der Beitrag Rechnung aus Shop oder ERP behandelt. Der Rechenweg muss nicht im selben System liegen wie die Rechnungsnummer, aber er muss eindeutig einem System gehören.

Für die Übergabe heißt das: Die Schnittstelle überträgt nicht nur Mengen und Preise, sondern auch die gerechneten Beträge, also Positionsbetrag, Nachlässe und Zuschläge je Satz, Bemessungsgrundlage und Steuer je Satz sowie die Summen. Der Empfänger prüft die Summenregeln selbst nach und stellt einen Vorgang mit Abweichung in eine Fehlerliste, statt ihn still zu korrigieren. Diese Prüfung passt in eine Middleware zwischen Shop und Warenwirtschaft. Ändert sich eine Bestellung nach der Übergabe, gilt dasselbe für die geänderten Beträge; wie man das sauber nachzieht, zeigt der Beitrag zur Bestelländerung nach der ERP-Übergabe.

Das Bundesfinanzministerium unterscheidet bei der E-Rechnung zwischen Formatfehlern und Geschäftsregelfehlern. Ein Geschäftsregelfehler liegt etwa vor, wenn Angaben einander widersprechen; als Beispiel nennt das Schreiben einen Steuerbetrag, der rechnerisch nicht mit dem angegebenen Steuersatz übereinstimmt (BMF-Schreiben vom 15. Oktober 2025). Verstößt eine Rechnung gegen die Pflichtangaben nach § 14 Abs. 4 UStG, ist sie nicht ordnungsmäßig, und solche Inhaltsfehler können bei der Validierung als Verletzung einer Geschäftsregel auffallen (BMF-Schreiben vom 15. Oktober 2025).

Für den Empfänger hält das Schreiben fest, dass eine Validierung die Prüfung der Rechnung unterstützt, aber nicht ersetzt. Auf das technische Ergebnis einer geeigneten Validierungsanwendung kann sich ein Unternehmer bei Beachtung der Sorgfaltspflichten eines ordentlichen Kaufmanns verlassen, und zum Nachweis bietet es sich an, den Validierungsbericht aufzubewahren (BMF-Schreiben vom 15. Oktober 2025). Ihr Geschäftskunde kann Ihre Rechnung also maschinell prüfen und sich auf das Ergebnis stützen. Für den Rechnungsausgang folgt daraus: Jede E-Rechnung wird vor dem Versand validiert, und der Bericht wird mit der Rechnung abgelegt. Zusätzlich lohnt eine eigene, strenge Prüfung von BR-CO-17 ohne Spielraum. Sie zeigt, wo Ihr Rechenweg von der Regelbeschreibung abweicht, bevor ein Kunde mit einer strengeren Prüfung es tut.

Bis zum 1. Januar 2027 bleiben für die Umstellung nur wenige Wochen. Wer die Rechenwege vorher nicht angleicht, merkt die Differenzen oft erst am Monatsende im Zahlungsabgleich. Unsere Arbeit rund um die E-Rechnung setzt genau hier an: Rechenweg festlegen, Schnittstelle anpassen, Testfälle durchlaufen und den Rechnungsausgang validieren. Für eigene Prüf- und Rechendienste zwischen den Systemen ist die API-Entwicklung der passende Einstieg.