Why fixed VAT-inclusive prices can cause e-invoice rounding problems

As of 18 October 2026. This article explains invoice arithmetic, not whether a particular invoice complies with national tax law.

The agreed price is €9.99, including VAT. Your invoicing software works backwards to find the price before tax, rounds it to cents, then calculates VAT on that amount. The result is €10.00.

Nothing was mistyped. The extra cent appears because rounding takes place at two different steps. If your prices are fixed inclusive of VAT, exporting an e-invoice involves more than putting each amount into the right XML field.

This is also an issue for the standards themselves. FeRD has announced support for VAT-inclusive invoice calculations as part of ZUGFeRD’s development. A single invoice line is enough to show why that work matters.

Where the extra cent comes from

Take one item, on one invoice line, at a VAT rate of 20%, with no allowances or charges. For this arithmetic example, round the amount before VAT to two decimal places using ordinary half-up rounding:

Calculation	Amount
Fixed price including VAT	€9.99
Amount before VAT: 9.99 ÷ 1.20	€8.325
Amount before VAT, rounded to cents	€8.33
20% of 8.33, rounded to cents	€1.67
Net amount plus recalculated VAT	€10.00

If VAT is instead taken as the difference between the fixed price and the rounded net amount, it comes to €9.99 − €8.33 = €1.66. The two calculation routes produce different VAT amounts.

This is not a recommendation to use either method for tax purposes. It demonstrates that reversing a VAT-inclusive price and then rebuilding it need not return the original amount once rounding is involved. Using exact decimal arithmetic does not remove that difference.

Structured invoices specify how the totals relate

Peppol BIS Billing, based on EN 16931, builds the invoice from amounts excluding VAT. Net line amounts, allowances and charges determine the taxable amounts. VAT is broken down by category and rate; the tax-inclusive invoice total is then calculated from those figures. OpenPeppol: Invoice calculations

Rule BR-CO-17 defines the VAT amount for a category as its taxable amount multiplied by the rate, rounded to two decimal places. Applied to our example, that calculation gives €1.67 in VAT. OpenPeppol: BR-CO-17

This does not mean that all VAT-inclusive prices cause trouble, or that a validator will necessarily reject this particular one-cent difference. Validation rules can allow tolerances, and the outcome depends on the rules being applied. Passing validation does not, by itself, prove that the original pricing calculation has been preserved.

More decimal places only solve part of the problem

A unit price is not the same as an invoice line net amount. Peppol allows unit prices to carry more than two decimal places. A line’s net amount, however, is limited to two. OpenPeppol: Line net amount and decimal limits

You can therefore record a unit price of €8.325 in this example. With a quantity of one, the line amount still has to be expressed in cents. Extra precision in the unit price does not eliminate that rounding step.

For larger quantities, retaining extra price decimals can be useful. It is not a universal fix for every VAT-inclusive price. What matters is where rounding occurs: at the unit price, the line amount, or the VAT calculated on the combined taxable amount.

A payment adjustment is not a VAT correction

The invoice model has a separate rounding amount, BT-114. It adjusts the amount due for payment: the tax-inclusive invoice total, less any amount already paid, plus the rounding amount. OpenPeppol: Amount due, BR-CO-16

In arithmetic terms, a rounding amount of −€0.01 would bring our €10.00 total down to a payment of €9.99. But the net amount would still be €8.33 and VAT would still be €1.67. The adjustment does not recalculate either of them.

That distinction matters when software offers to “fix rounding”. Ask whether it changes only the amount due or also recalculates the underlying lines and VAT. The figures must remain explainable. Having an adjustment field is not blanket permission to resolve tax discrepancies through it.

“Gross price” does not mean VAT-inclusive here

One field name makes this particularly easy to misunderstand. Item gross price, BT-148, means the unit price before an item price discount, excluding VAT. It is not the price including tax. OpenPeppol: Definition of BT-148

If your stock or billing system uses “gross price” to mean VAT-inclusive, copying that value into BT-148 because the labels match can produce the wrong invoice. Match the meaning of the fields, not just their names.

What ZUGFeRD has announced

On 19 May 2026, FeRD split the planned ZUGFeRD release into two stages. Support for what it calls Bruttorechnungen was assigned to the later stage. FeRD cited additional requirements from the revision of EN 16931 and the testing work they required. FeRD: Two-stage release announcement, in German

The publication for ZUGFeRD 2.5.2, dated 4 August 2026, still describes that support as an expected feature of a subsequent release, provisionally in autumn 2026. That is a roadmap statement, not evidence that your invoicing software already implements it. FeRD: ZUGFeRD 2.5.2 and planned developments, in German

Neither announcement establishes that every recipient can process such an extension. That requires an identified version, a supported profile and compatible implementations at both ends.

Four questions to ask your software provider

If you set prices inclusive of VAT, these questions are more useful than asking whether the product “supports e-invoicing”:

• What does entering a VAT-inclusive price actually do? Does that final price remain authoritative, or does the software merely convert it to a net unit price?
• Where does rounding happen? Ask to see the unit price, line amount, VAT and amount due for the same invoice.
• Where does a difference go? Is a rounding adjustment explicitly recorded, and which figures does it change?
• What does the recipient accept? Agree the format, version and profile rather than relying on a general claim of compatibility.

A useful export test compares more than the final amount on screen. Compare the net lines, VAT breakdown and amount due in the structured data with the original invoice. Both totals can say €9.99 while the figures underneath are different.

Further reading: How the e-invoice formats differ and why changing requirements also change XRechnung’s data model.