Invoice Generator

**The first is that the column adds up.** Whoever pays an invoice adds the line amounts and checks them against the subtotal, then adds the subtotal and the tax and checks them against the total. A tool that keeps an unrounded figure and rounds each printed number independently produces a column that does not add up: the version of this tool that shipped before September 2026 printed three lines of $0.38 under a subtotal of $1.13, and on a measured corpus of twelve ordinary invoices, ten of eighteen printed lines did not equal their own printed quantity times their own printed unit price. Everything here is computed on integers counting the minor unit, and **the subtotal is the sum of the rounded line amounts** rather than the rounding of an unrounded sum, which is the only arrangement in which a column agrees with its own footer. The page re-reads its own printed strings, adds them again, and shows you the result of that check.

**The second is the number of decimal places, which belongs to the currency and is not always two.** ISO 4217 calls it the minor unit. The Japanese yen and the Korean won have none, the Bahraini and Tunisian dinar have three. The figure comes from CLDR through the browser own `Intl`, so a yen invoice reads ¥100 and not ¥100.00.

**The third is when the discount comes off.** A price discount granted to the customer at the time of supply is excluded from the taxable amount by article 79 of the EU VAT Directive, and US sales tax works the same way, so tax is charged on the discounted figure by default and the page names the amount it was charged on. Charging tax on the full subtotal instead overcharges by the tax on the discount: 2.00 on a 100 invoice with 20 percent tax and a 10 discount. The other order is offered, because a settlement discount or a third-party-funded one can genuinely fall outside the taxable supply, but it has to be chosen by name.

**The fourth is what a PDF can actually write.** A PDF drawn with one of the standard 14 fonts carries the WinAnsi encoding, which is 218 characters: printable ASCII, Latin-1, and 27 more. The Indian rupee sign is not among them, and neither is any Greek, Cyrillic or CJK letter, and pdf-lib throws rather than dropping a character. Measured across twelve ordinary invoices, five produced no file at all: a rupee invoice, and clients named in Polish, Greek, Chinese and Turkish, each ending in a bare "Failed to generate PDF". Now the page tells you what cannot be drawn BEFORE you click, substitutes the nearest Latin form where there is one, falls back from an unwritable currency symbol to its ISO 4217 code, which is always ASCII, and writes the file.

Quantities may be fractional to three decimal places, which is what an hourly invoice needs: 2.5 hours at 100 an hour bills 250, where reading the quantity with `parseInt` billed 200. A unit price may be finer than the currency, up to six places, because a per-unit rate genuinely is quoted below the minor unit, and the price is printed at the precision it was given while only the line amount is rounded. Show working prints the product before rounding, how far rounding moved each line, and what the tax was charged on.

Every figure the page produces is checked in the project tests against a second implementation of the arithmetic written in Python decimal from the same definitions: 146 invoices across four currencies and both tax orders in the module tests, and sixteen more driven through the browser, with no disagreements. What the PDF says is read back out of the file by two independent readers, poppler pdftotext and pypdf.