Why the classification keeps going wrong
February. A customer files for insolvency. The engagement team logs it as a non-adjusting event, drafts a disclosure note, and moves on. Except the credit team flagged that customer's overdue balance back in November, and the receivable was already 90 days past due at 31 December. The financial difficulty did not start in February. It existed at the balance sheet date.
Under IAS 10.3 (a), an adjusting event is one that provides evidence of conditions existing at the end of the reporting period. That single sentence is the entire classification test, and teams still get it wrong on roughly half the files we review. I think the reason is structural, not technical: the event date is a fact you can look up, while the condition date requires you to reconstruct what was knowable at year end. One takes five seconds. The other takes real judgment.
IAS 10.8 leaves no room for ambiguity on consequences. When an event meets the adjusting criteria, the entity adjusts the recognised amounts in the financial statements (FS). Not just the notes. The numbers change.
IAS 10.9 lists examples worth memorising because they anchor the condition-date test in concrete scenarios: resolution of a court case after the reporting period confirming an obligation existed at year end, bankruptcy of a customer whose financial difficulty pre-dated the balance sheet date, discovery of fraud or error showing the FS were incorrect, and sale of inventory after the reporting period giving evidence of net realisable value at year end.
From the audit side, ISA 560.8 requires the auditor to evaluate whether management got the classification right. ISA 560.9 raises the bar: you need sufficient appropriate evidence that all adjusting events have been identified, not only the ones management chose to flag. At firms like ours, the standard procedures under ISA 560.7 (reading board minutes, inquiring of management, reviewing interim FS) catch most events reliably. What those procedures do not catch is the classification question itself. That part lives in the working papers (WPs), not in a checklist, and it is the part reviewers challenge most often.
Key points
- Classification turns on when the condition originated, not when the event occurred. If the condition existed at the balance sheet date, the FS change.
- Adjusting events change the recognised amounts, not just the disclosures. A note alone is insufficient under IAS 10.8 .
- Misclassifying an adjusting event as non-adjusting can produce a material misstatement the auditor must report under ISA 560.8 .
- Court case settlements are the textbook example, but customer insolvency filings are the classification teams miss most often in practice because the condition-date analysis requires judgment that checklists do not prompt.
Worked example: Vetter Logistics B.V.
Vetter Logistics B.V. reports EUR 38M revenue for the year ended 31 December 2025. Its second-largest customer, Braun Freight GmbH, files for insolvency on 14 February 2026. Braun's receivable at year end stood at EUR 1.2M, with EUR 740K more than 90 days overdue. Vetter's credit team had flagged the overdue balance in November 2025 and placed Braun on a watch list.
At first glance, this is straightforward. Financial difficulty existed before year end, so it qualifies as an adjusting event under IAS 10.9 (b). Vetter's finance team revises the expected credit loss (ECL) provision from EUR 85K to EUR 960K in the year-end FS.
Where it gets complicated
Three weeks later, Braun's insolvency administrator announces a restructuring plan. Creditors with claims under EUR 500K will receive 60 cents on the euro; larger creditors get 35 cents. Vetter's claim is EUR 1.2M. Management now wants to revise the provision downward to reflect the expected recovery.
Here is where judgment starts, and where I have seen partners on the same file disagree. One partner argued the restructuring plan is new information about a pre-existing condition (Braun's financial difficulty was already established), so the recovery estimate should feed into the adjusting event calculation. Another partner took the opposite view: the restructuring plan did not exist at year end, the creditor negotiations had not started, and the recovery terms are therefore a non-adjusting event requiring disclosure only.
Both positions are defensible. I believe the stronger argument is that the recovery terms are new, because they depend on creditor negotiations that had not begun at 31 December and the restructuring administrator was not yet appointed. But reasonable practitioners disagree, and we have seen firms go either way without receiving review findings from their regulators. What matters most for the file is that it tells a story: it documents the reasoning behind the classification, not just the provision number.
Documentation note: record the receivable balance at year end (EUR 1.2M), the ageing profile (EUR 740K > 90 days), the November credit watch flag, the February insolvency filing, and the basis for concluding the condition existed at 31 December. If a restructuring plan emerges, document why the recovery terms were or were not treated as part of the adjusting event. Cross-reference to the ECL model WP.
Where the documentation falls short
This finding generates the most review notes on subsequent events procedures. Files record the event itself (customer insolvency filing) but omit the evidence that the underlying condition pre-dated the balance sheet date. ISA 560.9 requires the auditor to document the link between the post-year-end event and the year-end condition. Without that link, a reviewer cannot assess whether the classification holds.
Why does the documentation keep falling short? Because subsequent events procedures run at the tail end of the engagement, after the team has mentally signed off. The ticking and bashing is done, the file is nearly closed, and nobody wants to reopen the ECL model for a customer that went under in February. I think this is a perverse incentive built into every engagement timeline: the classification judgment that carries the most risk lands at the exact moment when the team has the least capacity to do it properly. Documenting the condition-date analysis takes 30 to 45 minutes per event, and no engagement budget includes a line item for it.
Key standard references
- IAS 10.3 (a) defines adjusting events as those providing evidence of conditions that existed at the end of the reporting period.
- IAS 10.8 requires the entity to adjust the amounts recognised in the FS to reflect adjusting events.
- IAS 10.9 lists examples: settlement of court cases, customer bankruptcy with pre-existing financial difficulty, fraud discovery, and post-year-end inventory sales confirming NRV.
- ISA 560.8 requires the auditor to evaluate whether management correctly identified and accounted for adjusting events.
- ISA 560.9 requires sufficient appropriate evidence to support the classification of subsequent events as adjusting or non-adjusting.
Related terms
Related reading
Frequently asked questions
What is the test for classifying an event as adjusting?
The test is whether the condition existed at the balance sheet date, not whether the event occurred before or after it. A customer can file for insolvency in February, but if the financial difficulty existed in December, the FS reflect the February information as if it were known at year end. IAS 10.3(a) is explicit: adjusting events provide evidence of conditions that existed at the end of the reporting period. The event date is irrelevant to classification. In practice, teams get this wrong when they anchor on the event date because it is obvious, rather than doing the harder work of tracing the condition date.
Does an adjusting event change the financial statement numbers or just the disclosures?
Adjusting events change the numbers. IAS 10.8 requires the entity to adjust the amounts recognised in the FS. A disclosure note alone is not sufficient. If a customer files for insolvency in January and the financial difficulties existed at 31 December, the ECL provision must be revised in the year-end FS. We see teams default to disclosure-only treatment because it avoids reopening the ECL model late in the close process, but that shortcut can produce a material misstatement.