AI for Impairment Testing: Automate IAS 36 Calculations

The annual impairment test under IAS 36 is one of the most labor-intensive, judgment-heavy exercises in the financial reporting calendar. For most CFOs and controllers, it means weeks of spreadsheet wrangling: pulling cash flow forecasts from business units, reconciling them to board-approved budgets, calculating weighted average cost of capital (WACC) with dozens of inputs, and then stress-testing recoverable amounts against carrying values. The pain multiplies when you have multiple cash-generating units (CGUs), each with its own growth rates, discount rates, and sensitivity scenarios. One misplaced assumption in a linked Excel model can cascade into a restatement risk that keeps the audit committee up at night.

The deeper friction is not arithmetic—it is the narrative and documentation burden. IAS 36 requires you to demonstrate that assumptions are reasonable, disclose key estimates, and show how value-in-use would change if a critical assumption moved by a reasonable margin. Producing that narrative manually, for each CGU, is repetitive and prone to inconsistency. This is where generative AI changes the game. A well-structured AI workflow can ingest your existing cash flow models, extract the relevant inputs, calculate the recoverable amount, and draft the required disclosure language in minutes—not weeks. It does not replace your judgment; it eliminates the mechanical drag so you can focus on the assumptions that actually matter.

In this post, we show you how to build two reusable AI prompts for your IAS 36 process. The first prompt automates the calculation and reconciliation of value-in-use, and the second generates the full impairment disclosure note in the language your auditors expect. Both prompts follow the “anatomy of a prompt” structure: they force the AI to read your files, extract your standards, and ask clarifying questions before it executes. That structure is what turns a generic chatbot response into a reliable, auditable work product.

Why Generic AI Fails at Impairment Testing

If you have tried using a raw AI prompt like “calculate impairment for my CGU,” you already know the output is useless. The model does not know your discount rate source, your terminal value convention, or whether you use pre-tax or post-tax cash flows. It guesses, and a guess in impairment testing is dangerous. The solution is not better AI—it is better prompting. You must give the AI a structured brief that includes your files, your standards, and your success criteria. The prompt template below does exactly that. It is designed for a financial analyst who has a cash flow forecast spreadsheet and a WACC calculation, but who does not want to re-key data into a new tool.

I want to [automate the IAS 36 value-in-use calculation for my CGU group] so that [I can reconcile carrying amounts to recoverable amounts without manual spreadsheet errors and produce a clear audit trail].

First, read these files completely before responding:
[cgu_cashflows.xlsx] — contains five-year cash flow projections per CGU, including revenue growth, EBITDA margin, working capital changes, and capital expenditure.
[wacc_calculation.docx] — contains my pre-tax WACC derivation, including risk-free rate, equity risk premium, beta, cost of debt, and capital structure weights.
[prior_year_impairment_test.xlsx] — contains last year’s value-in-use model, terminal value formula, and sensitivity analysis format.

Here is a reference for what I want to achieve:
[Upload a completed impairment test from a prior year or an industry peer example as markdown, or describe the layout of your existing calculation workbook]

Here’s what makes this reference work:
[The reference uses pre-tax cash flows, applies a 2% terminal growth rate capped at long-term inflation, and shows a clear bridge from operating profit to cash flow. Sensitivity analysis includes +/- 1% discount rate and +/- 10% cash flow changes.]

Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: A structured Excel-ready table showing value-in-use per CGU, carrying amount, impairment loss (if any), and a one-page narrative explaining the calculation steps.
Recipient’s reaction: My external auditor should be able to follow the calculation from source data to conclusion without asking a single follow-up question.
Does NOT sound like: A generic AI explanation of IAS 36 theory. No textbook definitions. No hedging language. Must be specific to my numbers.
Success means: The output matches my manual calculation within 0.5% tolerance for every CGU, and I can copy the narrative directly into my working papers.

My context file contains my standards, constraints, audience. Read it fully before starting. [Attach your internal accounting policy manual or a summary of your materiality thresholds and disclosure preferences.]

DO NOT start executing yet. Ask clarifying questions first.
Specifically ask me: (1) whether to use pre-tax or post-tax WACC, (2) whether terminal value uses Gordon growth or exit multiple, (3) which CGUs have indefinite useful lives, and (4) whether any CGU has a recent impairment indicator triggering an interim test.

Give me your execution plan (5 steps max) before you begin.
Step 1: Extract and validate cash flow inputs from my file. Step 2: Recalculate WACC and confirm inputs. Step 3: Build value-in-use model per CGU. Step 4: Compare to carrying amounts and identify impairments. Step 5: Produce the reconciliation table and narrative.

