What is IFRS 9 calculation system testing?

IFRS 9 calculation system testing verifies that software calculates, stages and reports expected credit losses (ECL) in line with an organisation's approved accounting policies, model methods and data rules. It checks the calculation path from source data and configuration through to impairment results and downstream outputs, including whether changes or defective inputs produce the expected outcomes.

What IFRS 9 calculation system testing covers

The tests focus on the implemented system and its connections. They examine whether required data is complete and correctly mapped, whether calculation rules use the intended parameters, and whether results flow accurately into impairment reports, subledgers or the general ledger. Testing also checks controls such as validation messages, audit records and processing status where these form part of the system's scope.

ECL calculations can depend on probability of default (PD), loss given default (LGD), exposure at default (EAD), discounting and forward-looking economic information. Tests should verify how the system applies the institution's approved methods and assumptions, rather than assume that one simplified formula applies to every portfolio.

Staging is another important area. Under IFRS 9, Stage 1 generally uses 12-month ECL; Stage 2 uses lifetime ECL after a significant increase in credit risk since initial recognition; and Stage 3 uses lifetime ECL for credit-impaired assets. Test scenarios should check the relevant staging rules, transfers between stages and the effect of stage changes on calculated results. The system's configured policies determine how particular criteria are implemented.

How teams verify the calculations

A useful test set combines independently calculated reference cases with controlled data variations. For each case, record the input values, relevant model and configuration versions, expected stage, expected result or tolerance, and the evidence used to derive that expectation. Independently reviewed reference calculations help detect errors that a comparison with the system's previous output would miss.

Test both ordinary cases and conditions that challenge the calculation path. Examples include missing or stale economic data, invalid currency or date fields, boundary values for staging rules, changes to model parameters, and records that should be excluded or routed for review. Check that errors are reported clearly and that a failed batch does not leave partial or inconsistent outputs.

Where calculations use scenarios, test scenario weights, inputs and aggregation, including that weights meet the configured rules and that outputs reconcile to the expected weighted result. Check rounding and precision at the points specified by the approved methodology. Reconcile totals from account-level results through portfolio summaries and any downstream accounting entries. A plausible final total alone does not prove that the underlying records or stage assignments are correct.

Practical example

Suppose a controlled test exposure has an EAD of £100,000, a one-period default probability of 2%, and an assumed loss severity of 40%. A simplified calculation gives £800 before any applicable discounting: £100,000 × 2% × 40%. A test can confirm that the system uses the intended values and produces the expected result for this deliberately simple case.

This is a test illustration, not a complete IFRS 9 calculation method. A production result may require lifetime cash shortfalls, probability-weighted scenarios, discounting and other portfolio-specific rules. The expected result must therefore be derived from the approved method for the product and test case.

How to interpret the test evidence

Calculation system testing is part of financial services testing and often feeds regression testing. Run the relevant suite after changes to code, model interfaces, data mappings, parameters or reporting logic. Compare results with an approved baseline, investigate material differences, and retain input data, configuration versions, outputs and reconciliation evidence so another reviewer can reproduce the run.

Testing can show whether the configured system behaves as specified for the cases exercised. It does not, by itself, establish that the accounting policy or underlying model is appropriate. Those questions require the relevant accounting, credit risk and model governance review.