Distinguish raw precision from line rounding

Two honest answers to one sum

Invoices, tax summaries and payroll often involve amounts with more decimals than the currency allows. One system adds the precise values and rounds the total; another rounds every line first and then adds. Both are legitimate, and they can disagree by a cent or more on the same data. Which one applies is set by the billing, tax or accounting rule behind the document, not by arithmetic.

The decimal totals checker adds exactly the strings you give it and never rounds. That makes it a good tool for seeing which stage a stated total used.

The gap tends to grow with the number of lines. Every line rounded up by a fraction of a cent adds to it, so a long invoice can differ by more than a cent between the two methods.

Working the 0.335 example

The page example enters 0.335 and 0.335 with an Expected total of 0.68. The Calculated total is 0.670, the Expected total is shown as 0.680 at the same scale, and the Difference is -0.010. Totals match shows No.

Now enter the lines as they would look after rounding each one to two places: 0.34 and 0.34. With the same Expected total of 0.68, the Calculated total is 0.68 and the Difference 0.00. The stated figure was produced by rounding every line before adding, not by rounding the sum.

Testing which stage was used

• Enter the lines with their full source precision first and note the Difference.
• Then enter the lines rounded the way the document's rule says, and calculate again.
• Compare both results with the stated total; the version that matches tells you the stage.
• Write down which rule you applied, so whoever reviews the figures can repeat it.
• If neither version matches, the gap is not a rounding question; look for a missing or misread line.

Precision traps to avoid

• Copying values from a spreadsheet column formatted to two decimals: the display may hide the third decimal you need for the precise run.
• Mixing pre-rounded and precise lines in one run.
• Treating a gap of -0.010 as an error to fix by adding a line; it is the expected result of a rounding choice.
• Assuming one rounding method. Half up, half even and truncation can give different line values; apply the method your rule names.
• In the Tablora app's XLSX export, amounts become real numbers in recognized number columns and cells with decimals use a two-decimal number format, so a value like 0.335 may display as 0.34 while the cell holds 0.335. Check the cell value, not just the display.

Original synthetic example

Values

0.335 0.335

Expected total

0.68

Calculated total

0.670

Calculated minus expected

-0.010

Tools

• decimal-totals-check