Why your loan calculator and your bank disagree (and how to code it correctly)

Bellal Hossain — Mon, 28 Sep 2026 10:08:40 +0000

I've been building a set of free online calculators (loans, mortgages, salary, taxes, investments, and more) and the most common question from users is: "Why doesn't your result match my bank's?"

The answer is almost never "the math is wrong." It's usually that two calculators made different assumptions. Here are the ones that matter, with code.

1. Compounding frequency changes the answer

The standard compound interest formula is:

A = P * (1 + r/n)^(n*t)

where P is principal, r is the annual rate, n is compounding periods per year, and t is years.

function compound(principal, annualRate, timesPerYear, years) {
  return principal * Math.pow(1 + annualRate / timesPerYear, timesPerYear * years);
}

compound(10000, 0.05, 1, 10);  // ~16288.95 (annual)
compound(10000, 0.05, 12, 10); // ~16470.09 (monthly)

Same principal, same rate, same time. About $181 apart, purely because of compounding frequency. If your calculator assumes annual and your bank compounds monthly, you'll see a mismatch.

2. APR and APY are not the same number

APR is the stated yearly rate. APY includes the effect of compounding:

APY = (1 + r/n)^n - 1

const apy = (rate, n) => Math.pow(1 + rate / n, n) - 1;

apy(0.05, 12); // ~0.05116, or about 5.116%

A 5% APR compounded monthly is roughly a 5.116% APY. Mixing these up is one of the most common bugs in finance UIs.

3. Loan payments use the amortization formula

For a fixed-rate loan with monthly payments:

M = P * r(1+r)^n / ((1+r)^n - 1)

where r is the monthly rate and n is the total number of payments.

function monthlyPayment(principal, annualRate, years) {
  const r = annualRate / 12;
  const n = years * 12;
  if (r === 0) return principal / n; // don't divide by zero
  const factor = Math.pow(1 + r, n);
  return (principal * r * factor) / (factor - 1);
}

monthlyPayment(200000, 0.06, 30); // ~1199.10

Note the zero-rate edge case. Skipping it gives you NaN and an angry bug report.

4. Floating point will bite you

0.1 + 0.2;                    // 0.30000000000000004
Math.round(1.005 * 100) / 100; // 1 (not 1.01!)

For money, use one of these approaches:

Work in integer cents and only convert for display
Use a decimal library such as decimal.js or big.js for anything involving repeated multiplication (like amortization schedules)
Round at defined points, not after every step, and document which

Rounding at every step of a 360-payment schedule can drift from a bank that rounds only at payment time, or vice versa.

5. Other reasons results differ from a lender

Even with correct formulas, real-world numbers can diverge because of:

Payment timing (start vs end of period)
Day-count conventions (actual/365 vs 30/360)
Fees, insurance, and promotional rates
Taxes and withholding rules that vary by region
Rounding rules specific to the institution

For that reason, I label every result as an estimate, and I'd suggest you do the same in anything you build.

What I'd suggest if you're building your own

Show your assumptions next to the result (compounding, payment timing, rounding).
Write unit tests with known-good values, such as published amortization examples.
Handle edge cases: zero rates, zero terms, negative inputs, very large values.
Separate formula code from UI code so calculators are testable and reusable.

Try the calculators

These formulas power calculators like compound interest, mortgage, and loan payments on Noloii, a free set of 100+ calculators across 13 categories (credit, salary, tax, investment, real estate, and more). Each one explains its own assumptions.

If you find a result that doesn't match a source you trust, tell me in the comments with your inputs. Those reports are the fastest way I find edge cases.

What's the nastiest rounding or floating-point bug you've hit in a money-related project?

I'm a solo dev who built 250+ free browser-based tools. Here's what I learned

Bellal Hossain — Mon, 28 Sep 2026 09:47:48 +0000

Every time I needed to compress an image, merge two PDFs, or format some JSON, I ended up on a different site full of popups, signup walls, or upload limits. So I started building my own.

That project became Noloii, a free tools hub with 250+ utilities for files, images, calculators, developers, and everyday tasks. No signup, and it runs in the browser.

Here's what I've learned building it as a one-person team.

Why I built it

I wanted one place that handles the small stuff:

Compress, resize, and convert images
Merge, split, and compress PDFs
Format and validate JSON, decode JWTs, encode Base64
Loan, salary, and tax calculators
Currency and time zone converters
A free ATS-friendly resume builder

None of these tasks is hard. The friction is the problem, so I set one rule: open the page, do the task, leave.

The stack

[Fill in your real stack, for example: Next.js + TypeScript, Tailwind, hosted on X. Mention which tools run fully client-side.]

The biggest architectural decision was client-side processing wherever possible. For tools like image compression and PDF merging, [describe how, e.g. Canvas API, pdf-lib, WebAssembly]. Files never leave the user's device, which is better for privacy and cheaper to run.

What I learned

1. Small tools need a system, not 250 one-offs

After the first ten tools, I noticed I was rewriting the same layout, input handling, and result display. Building a shared tool template and category structure made adding tool #100 much faster than tool #10.

2. Privacy is a feature people actually check

Users regularly ask, "Is my file uploaded?" Saying clearly on each tool page whether processing happens in the browser builds more trust than any marketing copy.

3. Explanations beat bare tools

A calculator with no context is easy to replace. I added research-style guides (how payment authorization works, how credit card interest is calculated) next to the tools. People stay longer, and the content is something other sites link to.

4. SEO for tool sites is slow, and that's normal

[Share a real number if you have one, such as impressions, clicks, or how long indexing took.] I stopped chasing shortcuts and focused on making each page genuinely better than what already ranks.

5. Building solo means saying no

I keep a list of tools I won't build until existing ones are polished. Shipping 250 mediocre tools is worse than 50 great ones.

What I'd do differently

[Example: Set up analytics and Search Console on day one]
[Example: Standardize tool metadata earlier]
[Example: Test on low-end mobile devices sooner]

What's next

[Examples: more developer utilities, an API, offline support, AI-assisted features.]

Try it and tell me what's missing

If you want to look around, it's at noloii.com. I'd especially like feedback on:

Which tool do you use most often, and what's annoying about the current options?
What small utility do you wish existed and doesn't?

Drop a comment. I read all of them.

DEV Community: Bellal Hossain