RemitInvoice Maker

Remit is a free, private invoice maker that runs in your browser. You type the job on the left, see the finished invoice on the right at true size, and save it as a PDF through the print dialog. No account, and your client list stays on your machine.

"Download PDF" is the browser print dialog, so headers, footers, and margins depend on the user's browser settings. Tax is a taxable flag per line plus invoice-level rates, which doesn't fit VAT setups with two rates on one invoice. Tested by automated checks and a hand-checked sample, not by anyone's real billing.

This was part of the bulk one-shot night, about half an hour of work from Claude Code. I wanted a real invoicing tool, not a form that prints, with money math an accountant wouldn't flinch at. That meant discounts, mixed taxable and non-taxable lines, deposits, multiple tax rates, and currencies that don't have two decimals. My rules were the usual ones: one tested logic core, no dependencies, dark and light themes.

Claude Code wrote invoice.js (parsing, integer math, totals, numbering, dates, overdue status, validation, import and export), the 168 tests, the UI with four templates and a print stylesheet, and the static server.

The first session got interrupted after the app, tests, and screenshots existed but before any write-up. So nothing about the build was captured yet. The next day a second Claude Code session re-ran the tests (168 of 168), re-checked the sample invoice by hand against the rendered sheet (subtotal 11,178.50, tax 44.20, total 10,711.77, balance 8,211.77), confirmed both themes served, and wrote the docs from the actual code rather than from memory of the plan. No failing tests or broken renders turned up on that pass.

• Money code should never see a float. 19.99 * 100 is 1998.9999999999998 in JavaScript. So amounts get parsed from the typed string into whole cents (or whatever the smallest unit is), and rates are kept as whole basis points.
• An invoice-level discount can't just come off the subtotal when only some lines are taxable. It has to be split across lines, and naive rounding leaves the parts a cent off. The largest remainder method guarantees the shares add up exactly, so the taxable base is right to the cent.
• "Two decimals" is a US assumption. Yen has zero and Kuwaiti dinar has three, so the digit count is a parameter of every parse and format call.
• Due-date math is safest in UTC. Adding whole days in UTC avoids the daylight-saving drift that can shift a Net 30 due date by a day. Also, @page { size } can't read a CSS variable, so the app rewrites a dedicated style tag when the paper size changes.

Same tested-core pattern from #9 onward: invoice.js imported by both the page and verify.mjs, so the shipped code is the tested code. It's one of four builds in this range finished by a fresh session reading the folder, which is why the one-folder-per-project setup paid off. Next door, #19 handled money differently with EPSILON-safe rounding instead of integer units. Both work for their job, but this one is the stricter approach.

I'd store tax as a per-line rate and add a real PDF writer so it's one click to a file that looks the same everywhere.