Why every price in our billing is an integer of micro-dollars
A micro-dollar is a millionth of a dollar, which makes a cent ten thousand of them. Every amount in this billing system is an integer number of micro-dollars — a run-minute costs some whole number of them, well under a cent — and nothing is ever expressed as a decimal, anywhere, at any point.
That reads like fastidiousness until you look at the shape of the arithmetic. A month’s invoice is the sum of thousands of values each individually smaller than a cent. Cents cannot be the working unit — you would round every line to zero. And a double accumulates error you do not discover in a test; you discover it when a customer’s invoice disagrees with the ledger by one cent that neither side can explain.
Integers all the way down
So: bigint in TypeScript, BIGINT in Postgres, billing.Micros in Go. Never a float, never a JavaScript number. The arithmetic lives in one module, and the pricing page’s estimator imports that module rather than re-deriving the sums — because the alternative is two implementations of the same formula, and one of them being wrong is a matter of time.
The rounding has to happen exactly once
Somewhere a total of micro-dollars becomes a charge in cents, because that is what a card network accepts. Doing it per line and summing gives a different answer from summing and doing it once, and the difference is real money in the aggregate. So the split is explicit and the remainder is kept:
That is not a comment. It is a CHECK constraint on the invoices table. The database refuses to store an invoice whose parts do not reconcile, and the function that rebuilds a draft invoice re-adds the lines and refuses a set that does not sum. Two independent implementations of the same arithmetic — one in the application, one in the schema — have to agree before a row exists.
Why a property test rather than examples
The failure mode here is not “this case is wrong”, it is “the allocated cents do not add up to the total”, which example-based tests find only if you happened to pick the example. So the test asserts the property directly, over generated inputs: however the amount is split across lines, the cents allocated always sum to the invoice total. It has caught exactly the thing it was written for.
None of this is clever. It is the boring version, chosen because the interesting version fails in front of a customer. The prices themselves are on the pricing page, read from the rows that do the billing.