How the calculators produce an estimate

1. 1. Validate. Required values, supported ranges, and impossible combinations are rejected or explained.
2. 2. Normalize. Percentages, time periods, payment frequency, and currencies are converted into the units required by the formula.
3. 3. Calculate. The tool applies a deterministic formula or schedule. It does not ask a generative model to invent a result.
4. 4. Present. Results are rounded for readability; intermediate values may keep more precision to reduce compounding error.

Defaults are examples, not recommendations. A calculator may assume a constant rate, regular payment timing, no missed payments, or a stable tax rule. The calculator page identifies material assumptions and its jurisdiction. U.S. statutory-threshold calculators use USD even when a different display currency was previously selected.

Real institutions may use different day-count conventions, compounding, minimums, fees, eligibility tests, taxes, and rounding. Those differences can produce a different result.

• Known examples and boundary cases are checked where test coverage exists.
• Shared finance functions are regression-tested after changes.
• Type and production-build checks catch invalid code paths.
• Source links and high-risk rule sets receive dated reviews.

Automated tests reduce errors but cannot prove that every calculator is correct for every contract, jurisdiction, or personal situation.

Calculators based on general mathematics are reviewed when their logic changes. Rule-based tools are reviewed against the linked primary source. The date shown in each transparency panel is the most recent link and methodology check; it is not a guarantee that a government or provider has not changed a rule since then.

If an issue is confirmed, we update the formula, source, explanatory copy, or supported-year label and add a regression case when practical.