Impairment testing under IAS 36 is one of the most demanding exercises in the finance calendar. Every reporting period, controllers and analysts must identify cash-generating units, rebuild value-in-use models, refresh discount rates, defend terminal growth assumptions, and reconcile carrying amounts against recoverable amounts — often across dozens of asset groups and multiple jurisdictions. The mechanical work is heavy, the audit trail is fragile, and the cost of a single inconsistent assumption can be a restatement-level problem.
The pain is not the accounting theory. It is the assembly line around it. Assumptions live in scattered spreadsheets, prior-year models get overwritten, discount rate derivations are rebuilt from scratch, and sensitivity tables are produced manually the week before sign-off. When auditors ask why the WACC moved 40 basis points, the answer is buried in an email thread. When a CGU’s headroom narrows, nobody notices until the file is already with the audit committee.
AI changes the economics of this work. Used properly, a language model does not replace your judgment on cash flow forecasts or discount rates — it replaces the transcription, structuring, cross-checking, and documentation labour that surrounds those judgments. You feed it your assumptions, your prior-year file, and your accounting policy, and it produces a structured impairment working paper, a sensitivity grid, an assumption-change log, and a disclosure draft that ties back to your inputs. The analyst keeps the judgment; the AI absorbs the grind.
Where AI Fits in the IAS 36 Workflow
The highest-value applications are not “calculate my impairment.” They are: extracting and normalising assumptions from source documents, building the value-in-use calculation scaffold, generating the discounted cash flow schedule from your inputs, producing sensitivity and headroom analysis, and drafting the disclosure note in your house style. Each of these is a bounded task with a clear input and a checkable output — exactly the profile where a well-constructed prompt beats a generic request.
The two prompts below follow the same pattern: define the task, force the model to read your context files first, give it a reference for the output format, and require a plan before execution. That structure is what separates a usable working paper from a plausible-sounding hallucination.
First, read these files completely before responding:
[ias36_policy.md] — our accounting policy for impairment, CGU identification rules, and materiality thresholds
[prior_year_impairment.xlsx.md] — last year’s value-in-use model, discount rate derivation, and terminal growth assumptions
[cgu_assumptions_[period].md] — current period cash flow forecasts, capex, working capital movements, and asset carrying amounts by CGU
Here is a reference for what I want to achieve:
[Upload prior-year working paper as markdown, or describe the structure of your best-reviewed impairment file]
Here’s what makes this reference work:
It states the CGU, the carrying amount, the recoverable amount, and the headroom on a single summary page before any calculation. Every assumption has a named source and a date. The discount rate derivation shows each component (risk-free rate, equity risk premium, beta, size premium, cost of debt, tax rate) separately. Sensitivities are presented as a grid, not prose. The conclusion is one sentence and references the summary page.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: Structured working paper, 8-12 sections, with tables for the DCF schedule, discount rate build-up, and sensitivity grid
Recipient’s reaction: The audit partner should be able to review it in 20 minutes and find no unexplained figures
Does NOT sound like: A generic template with placeholder commentary or vague “management believes” language
Success means: Every number in the working paper traces to a named input file, and the headroom calculation is reproducible by a reviewer without asking me a question
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 not do: it does not ask the model to invent a discount rate or guess a terminal growth figure. It asks the model to structure, calculate, and document inputs that you supply. That boundary is the difference between a tool that saves you two days and a tool that creates an audit finding.
Stress-Testing the Result Before It Reaches the File
Once the base working paper exists, the second prompt turns it into a challenge document. Impairment testing fails in practice not because the base case is wrong, but because nobody pressure-tested the assumption that mattered. A structured sensitivity and headroom analysis, generated consistently across every CGU, surfaces the two or three units where a modest change in growth or discount rate eliminates headroom — which is precisely what the audit committee will ask about.
First, read these files completely before responding:
[value_in_use_working_paper.md] — the completed base-case model with carrying amounts, recoverable amounts, and headroom by CGU
[assumption_register.md] — the source and rationale for each key assumption (discount rate, terminal growth, revenue growth, margin)
[board_risk_register.md] — the risks management has already flagged for the coming period
Here is a reference for what I want to achieve:
[Upload a prior sensitivity analysis or describe the format your audit committee expects]
Here’s what makes this reference work:
It ranks CGUs by headroom as a percentage of carrying amount, not by absolute value. It shows the break-even point for each key assumption (the discount rate at which headroom reaches zero, the terminal growth rate at which headroom reaches zero). It flags any CGU where the break-even assumption is within the range management has already described as plausible. It ends with a one-paragraph conclusion per at-risk CGU.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: Sensitivity grid plus a ranked headroom table plus a short narrative, 3-5 pages
Recipient’s reaction: The audit committee should immediately see which CGUs need discussion and why
Does NOT sound like: A wall of numbers with no ranking, or a narrative that buries the at-risk units on page four
Success means: Every CGU is ranked, every break-even point is stated explicitly, and at-risk units are identified in the first paragraph
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 before you run either prompt: build your context files once and reuse them every reporting period. The ias36_policy.md, assumption_register.md, and prior-year working paper do not change much quarter to quarter, but they are what turn a generic model into one that produces output in your format, with your materiality thresholds, and your disclosure language. The upfront hour spent assembling those files pays back every cycle.
Start with the base-case working paper prompt on a single CGU. Review the output line by line against your own calculation. Once the structure holds, scale it across the full population and add the sensitivity prompt. The goal is not to remove the analyst from IAS 36 — it is to remove the analyst from the spreadsheet mechanics so their time goes to the assumptions that actually determine whether an impairment is recognised.
Published on 7 October 2026 on growwithgpt.com