How to test compound interest calculations

Compound interest calculation testing checks that software applies the agreed interest rate, compounding frequency, time period and rounding rules to produce the correct balance or interest amount. It uses independently calculated expected results and cases that expose errors in period handling, precision, input validation and product-specific rules.

Define the calculation rules first

Before writing tests, confirm how the product defines its rate and periods. A nominal annual rate compounded several times a year is calculated differently from an effective annual rate. Requirements should state the rate basis, compounding frequency, treatment of partial periods, start and end dates, and when rounding occurs.

For a fixed nominal annual rate, the standard formula is:

A = P × (1 + r/m)^(m×t)

Here, P is the principal, r is the annual rate as a decimal, m is the number of compounding periods per year, and t is the time in years. This formula assumes a constant rate and complete, regular periods. Calendar-based products may instead depend on actual dates and a day-count convention.

Use a reference calculation that does not call the application code under test. A spreadsheet or a small independently reviewed calculation can serve as an oracle. Avoid copying the production formula into the test helper, since the same defect could then affect both expected and actual results.

Build test cases around the rules

Start with a simple case that has an easily checked result. For example, with principal 1,000, an annual rate of 5%, annual compounding and a two-year term, the expected balance before rounding is 1,000 × (1 + 0.05)^2 = 1,102.50. The expected interest is 102.50. This gives a baseline for checking the displayed balance and any generated interest schedule.

Then vary one input at a time. Compare annual, monthly and daily compounding where the product supports them. Check zero interest and zero principal, and use boundary value analysis around permitted minimum and maximum rates, term lengths and deposit amounts. Include values just below, at and just above each configured limit.

Test dates and periods explicitly. Include a term ending on a month-end, a leap day where applicable, and a period that does not align with a full compounding interval. Expected results must follow the product's specified calendar and day-count rules. If rates can change during a term, verify that the old rate applies up to the effective date and the new rate applies afterwards.

Check precision and intermediate results

Rounding can change the final amount, especially when interest is posted each period. Confirm whether the system rounds each posting or retains extra precision and rounds only the final amount. Use test data that makes these approaches produce different results, then assert the balance at the correct precision and the posted interest separately.

Also check that rates are interpreted correctly. A value entered as 5 may mean 5 per cent or a rate of 500 per cent, depending on the interface and API contract. Assert the stored or transmitted value where possible, as well as the calculated result.

For a savings account workflow, verify that the calculated interest flows into the account balance and any statement or transaction record. A correct calculation can still produce a defect if the posting uses the wrong account, date or amount. These checks may form part of end-to-end testing in banking or banking rounding and precision testing.

Investigate failures systematically

A mismatch can come from an incorrect formula, a wrong rate unit, period-boundary handling, premature rounding or stale configuration. Capture the input values, effective dates, rate configuration, unrounded result and posted amount in test evidence. This makes it easier to distinguish a calculation defect from environment drift or a test-data problem.

Keep test data deterministic. Fix the account balance, rate, currency, product configuration and calculation date, and reset the account between runs. In continuous integration, run the same cases against the calculation service and the persisted account result when those are separate components. A regression should fail if either the calculated amount or the resulting ledger balance differs from the specified outcome.