Rounding, VAT and Peppol: why one cent can make a difference
An invoice shows one total in an ERP system, while an e-commerce platform or accounting application arrives at a figure that differs by one cent. Which system is wrong?
In many cases, neither.
A one-cent difference may simply result from the point at which each system rounds prices, discounts, taxable amounts and VAT. With the increasing adoption of structured electronic invoicing — particularly through Peppol and models based on the European EN 16931 standard — these small differences are no longer merely a matter of presentation: they can determine whether or not a document is accepted by another system.
This is why Gestix totalises invoices within the ERP itself rather than delegating the calculation to the application communicating with the API.
An invoice is more than quantity × price + VAT
The calculation may appear simple:
Quantity × Price − Discounts + VAT = Total
In practice, several decisions have to be made along the way.
Does the price include VAT? Are there multiple successive discounts on the line? Is there an overall document discount? Is that discount a percentage or an amount? At what point should rounding take place? Is VAT calculated line by line or on accumulated amounts?
Two applications can use exactly the same prices, quantities, discounts and VAT rates and still arrive at slightly different totals.
A particularly interesting case occurs when prices already include VAT.
An example: €24.95 with a 30.63% discount
Consider one unit with:
- VAT-inclusive price: €24.95
- discount: 30.63%
- VAT: 21%
After applying the discount, the gross line amount is:
24.95 × 0.6937 = €17.307815
Rounded to cents:
€17.31
To determine the corresponding taxable amount:
(24.95 × 0.6937) ÷ 1.21 = €14.303979…
Rounded to cents:
€14.30
The VAT amount for the line is then determined by the difference:
€17.31 − €14.30 = €3.01
It may seem like an insignificant detail. It is not.
If another application first rounds the gross amount and then recalculates VAT from that already-rounded figure, it may, in certain cases, arrive at a different result.
Multiply that difference across several invoice lines, different VAT rates, discounts and allowances, and it becomes easy to understand why two systems can disagree on the totals of the same invoice.
EN 16931 and the importance of line-level calculation
Structured electronic invoicing has made this issue particularly relevant.
The European EN 16931 standard, used throughout the European e-invoicing ecosystem and in Peppol implementations, defines a rigorous semantic model for the values that make up an invoice.
It is not enough for the final total simply to “look right”. Line amounts, taxable amounts, taxes, discounts and totals must be consistent with one another and comply with the validation rules applicable to the electronic document.
Gestix therefore uses a calculation model that transforms the document’s commercial data — including VAT-inclusive prices, discounts and allowances — into the net amounts, taxable amounts, taxes and totals required by the EN 16931 model and Peppol interoperability rules.
Under this model, each line is totalised individually, and the resulting rounded values are subsequently used to build the VAT subtotals and document totals.
This reduces one of the classic causes of one-cent discrepancies: using rounding strategies that differ from those required to maintain consistency between line amounts, taxable amounts, VAT subtotals and the totals required by the interoperability model.
Three line discounts are not a single discount
There is another frequent source of discrepancies in integrations.
Gestix can apply multiple successive discounts to an invoice line. These discounts are cumulative rather than additive.
For example, a 10% discount followed by a 5% discount does not amount to a 15% discount.
The calculation is:
0.90 × 0.95 = 0.855
The effective discount is therefore 14.5%.
This distinction is particularly important for integrations with online stores, commercial platforms and external applications that create documents through the Gestix API.
If the external system simply adds the percentages together, its calculated values will no longer match those of Gestix.
What about document-level discounts?
Discounts applied to the document as a whole add another dimension to the problem.
An overall discount may affect different taxable amounts when the document contains lines subject to different VAT rates. It is therefore necessary to determine correctly the portion of the discount associated with each VAT category and rate.
Under the EN 16931/Peppol model, document-level discounts are identified as such and taken into account when determining the taxable amount for the corresponding VAT category.
Internally, Gestix performs the calculations and adjustments necessary to preserve consistency between the document’s commercial values, taxable amounts, VAT subtotals and final total.
Where necessary, residual differences caused by rounding must also be handled in a controlled manner rather than simply disappearing or altering the intended document total.
The API provides the commercial data; Gestix calculates the totals
This leads to an important rule for applications integrating with Gestix.
An application creating an invoice through the API should primarily provide the commercial data from which the document is built: quantities, prices, discounts, VAT rates and any other applicable elements.
Invoice totalisation takes place on the Gestix server.
Once the document has been processed, the API returns the values actually calculated and persisted by the ERP, including the net amount, VAT, rounding and total.
This provides a single source of truth for the Gestix document.
The external application may, of course, perform its own calculations for display or verification purposes. It should not, however, assume that a calculation using a different rounding strategy will necessarily produce the same intermediate values.
ERP, API and Peppol speaking the same language
Interoperability is not merely about being able to transmit an XML file from one system to another.
Both systems must attribute the same meaning to the values contained in that file.
This is precisely why apparently minor questions such as when to round a cent matter in the evolution of Gestix.
Support for electronic invoicing and Peppol does not end with generating the electronic document. It starts earlier, with the calculation model that produces the values that will ultimately form part of that document.
By centralising invoice totalisation within the ERP and applying rules appropriate to different invoicing scenarios, Gestix aims to ensure that what is invoiced, what the API returns and what is transmitted electronically all represent the same commercial document.
Because in electronic invoicing, one cent is information too.
