The missing cent
You add up the lines, the client's accounts department adds up the lines, and the two totals differ by a cent. Nobody has made an arithmetic mistake. Two things cause this — rounding at a different moment, and the way computers store decimal fractions — and both are avoidable once you know where they bite.
Money is not a decimal number, it is an integer of cents
Computers store 0.1 and 0.2 as binary fractions that are very close but not exact, so 0.1 plus 0.2 does not equal 0.3 in most programming languages. On one line nobody notices. Across forty lines and a tax calculation, the error accumulates into a visible cent. The app never holds an amount as a decimal: every price becomes a whole number of cents the moment it is entered, all arithmetic happens on integers, and the amount is converted back for display only. That is the difference between a total that is right and a total that is right most of the time.
Rounding once, in one place
The second source is subtler. Take three lines of 3 items at 0.335 each. Round each line first and you get 1.01 three times, totalling 3.03. Add first and round once and you get 3.02. Neither is wrong arithmetically; they are answers to different questions. What is wrong is doing both in the same document — rounding lines for display but totalling the unrounded values, which produces an invoice where the visible lines genuinely do not add up to the visible total. The app rounds once, per line, and then adds the rounded lines, so what you see printed is what was summed.
Where discounts hide a cent
A percentage discount on a total does not divide evenly across lines. Ten per cent off three lines of 3.33 is 0.999 — a third of a cent per line, which cannot be printed. If you round each line's share down you lose a cent from the total; if you round each up you gain one. The app calculates the discount on the subtotal, then distributes it across the lines and puts the remainder on one of them, so the sum of the discounted lines equals the discounted subtotal exactly. There is no elegant answer to this problem — only the discipline of making the visible numbers consistent.
Currencies without cents
Not every currency has two decimals. The Japanese yen has none: an amount is a whole number of yen and there is no minor unit to round to. A system that hardcodes two decimals produces prices like ¥1,250.00, which is not how yen is written, and worse, rounds to a hundredth of a unit that does not exist. The app stores the number of decimals per currency and rounds to that, so a yen invoice rounds to whole yen and a dollar invoice to cents.
Frequently asked questions
Why does my invoice total differ by one cent from my spreadsheet?
Usually because one of you rounds each line and the other rounds only the total. Both are defensible; mixing them within one document is not.
Should I round per line or on the total?
Per line, and then add the rounded lines — that way the printed lines visibly add up to the printed total. Some tax regimes have a preference, so check yours if the amounts are large.
Is 0.1 + 0.2 really not 0.3?
In binary floating point, no — it is 0.30000000000000004. That is why money should be handled as whole cents, which is what the app does.
Why does a percentage discount leave a remainder?
Because a percentage of a total rarely divides evenly into whole cents across the lines. The remainder has to land on one line; the app places it so the lines still sum to the discounted subtotal.
How does the app handle the Japanese yen?
As a zero-decimal currency: amounts are whole yen, with no minor unit and no cent rounding.
Can I just fix the total by hand?
Do not. A total that does not equal the sum of the lines is the first thing a reviewer notices. Fix the rounding rule instead.
Invoices where the totals actually add up. Invoice Maker builds invoices, proformas, quotes and receipts in your browser, does the money in whole cents so the VAT line never drifts, and exports a PDF. Nothing is uploaded.
Make an invoice in the browser