Documents · Freelance Invoice Tool
Calculating Invoice Totals Correctly: Rounding, Tax and Floating Point
· How it works
invoice javascript validation
A one-cent mismatch between your invoice and a client's system usually comes from where rounding happens, not from a wrong rate. This post explains line-level versus total-level rounding, why computers get 0.1 + 0.2 wrong, and how to check any generator's arithmetic.
Off by one cent — the accounts-payable query that stalls an otherwise perfect invoice
A one-minor-unit mismatch is enough for two systems to disagree even when quantity, price and rate appear identical. The cause can be calculation order, a different rounding mode or a different taxable base. Resolve it by comparing methods step by step rather than manually changing the final total.
Where rounding happens — computing tax per line and summing, versus summing first and taxing once, and why the results differ
The shipped model rounds each line gross from unit price times quantity, applies and rounds line discounts, sums line nets, applies the overall discount, allocates that discount across taxable lines, then calculates tax on the discounted taxable base. A system that taxes each line independently can differ.
Why 0.1 + 0.2 is not 0.3 in JavaScript — binary floating point and the case for calculating in whole minor units
JavaScript binary numbers cannot represent every decimal exactly, which is why a direct 0.1 plus 0.2 comparison surprises people. The money module parses decimal text into whole minor units and uses BigInt rational arithmetic for multiplication, division and percentages instead of carrying binary fractions through totals.
Rounding modes — half up, half even and truncation, and why the choice must be consistent across the document
The module supports half-up, half-even, up and down modes, with half-up as the document default. Consistency matters because a tie handled differently at line, discount or tax stage changes later inputs. The tests exercise positive and negative ties instead of assuming one direction from a friendly example.
Currencies with zero or three decimals — why yen and some Gulf currencies break assumptions built for cents
The outline mentions currencies with three decimals, but the current registry contains zero-minor-unit currencies and two-minor-unit currencies only. The implementation still derives precision from currency metadata rather than assuming cents, so whole-unit currencies do not acquire artificial decimal places.
Worked example — three billed items at an awkward tax rate, computed both ways, with the cent difference explained
For three awkward line amounts, compare the tool’s displayed subtotal, line discounts, invoice discount, taxable base, tax and total with the client’s stages. Do not merely compare the last number: the first stage that differs identifies whether the dispute is parsing, rounding, allocation or tax-base selection.
What this does not cover — which rate applies to you, or how your client's system rounds; agree the method if it matters
The arithmetic cannot decide which rate applies, whether a line is legally taxable or how another accounting system rounds. The tool requires tax confirmation and implements only one rate per document. Agreement on method remains a business and compliance question outside the calculator.
Takeaway — check totals against the method your client expects, then let the Freelance Invoice Tool produce the clean PDF
Keep prices as entered decimal text, choose one rounding mode and compare the full calculation chain when systems disagree. The Freelance Invoice Tool provides deterministic minor-unit arithmetic and a readable PDF, but it does not make a client’s different method incorrect by definition.