0.1 + 0.2 doesn't equal 0.3. If your billing code uses floats, you're already losing money.

0.1 + 0.2 doesn't equal 0.3. If your billing code uses floating-point for money, you're already losing money. You just haven't reconciled the books yet.

I built an e-invoicing engine that submits legally binding tax documents to Costa Rica's Hacienda and Mexico's CFDI systems. When a government rejects your invoice because the total is off by a fraction of a cent, "close enough" is not a defense.

So every amount in that engine is an integer in minor units. No floats touch money. Ever. Rounding is explicit and happens once, at the edge, where a human can see it. The core carries roughly 230 tests, because tax authorities don't grade on a curve.

This is the unglamorous stuff that separates software that demos well from software that survives an audit. Anyone can render a price on a screen. Making the number correct across currencies, rounding rules, and a foreign tax API is the actual job.

If your product touches money, whether that's invoices, payouts, or marketplaces, the integer-money discipline is non-negotiable. Most codebases get it wrong.

Want the pattern I use? Reply and I'll share how I structure it.