Skip to content

How we verify our numbers

A calculator is only worth using if its arithmetic is right, and almost nobody publishing one will show you how they checked. This page shows you.

The calculation is separate from the interface

Every calculation lives in a pure function that knows nothing about the page it ends up on — no access to the document, no framework, no interface code. That is not tidiness for its own sake. It means the arithmetic can be tested directly, exhaustively, and without a browser, so a bug has nowhere to hide behind a rendering quirk.

Those functions are tested against fixtures: a set of inputs with a known-correct output, where the source of that output is written into the test as a comment. A test that only compares our code against our own expectations proves the code is self-consistent, not that it is correct. The tests that matter check us against something external.

A worked verification you can repeat

The debt payoff engine is checked against the standard loan payment formula, which every lender, textbook and amortisation table produces the same answer from:

P = B × i ÷ (1 − (1 + i)−n)

For a $10,000 balance at 6.00% annual interest over 60 months, i = 0.005 and the formula gives a monthly payment of $193.3280 — the $193.33 that every amortisation table quotes. Feed that payment back into our engine and it must clear the balance in exactly 60 months.

Months to clear, from our engine60
Total interest, from our engine$1,599.68
Total interest, from the closed formula$1,599.68
Difference$0.00

That test asserts exact equality, not "close enough". An earlier draft allowed fifty cents of tolerance; measuring the real figure showed the tolerance was fifty times wider than reality and would have quietly absorbed a genuine regression in the rounding policy. It was tightened.

Money is never a decimal

Computers store decimal fractions approximately. In JavaScript, 0.1 + 0.2 is 0.30000000000000004, and 1.005 × 100 is 100.49999999999999 — so the obvious way to round $1.005 to the cent gives $1.00 instead of $1.01. That single defect is responsible for a large share of the one-cent discrepancies people notice in financial software.

Every amount here is stored as a whole number of cents or pence, never as a decimal. Where a fraction is unavoidable — interest is balance × rate ÷ 12, which rarely lands on a whole cent — the rounding is explicit and tested at the boundary in both directions.

The rounding policy

What we will not build

There is a rule here that costs us traffic and we keep anyway: if verifying an answer needs expertise we do not have, we do not build the tool.

That rules out tax withholding, payroll, capital gains, equity compensation and anything requiring a tax table — categories with far more search traffic than the ones we do build. A calculator whose output nobody here could check is a calculator that can be confidently, consistently wrong without anyone noticing, and that is the one failure this site cannot survive.

Read the tests

The source and every test are public at https://github.com/TheVikashSingh/quickoper. The calculation modules are under src/lib/calc/ and their fixtures under tests/calc/, with the source of each expected value cited in a comment directly above it.

If you find a figure that disagrees with your lender— or with an official worked example — please tell us. Open an issue with the source, or get in touch. Corrections are made openly, with the change and its date recorded on the page it affects. That is the single most useful thing anyone can send us.

What this does not make us

Verified arithmetic is not financial advice, and we are careful not to blur the two. QuickOper works out what the numbers do. It does not know your circumstances and does not tell you what to do about them. See about for what that means in practice.

Last updated 2026-08-07.