Sowohl für jede Rechnungszeile als auch für den Gesamtbetrag sollten eindeutige Rechenregeln definiert werden, da diese in der Praxis unterschiedlich interpretiert werden. D.h. pro Rechnungszeile sollte definiert werden, wie der LineItemAmount zustande kommt, und auf globaler Ebene sollte definiert werden, wie der TotalGrossAmount zustande kommt. Diese Regeln sollten sowohl für ebInterface 3.0.x als auch für ebInterface 4.0 definiert werden.
In den Regeln berücksichtigt ist ein optionales Feld “BaseAmount” mit dem Standardwert “1”. Dieses kann verwendet werden, wenn Elemente in bestimmten Verpackungseinheiten (z.B: 1000) verkauft werden. Dadurch kann verhindert werden, dass sich der Einzelpreis nicht mehr mit 4 Dezimalstellen ausdrücken lässt.
Vorschläge seitens des BRZs, die aber noch auf das steuerrechtliche Approval vom BMF warten:
LineItemAmount:
- UnitNetAmount / BaseAmount * Amount +- (Reduction/Surcharge in der angegebenen Reihenfolge)
- Das Ergebnis auf 2 Dezimalstellen im definierten Rundungsmodus runden
LineItemGrossAmount:
- Ungerundeter LineItemAmount * (100 + TaxRate) / 100
- Das Ergebnis auf 2 Dezimalstellen im definierten Rundungsmodus runden
TotalRoundingAmount:
- Summe(ungerundeter LineItemGrossAmount) - Summe(gerundeter LineItemGrossAmount)
- Das Ergebnis auf 2 Dezimalstellen im definierten Rundungsmodus runden
TotalGrossAmount:
- Summe(gerundeter LineItemGrossAmount) +- (Reduction/Surcharge in der angegebenen Reihenfolge) + TotalRoundingAmount
- Das Ergebnis auf 2 Dezimalstellen im definierten Rundungsmodus runden
Das bedingt, dass es auf globaler Ebene ein neues Element "TotalRoundingAmount" geben muss, in dem optional Rundungsdifferenzen abgelegt werden können.
Außerdem wäre in diesem Zusammenhang ein Element "LineItemGrossAmount" auf Zeilenebene hilfreich.
Zusätzlich sollte es eine Definition des zu verwendenden Rundungsmodus werden, aber auch hier sollte eine Aussage vom BMF kommen.
Der Bund verwendet derzeit den Modus „HALF_UP“ der bei uns wie folgt definiert ist:
- Rounding mode to round towards "nearest neighbor" unless both neighbors are equidistant, in which case round up. Behaves as for RoundingMode.UP if the discarded fraction is >= 0.5; otherwise, behaves as for RoundingMode.DOWN. Note that this is the rounding mode commonly taught at school.
International üblich ist der Rundungsmodus “HALF_EVEN”:
- Rounding mode to round towards the "nearest neighbor" unless both neighbors are equidistant, in which case, round towards the even neighbor. Behaves as for RoundingMode.HALF_UP if the digit to the left of the discarded fraction is odd; behaves as for RoundingMode.HALF_DOWN if it's even. Note that this is the rounding mode that statistically minimizes cumulative error when applied repeatedly over a sequence of calculations. It is sometimes known as "Banker's rounding," and is chiefly used in the USA. This rounding mode is analogous to the rounding policy used for float and double arithmetic in Java.
Update 16:58: Folgende Infos habe ich auf BMF-Seiten gefunden:
Quelle: https://findok.bmf.gv.at/findok/freie_suche.do mit dem Suchwort „rundung“ und der betroffenen Norm „§ 11 ustg“
11.1.5.6.4. Auf- und Abrundung
1516
Über die Auf- oder Abrundung der USt bei der Rechnungserteilung enthält das Steuerrecht keine besonderen Vorschriften. Die USt muss daher vom Unternehmer für die von ihm ausgeführten steuerpflichtigen Leistungen genau berechnet werden. Soweit in einer Rechnung der Steuerbetrag oder der Rechnungsendbetrag (der zivilrechtliche Preis) auf- oder abgerundet wurde, hat dies für die Höhe der Steuerschuld keine Bedeutung bzw. ist § 11 Abs. 12 UStG 1994 sinngemäß anzuwenden.
Siehe auch EURO-Einführungserlass, AÖF Nr. 019/1999.
Update 12.8.2013: nach Auskunft des BMF soll immer kaufmännisch gerundet werden, also nach dem "HALF_UP" Modus!
vg P. Helger