Building Loan Calculators That Survive an Audit, Not Just a Demo

Anyone can build an EMI calculator. The formula is one line — reducing-balance amortization, plug in principal, rate, tenure, done. I've seen it built as a homework assignment. The part that actually takes engineering effort is the part that never shows up in a product screenshot: making sure the number a customer sees today matches the number they'll see on their statement eleven months from now, and that you can prove why.

The first version of a loan amortization tool we built used standard JavaScript floats for interest calculations. It worked fine for round numbers. It started producing schedules where the final payment was off by ₹0.03 to ₹0.11 due to accumulated floating-point rounding across 240 monthly compounding periods. Nobody notices that in a demo. A compliance reviewer checking your amortization table against a manually calculated reference schedule notices immediately, and now you're explaining a rounding error instead of a feature.

The fix is boring and non-negotiable: financial calculations don't run in floating point. Every interest, principal, and balance computation gets done in fixed-point arithmetic — we use integer paise/cents internally and only convert to display currency at the render layer — and the rounding rule for the final payment (which absorbs whatever residual balance is left after n-1 equal installments) is applied explicitly, not left to whatever the last floating-point operation happens to produce.

The second thing that separates a demo calculator from a production one: every output needs an audit trail back to its inputs. When a customer disputes a payment amount eight months into a loan, "the calculator said so" is not an answer anyone can act on. What needs to exist is a stored calculation snapshot — the exact principal, rate, tenure, and calculation method used to generate that specific schedule, timestamped, immutable — separate from the live calculator that a prospect plays with on your marketing site.

This sounds like overkill until you've been in the room when a client's finance team asks for it after the fact, and the honest answer is "we didn't store that, we only stored the final schedule." That's a rebuild, not a patch.

Interest calculation conventions aren't universal. Some products compound monthly, some daily-reducing, some use a 360-day year, some use actual/365. A calculator hardcoded to one convention works fine until you need to support a second loan product with a different convention, and the temptation is to add an `if` statement. Do that three times and your calculator is an unreadable pile of conditional financial logic that nobody trusts to modify.

What holds up better is treating the compounding convention, day-count method, and rounding rule as configuration data per loan product, not code branches — a `LoanProductConfig` document that the calculation engine reads, rather than a `switch` statement the engine contains. New product, new config row. No redeploy, no risk of breaking product A while adding product B.

We won't tell a client "this calculator is compliant" as a blanket statement, because compliance isn't a property of code — it's a property of a code base plus a specific regulatory framework plus a specific jurisdiction, verified by people qualified to verify it. What we build is calculation logic that is *auditable*: correct arithmetic, stored provenance, and configuration instead of hardcoded assumptions. Whether that satisfies a specific regulator's specific requirement is a question for your compliance team, not your engineering vendor — and anyone who tells you otherwise without qualification is a bigger red flag than a rounding bug.