Your money should jiggle jiggle not fold

Trigger warning, IEEE 754. If you’ve ever handled money irrespective of language or framework you know each and every word of this standard. See, the point of a financial system is precision, reliability, and scale.

A bank calculates compound interest on your savings account daily. The daily interest rate on a small account (like mine, cause I am broke) might be $0.004123. Now, you can’t really represent $0.004123 on your machine because it uses base 2 whereas us humans use base 10. So what’s the solution?

Use integers to store your money

You should be taking the amount and multiplying it by 100 and storing it as cents. It’s just that simple. End of blog right? Might as well have been a tweet. Well, no. Let me introduce micros.

Micros

You ever wonder how AWS can charge you $0.00381 for compute? Well, the keen amongst you might have noticed you can’t accurately represent numbers like this using standard floats. So if multiplying by 100 isn’t the catch-all solution, what is?

First, there’s no such thing as a catch-all solution. Stop with this line of thinking. Second, you can multiply by 100, 1,000, 10,000, or even 1,000,000 until you reach the exact level of precision your business requires.

This is also where engineering directly drives business decisions. Say your user accumulates a cashback reward of $0.004123 USD. How do you credit that to their bank account? API providers like Stripe, Razorpay, or even traditional banks do not support micros over the wire. In this case, you have to tell your boss that the product needs a minimum redemption threshold, a rule that ensures payouts scale up to a whole amount that the banking APIs can actually honour.

Pro Tips

• Always use Big Int when storing your money. A normal Int is just 10⁶ , that way you can support upto $9 trillion even when scaled by a million.
• When you multiply two scaled integers, you must immediately divide the result by your scaling factor to normalize it back to micros.
• When serializing for Frontend or Mobile, standard JSON parsers might convert large numbers into floats. You should pass financial values across your internal microservices as Strings or explicit Integers. Never let a raw unformatted decimal hit your network until it is purely text on screen.

The Decimal(10, 6) argument

Decimal column type was litreally built to avoid the rounding bugs of standard floats, so why not use it? What did I just say about catch all solutions to you? See, the Decimal comes with its own headaches for high throughput systems.

Your CPU is designed for ints, it can multiply integers in a single cycle. DECIMAL is aribitrary-precision math simulated entirely in software. The DB litreally handles the math like string manipulation, digit by digit. In high frequency ledger processing millions of records, DECIMAL calculations heavily spike DB CPU compared to BIGINT.

Furthermore, DECIMAL has to play nice across languages, DB drivers, and ORMs. Many times, these drivers automatically deserialize a DB decimal into a raw application Float or Double. The exact moment that number hits your application code, the leaky binary tails return instantly.

Also, DECIMAL(10, 6) in its very essence a hard constraint. When your CEO decides to support a hyper fractional asset like BTC, which scales to 8 decimal places, a global DB migration to alter DECIMAL columns on billions of ledger entries.

Currency-Specific Quirks

Integers work, but assuming every currency has two decimal places like the US dollar is a massive rookie mistake. Your database architecture needs to know exactly what currency it is looking at because the world does not standardise on cents.

The Edge Cases: Zero Fractional Units to Crypto

If you write global payment code, you will hit weird edge cases immediately. Currencies like the Japanese Yen (JPY) or Chilean Peso (CLP) have absolutely no fractional units, one Yen is just one Yen. On the flip side, currencies like the Kuwaiti Dinar (KWD) use three decimal places, meaning its smallest unit is a fils, or 1/1000th of a Dinar. Then you look at cryptocurrencies, Bitcoin scales out to 8 decimal places for a Satoshi, and Ethereum goes all the way out to 18 decimal places for a Wei. If you apply a flat 100x or 1,000,000x multiplier across all these assets blindly, your ledger will corrupt data and blow up your system on day one. Your backend must store an explicit exponent or asset scale config dynamically alongside the currency type.

Rounding Modes

When you do math with scaled integers, fractions still happen, and you have to decide exactly how to round them. You cannot just use floor or ceiling rounding blindly because that creates systematic bias, either favoring the house or cheating the user across millions of ledger entries. You have to write explicit code to handle different rounding modes, like truncating toward zero, rounding up, or using half-up rounding. Most enterprise financial systems force you to use half-to-even rounding, which cuts down cumulative rounding bias across your database.

Tax and Regulatory Implications

Integers solve your physical computer storage problem, but they do not solve accounting law. This is a massive legal blind spot for developers who think integers are a magical cure. Financial platforms must comply with strict corporate regulations like GAAP or IFRS, which legally mandate how tax calculations and financial statements are computed and rounded. If your system arbitrarily drops fractional remainders without keeping an audit trail, your books will not balance, you will fail a corporate regulatory audit, and your company will face serious legal compliance issues.

Code Examples

Stop overcomplicating scaled integer math, here is a clean Python example showing how to calculate a cashback reward using micros without touching a single float or causing rounding bias:

# Define our micro scale factor (10^6)
SCALE_FACTOR = 1000000

# \$10.05 stored as a perfect micro integer
user_balance_micros = 10050000

# A 1.5% cashback rate scaled up to an integer
cashback_rate_micros = 15000

# Step 1: Multiply integers directly on the CPU hardware
raw_product = user_balance_micros * cashback_rate_micros

# Step 2: Divide by the scale factor, adding half the scale factor first to handle half-up rounding accurately
cashback_earned_micros = (raw_product + (SCALE_FACTOR // 2)) // SCALE_FACTOR

print(cashback_earned_micros)  # Outputs: 150750 (which is exactly 15.075 cents)

Summary

Don’t store your money as Floats, use Big Int. Decimal is a lie created to gaslight you into thinking catch all solutions exists, they simply don’t. Good Luck!