Impairment testing under IAS 36 is one of the most demanding exercises in financial reporting. Every year, controllers and analysts rebuild the same machinery from scratch: cash-generating unit definitions, five-year cash flow projections, terminal value assumptions, pre-tax discount rates, sensitivity tables, and a reconciliation of headroom that has to survive auditor scrutiny. The calculations themselves are not conceptually difficult — the friction is in the repetition. One wrong discount rate, one inconsistent growth assumption, or one CGU mapped to the wrong asset group and the entire impairment schedule has to be rebuilt under deadline pressure.
The deeper pain is documentation. IAS 36 requires judgment at almost every step: how CGUs were identified, why the discount rate is appropriate, which assumptions are most sensitive, and what would have to change for an impairment to arise. Most finance teams do the numbers in one file and write the justification narrative in another, weeks later, from memory. Auditors then ask for the link between the two, and the reconciliation exercise consumes days that should have gone to analysis.
Large language models change the economics of this work. When given a structured prompt, a model can draft the full impairment working paper — CGU mapping table, DCF mechanics, rate build-up, sensitivity matrix, and disclosure narrative — in a consistent format, ready for review. The analyst’s role shifts from building spreadsheets to challenging assumptions, which is precisely where professional judgment adds the most value.
Where AI fits — and where it does not
To be clear about scope: the AI does not replace your valuation model or your auditor. It accelerates the structured drafting around the calculation — the assumption registers, the rate derivations, the sensitivity grids, and the IAS 36 disclosure text — so your team spends its time on the judgments that matter. Every output must still be reviewed by a qualified accountant and tied back to the approved model.
The two prompts below show how to structure this. The first builds the impairment working paper from your CGU register and assumptions. The second produces the disclosure note and audit-ready sensitivity analysis. Both use the anatomy-of-a-prompt format so the model reads your files fully before producing anything.
First, read these files completely before responding:
[cgu_register.md] — list of cash-generating units, asset groupings, and carrying amounts
[assumptions_2026.md] — five-year cash flow projections, growth rates, terminal value basis, and discount rate components
Here is a reference for what I want to achieve:
[Upload last year’s approved impairment working paper as markdown]
Here’s what makes this reference work:
[Tabular CGU-by-CGU layout; explicit rate build-up from risk-free rate to pre-tax discount rate; every assumption tagged with source and owner; sensitivity shown as a grid of headroom percentages; narrative in short declarative sentences with no hedging]
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: Working paper in markdown, 1,200–1,800 words plus tables
Recipient’s reaction: The audit partner should see a complete, internally consistent file and ask only judgment questions, not arithmetic ones
Does NOT sound like: A textbook summary of IAS 36; no generic definitions, no filler
Success means: Zero inconsistencies between CGU carrying amounts, projected cash flows, discount rates, and headroom figures across the document
My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.
Give me your execution plan (5 steps max) before you begin.
Notice what the prompt does: it forces the model to read your CGU register and assumptions before writing a single line, and it defines success as internal consistency rather than prose quality. That is the correct bar for impairment work. A beautifully written working paper with a discount rate that does not tie to the rate build-up is worse than useless.
From calculation to disclosure
Once the working paper exists, the disclosure note and sensitivity analysis follow from the same source files. The second prompt produces both, structured so that the sensitivity table directly supports the narrative — a requirement auditors test every year. Run it after you have reviewed and approved the first output, feeding the approved version back in as the reference.
First, read these files completely before responding:
[approved_working_paper.md] — the reviewed impairment working paper with final headroom figures
[auditor_queries_2025.md] — last year’s audit questions and management responses
Here is a reference for what I want to achieve:
[Upload the prior year’s published impairment note as markdown]
Here’s what makes this reference work:
[Key assumptions disclosed per CGU with quantified sensitivity; changes in assumptions explained year-on-year; terminal growth and discount rate shown with derivation basis; language mirrors IFRS taxonomy wording while staying readable]
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: Disclosure note plus sensitivity table, 600–900 words
Recipient’s reaction: The auditor recognizes every prior-year query is already addressed in the text
Does NOT sound like: Boilerplate copied from the standard; no unexplained jargon
Success means: Every figure in the note traces to the approved working paper, and each prior-year query maps to a specific sentence
My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.
Give me your execution plan (5 steps max) before you begin.
A practical tip: keep your CGU register and assumptions file as living markdown documents throughout the year, updated whenever forecasts change. The quality of the AI output is bounded by the quality of those two files — teams that maintain them quarterly get usable drafts on the first pass, while teams that assemble them in January spend the saved time correcting inputs instead of reviewing judgments.
Start with one CGU this cycle. Run the first prompt, review the output against your existing model, and note where the model’s structure exposed gaps in your own documentation. That gap list is the real deliverable — it tells you exactly what to fix before the next reporting close.
Published on 4 November 2026 on growwithgpt.com