This first prompt is deliberately heavy on constraints because the cost of a wrong assumption is high. Notice how it asks for your prior-year model as a reference—that gives the AI a format and a methodological anchor. It also forces the AI to ask clarifying questions before it executes. In practice, you will get a short list of four or five questions back. Answer them once, and the subsequent output will be startlingly accurate. The 0.5% tolerance check is your safety valve: you can run the AI model in parallel with your manual spreadsheet for the first cycle, and if it matches, you have just automated a process that used to take two weeks.

Drafting the Disclosure Note That Survives Audit Review

Once your calculations are correct, the next bottleneck is writing the IAS 36 disclosure note. Paragraph 134 requires you to disclose the carrying amount of each material CGU, the basis for recoverable amount (value-in-use vs. fair value less costs of disposal), the key assumptions, and a sensitivity analysis showing how much headroom remains. Most finance teams write this note in a sterile, boilerplate style that triggers audit pushback because it does not link assumptions to actual business drivers. The second prompt below generates a disclosure note that reads like a seasoned technical accountant wrote it—specific, concise, and impossible to challenge on completeness.

I want to [generate the full IAS 36 impairment disclosure note for my annual report] so that [my external auditors approve the note without comments and my audit committee understands the headroom and risks in plain language].

First, read these files completely before responding:
[impairment_calculation_results.xlsx] — contains the final value-in-use per CGU, carrying amount, impairment loss, and headroom (recoverable amount minus carrying amount).
[budget_assumptions_2026.docx] — contains the board-approved budget narrative, including revenue growth drivers, margin expansion plans, and market conditions.
[prior_year_disclosure_note.docx] — contains last year’s IAS 36 note in the exact format your auditors accepted, including all tables and footnotes.

Here is a reference for what I want to achieve:
[Upload a best-practice disclosure note from a listed peer company in your industry, or use the prior-year note as the reference]

Here’s what makes this reference work:
[The reference discloses each CGU separately, quantifies the discount rate and terminal growth rate, and includes a sensitivity table that shows the percentage change in a key assumption that would eliminate headroom. It uses active voice and avoids generic phrases like “based on management’s best estimate.”]

Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: A complete note ready for inclusion in the financial statements, approximately 800-1,200 words, including all required tables from IAS 36.134.
Recipient’s reaction: The audit partner reads it once and marks it “no further comments.” The audit committee understands exactly which CGU is at risk and why.
Does NOT sound like: Legalistic boilerplate. No “the company has determined” without explaining how. No vague references to “market conditions.” Must name specific drivers like “raw material cost inflation” or “customer churn in Segment B.”
Success means: The note passes an internal technical review checklist for IAS 36.134(a) through (f) with zero missing items, and the sensitivity language matches the actual numerical headroom in my calculation file.

My context file contains my standards, constraints, audience. Read it fully before starting. [Attach your disclosure checklist and any specific wording preferences from your audit firm.]

DO NOT start executing yet. Ask clarifying questions first.
Specifically ask me: (1) whether any CGU has headroom below 10% (which requires enhanced sensitivity disclosure), (2) whether I have any unrecognized impairment that needs explanation, (3) what level of aggregation I use for CGU disclosure (operating segment level or individual CGU), and (4) whether any impairment loss recognized in the period needs to be allocated to specific assets within the CGU.

Give me your execution plan (5 steps max) before you begin.
Step 1: Read my calculation file and identify headroom percentages. Step 2: Map my budget drivers to each CGU’s key assumptions. Step 3: Draft the narrative for each CGU, using the reference format. Step 4: Build the sensitivity tables from the actual numbers. Step 5: Cross-check against IAS 36.134 requirements and output the final note.

The second prompt works because it forces the AI to ground every sentence in your actual numbers. It will not invent a 15% headroom when your file says 4%. It will also flag CGUs that need enhanced sensitivity disclosure—a common audit finding when headroom is tight. The instruction to ask clarifying questions before executing is critical here; you will often discover that your CGU aggregation for disclosure purposes differs from your internal management reporting. The AI will catch that mismatch before it drafts a word.

Here is your practical next step. Pick one CGU that is not material—one where you are confident in your manual calculation. Run the first prompt with your actual files. Answer the clarifying questions, review the execution plan, and compare the output to your spreadsheet. If the tolerance matches, run the second prompt to draft the disclosure note. You will likely find that the AI’s narrative is more specific and more defensible than your current template. After two successful cycles, expand to your full CGU portfolio. The time you save in the first year will pay for the setup effort many times over—and you will reduce the risk of a material misstatement from a formula error that no one caught in the 14th tab of a spreadsheet.

Published on 5 September 2026 on growwithgpt.com