04.01 · Concept · Free
Never Store Money in a Float
Store an amount as an integer in its currency's minor unit, and handle the currencies that have three decimal places or none.
Curated for this lesson1/3
Money in Your Database
Floating Point Numbers (Part1: Fp vs Fixed) - Computerphile
Directly contrasts floating-point and fixed-point, the key distinction behind storing money as integer minor units.
Money belongs in integer minor units, paired with a currency code, not in floating-point columns. Binary floats are approximate and can make decimal amounts drift during arithmetic. The correct scale depends on the currency: some use the familiar minor unit, some have none, and some require three decimal places.
What this lesson answers
- why not store money as a float
- how to store currency amounts in database
- how handle currencies without two decimal places
Notes
Money should not be stored as a floating-point number because floats are designed for approximate scientific measurement, not exact decimal accounting. Values like 0.1 or 19.99 often cannot be represented exactly in binary floating point, so repeated arithmetic can produce tiny errors that become visible in balances, invoices, tax totals, or reconciliation checks.
The practical model is to store money as an integer count of the currency’s minor unit. Store USD 12.34 as 1234 cents, JPY 500 as 500 yen because it has no decimal minor unit, and KWD 1.234 as 1234 fils because it has three decimal places. Keep the currency code alongside the amount, because the integer alone is meaningless without knowing which currency’s minor unit it uses.
A common misconception is that rounding the float before saving, or using a database decimal display format, makes floats safe for money. It does not fix the core problem: the computation may already have used approximate binary values, and different languages, databases, or serialization paths can expose slightly different results. If exactness matters, use integers for storage and exact decimal or integer arithmetic for calculations.
After this lesson, the student should be able to design a money column as something like amount_minor_units plus currency, choose the correct scale from currency metadata, and avoid hard-coding “two decimal places” globally. They should also recognize that formatting for humans, such as showing 1234 as “$12.34”, is a presentation concern separate from the stored representation.
References
Common questions
- Why are floats unsafe for storing money?
- Floats represent many decimal values approximately because they use binary floating-point encoding. That is acceptable for measurement, but not for accounting. Small representation errors can appear after addition, tax calculation, discounting, serialisation, or reconciliation, causing amounts that should match exactly to differ.
- What should a money column store instead?
- Store the amount as an integer count of the currency’s minor unit, and store the currency code beside it. The integer is not self-describing: the same stored value means different human amounts depending on whether the currency has a minor unit, no minor unit, or three decimal places.
- Is rounding a float before saving good enough?
- No. Rounding at the boundary does not make the earlier arithmetic exact, and different runtimes, databases, or API serialisation paths can expose the approximation differently. Use integer or exact decimal arithmetic for calculations, then persist integer minor units with the currency metadata needed to interpret them.
Short definition: what is Never Store Money in a Float?