How to test a loan amortisation schedule

Loan amortisation schedule testing checks that each scheduled repayment, interest charge and outstanding balance follows the loan’s agreed terms and calculation rules. A schedule usually records the payment date, opening balance, payment amount, interest, principal repaid and closing balance for each period. Tests should verify individual rows as well as totals and the final balance, using the applicable rate, date and rounding conventions.

Define the calculation rules first

Before writing expected results, identify the rules the product is meant to apply. These may come from the loan contract, product configuration or a calculation specification. Confirm the principal, term, repayment frequency, interest rate and whether payments occur at the start or end of each period.

Clarify how the system handles annual rates, day-count conventions, compounding, payment dates that fall on non-working days, and rounding. For example, a nominal annual rate divided by 12 produces a different result from interest calculated daily using the actual number of days in each period. Check whether fees are included in the financed principal or displayed separately, and whether the last instalment is adjusted to clear a rounding residual.

Record these rules in test data and expected results. Without them, a difference between two calculations may reflect different assumptions rather than a defect.

Build an independent expected result

Use an independent calculation as the oracle for expected results. For a fixed-rate loan with equal monthly payments, end-of-period payments and a monthly rate, the unrounded payment can be calculated as:

payment = principal × rate / (1 - (1 + rate)^(-number of payments))

The application may round each instalment or its components to the currency’s minor unit. Apply the specified rounding at the specified point in the calculation. Avoid generating expected values with the same production code or shared calculation library as the system under test, since the same defect could affect both.

For example, take a £1,000 loan repaid monthly over 12 months at a nominal annual rate of 12%, with the rate divided by 12 and interest charged on the opening balance. The unrounded monthly payment is about £88.8488. If the payment is rounded to £88.85, the first month’s interest is £10.00, principal repaid is £78.85 and the closing balance is £921.15. The final instalment may need an adjustment to clear the balance, depending on the product’s rounding rules.

Test rows, totals and boundaries

For each schedule row, verify that the payment is allocated correctly between interest and principal. Check that the closing balance equals the opening balance plus any applicable charges, less the payment, with each component handled according to the stated rules. The next row’s opening balance should match the previous row’s closing balance.

Check schedule-level properties as well. The principal repayments should reconcile to the original principal, subject to any agreed residual or balloon payment. The final balance should match the product’s defined outcome, usually zero for a fully repaid loan. Total interest should equal the sum of row-level interest charges. These checks can expose defects that a comparison of the monthly payment alone will miss.

Use boundary value analysis around supported limits: the minimum and maximum principal, shortest and longest term, rate limits, and the smallest permitted repayment. Include zero or promotional rates where supported, rates near a configured limit, and amounts that produce fractions of a minor currency unit. Test the shortest term and a term that crosses a leap day or a month-end when dates affect interest. Invalid values, such as a term of zero or a rate outside the permitted range, should produce the specified validation response rather than a plausible-looking schedule.

Check changes and system outputs

Test changes that affect the calculation, including a rate change, early repayment, payment holiday or amended payment date, where the product supports them. Verify which schedule rows are recalculated, how past transactions are preserved and whether totals and the maturity date are updated. A schedule should also remain consistent across the user interface, application programming interface (API), loan servicing records and any downstream accounting output that consumes it.

For automated regression tests, keep test data deterministic and fix the rate, dates, currency and calculation configuration. Compare structured schedule fields rather than formatted screen text alone. When a test fails, retain the input terms, calculation configuration and row-level actual and expected values. This helps distinguish calculation defects from environment drift, stale configuration or display rounding. For related checks, see Loan interest calculation testing, Banking rounding and precision testing and Boundary value testing in banking.