Building the Business Case
The slide is up. It says the reporting AI program will save 4,000 analyst hours a year and pull EUR 300,000 out of the cost-to-report line. The CFO nods, asks one question, and the question is not about the savings. She asks whether the numbers the platform produced will survive the auditor. Your assurance lead, sitting two seats down, goes very still. Because the honest answer is that nobody has tested that yet. The CFO has just found the seam in your business case: you sold her speed, and she heard risk. In a year where the companies still inside CSRD are the largest in Europe and a failed disclosure is a board-level event, a number that arrives faster but cannot be defended is not a saving. It is a liability with a shorter fuse.
This lesson teaches the business case a CFO will actually fund, and it has two axes, not one. Axis one is efficiency: cycle time and cost-to-report. Axis two is assurance-risk reduction: fewer findings, a cleaner basis of preparation, lower exposure to restatement and greenwashing headlines. Single-axis cases get punished. A case built only on speed invites exactly the failure mode the CFO smelled in that meeting, where the program books the time-saving and quietly inherits the audit risk. Your job as a strategist is to present both axes honestly, show the math, and name every assumption a CFO must see verified before a number goes in a board deck.
Why one axis is not enough
Most reporting AI pitches arrive as a single number. A vendor says sixty percent time-saving. A consultant says the cycle drops from sixteen weeks to ten. These are efficiency claims, and efficiency is real and worth money. But efficiency presented in isolation is dangerous, because the fastest way to make a reporting cycle shorter is to stop checking the numbers, and the fastest way for an AI tool to fill a data gap is to estimate the missing value and move on. Both of those compress cycle time. Both of them also raise the probability that an assurance provider finds something that does not trace to evidence. If your business case rewards only the first effect and is silent on the second, you have built an incentive to ship risk.
The dual-axis frame exists precisely so that speed cannot be sold alone. When you force every claim to answer two questions at once, "does this make us faster" and "does this make us more defensible," you cannot hide a risk increase inside a speed gain. A genuine win moves both axes the same direction. This is not a coincidence or a slogan. The same discipline that makes an AI output traceable, namely that every figure points back to a source document and a documented method, is also the discipline that makes the next reporting cycle faster, because the evidence is already assembled and the basis of preparation is already reconstructable. Traceability is the shared root of both axes. When you find a tool or a workflow that improves traceability, you tend to get speed and assurance together. When you find one that improves only speed, you are usually looking at a tool that gets faster by skipping the step that makes a number defensible.
A reporting AI business case that sells only speed will be punished the first time an AI-driven number fails assurance. Fund the program that moves both axes the same direction, because the discipline that makes a number traceable is the same discipline that makes it fast.
Hold that rule through the rest of the lesson. Every piece of math below is built to keep both axes visible at the same time, so that a CFO is never asked to buy a saving without also seeing what it does to the company's exposure under assurance.
Axis one: the efficiency math
Efficiency is the axis a CFO understands instinctively, which is exactly why it is the easiest one to get wrong. The temptation is to take the vendor's headline percentage, multiply it by a big hours number, and present the product as a saving. Resist that. Build the efficiency case from the bottom up, from hours your own team actually spends, and treat every percentage as something to test rather than to assume.
Start from hours, not from a vendor percentage
The unit of the efficiency axis is the analyst hour. Walk your reporting cycle and count where the hours go: data wrangling and reconciliation across systems, extracting figures from supplier documents and invoices, mapping data to the disclosure framework, drafting narrative, and the review and sign-off loop. For a mid-to-large reporting team a full cycle can run well over a thousand fully-loaded analyst hours, much of it concentrated in the data-wrangling and extraction stages that AI tools target. Get this baseline from time records or a structured estimate, not from memory, because every later number multiplies off it. If your baseline is wrong, your saving is wrong by the same factor.
Attach a fully-loaded hourly cost to those hours. Fully-loaded means salary plus benefits, plus the overhead the finance function already allocates per head, not the bare wage. A CFO will recognise a fully-loaded rate and distrust a bare one. Multiply baseline hours by the fully-loaded rate and you have your current cost-to-report for the in-scope work, the number the AI scenario has to beat.
Apply a tested time-saving, then add the work back
Now the vendor's percentage. Suppose the platform claims a sixty percent reduction in the hours spent on data wrangling and extraction. That number is a hypothesis about a generic customer, not a fact about your data. Your supplier files, your systems, your data quality, and your framework choices all change how much a tool can actually automate, and Scope 3 data, which is roughly three quarters of most companies' emissions and the hardest to source, is exactly where vendor demos look best and real data looks worst. So the tested percentage belongs in a proof of concept on your own data before it belongs in a board deck. Run the tool on a real, messy slice of your last cycle, measure the hours it actually removed, and carry that measured number forward. If the proof of concept delivers forty percent where the brochure promised sixty, you present forty.
Then do the step most business cases skip: add the oversight back. AI does not delete the work, it shifts it. Hours move from doing to reviewing. Someone has to check the extracted figures, confirm the mappings, and challenge anything the tool inferred. That verification time is real, it is often skilled and expensive, and if you leave it out your saving is fiction. The net efficiency gain is the hours removed by the tool minus the oversight and verification hours added back, valued at the fully-loaded rate, minus the annual cost of the platform itself: licence, implementation amortised across its useful life, and any integration cost. Only after all three subtractions do you have a defensible net annual saving and a payback period.
Axis two: assurance-risk reduction
The second axis is harder to quantify and is often the larger prize. It almost never appears in a vendor deck because vendors sell time-savings, but for the companies still in scope it is the axis that protects the balance sheet. Assurance-risk reduction is the value of a cleaner, reconstructable basis of preparation: fewer assurance findings, fewer late-cycle scrambles to substantiate a number an auditor questioned, lower probability of a restatement, and lower exposure to a greenwashing headline that damages the brand and draws a regulator's attention.
Why the consequence is large and why that matters
The context makes this axis bigger than it used to be. CSRD survived the Omnibus simplification and continues under the revised directive, but the scope thresholds rose, so the companies that remain in scope are the largest, those above one thousand employees and above the turnover floor. For a company that size, a failed sustainability disclosure is not a quiet correction. It is a board-level event, with audit-committee scrutiny, possible restatement, the cost of re-assurance, and reputational damage that can move financing terms. External assurance is now the norm rather than the exception, with roughly three quarters of large global companies obtaining it and the trajectory moving from limited toward reasonable assurance, which is the more demanding standard. The harder the assurance and the larger the company, the more a finding costs, and therefore the more a reduction in the probability of a finding is worth.
Price it as expected value, not false precision
You cannot put a fake precise number on this axis, and a CFO will respect you more for refusing to. Present it as expected value and as a range. Expected value is the size of the consequence multiplied by the change in its probability. If a restatement and its re-assurance would cost the company some large, estimable amount, and a cleaner AI-assisted basis of preparation lowers the annual probability of such an event even by a modest amount, the expected avoided cost can rival or exceed the entire efficiency saving, because the consequence is so large. Show the arithmetic of the expected value, show the range around it, and label the inputs as judgement rather than measurement. This is honest, it is how risk is priced everywhere else in the business, and it lets the CFO weigh a probabilistic benefit against a hard cost without you pretending the probability is known to the decimal.
Tie the reduction to specific, nameable mechanisms so it is not hand-waving. The basis of preparation is reconstructable on demand, so audit requests do not trigger a scramble. Every figure traces to a source, so findings that would have arisen from unsupported numbers do not arise. Methods are documented and consistent year over year, so the prior-period comparison the auditor checks holds up. Each of these is a concrete reason the probability of a finding falls, and naming them turns "we will be lower risk" into something a CFO and an audit committee can interrogate.
The trap: speed that hides risk
Now the failure mode the whole dual-axis frame is built to prevent. The worst outcome in reporting AI is not a tool that saves nothing. It is a tool that saves time by raising risk, where the saving is real and visible and the risk is real and invisible until assurance. This happens when AI fills data gaps with unverified estimates. The cycle gets shorter because the gaps close automatically. The cost-to-report drops because analysts stop chasing missing supplier figures. And the basis of preparation now contains numbers that exist because the model guessed, which is precisely the kind of number that fails assurance and triggers a restatement. You booked the time-saving in year one and inherited the restatement in year two.
The cardinal rule sits underneath this entire lesson. Every figure must trace to evidence. "The AI estimated it" is not evidence. Accountability stays human, and it does not transfer to the platform no matter what the vendor's contract implies. A business case that ignores this rule is not optimistic, it is mispriced, because it counts a benefit on axis one while hiding a cost on axis two. The dual-axis frame catches it: the moment you require the case to show its effect on assurance risk, a speed gain bought with unverified estimates stops looking like a win and starts looking like a deferred loss.
The assumptions a CFO must see verified
Before any number reaches a board deck, five assumptions have to be checked, and a strategist names them out loud rather than waiting for the CFO to find them.
- The time-saving percentage. Verified on your own data in a proof of concept, not taken from the vendor's brochure. The number that goes in the deck is the one your data produced.
- The baseline hours. Sourced from records or a structured estimate, because every saving multiplies off this and an inflated baseline inflates the whole case.
- The oversight and verification time added back. AI shifts work to review rather than deleting it, and a case that forgets this overstates the net saving.
- The licence, implementation, and integration cost. The full annual cost of the platform, amortised honestly, subtracted before you claim a net saving.
- The assurance-posture claim. Evidence that the tool makes the basis of preparation more reconstructable and traceable, not less. If a tool gets faster by filling gaps it cannot defend, axis two moves the wrong way and the case fails regardless of the speed gain.
Worked example: a dual-axis case
Here is a worked dual-axis case for an illustrative in-scope company. Every number below is illustrative and must be verified on your own data before use; the point is the structure and the arithmetic, not the specific figures.
Axis one: efficiency
Baseline: the in-scope reporting work consumes 1,200 fully-loaded analyst hours per annual cycle, at a fully-loaded rate of EUR 90 per hour, and the cycle currently runs 16 weeks. The proof of concept on the company's own data measured a 45 percent reduction in the hours spent on data wrangling and extraction (the brochure had claimed 60 percent; the company carries the tested 45 percent). The tool also requires roughly 120 hours of added oversight and verification per cycle. The platform costs EUR 60,000 per year in licence plus EUR 30,000 of implementation amortised over three years, so EUR 10,000 per year, giving an annual platform cost of EUR 70,000.
| Line | Baseline | AI-assisted | Note |
|---|---|---|---|
| Analyst hours per cycle | 1,200 | 660 plus 120 oversight | 45 percent tested reduction, oversight added back |
| Effective hours per cycle | 1,200 | 780 | Net 420 hours removed |
| Fully-loaded rate | EUR 90 per hour | EUR 90 per hour | Salary plus benefits plus overhead |
| Labour cost per cycle | EUR 108,000 | EUR 70,200 | Gross labour saving EUR 37,800 |
| Annual platform cost | EUR 0 | EUR 70,000 | Licence EUR 60,000 plus amortised implementation EUR 10,000 |
| Net annual position | Reference | Minus EUR 32,200 | Labour saving 37,800 minus platform 70,000 |
| Cycle time | 16 weeks | 11 weeks | Faster close, earlier assurance readiness |
Read axis one honestly. On efficiency alone, in year one, this case is negative: the labour saving of EUR 37,800 does not cover the EUR 70,000 platform cost, so the program loses about EUR 32,200 on the efficiency axis in the first year. Payback on efficiency alone does not arrive inside year one. If you had sold this as a pure speed-and-cost case, the CFO would decline, and she would be right to. The cycle-time gain from 16 weeks to 11 is real and valuable for earlier assurance readiness, but it does not, by itself, pay for the platform. This is the honest result, and it is also why the second axis is not a nice-to-have but the heart of the case.
Axis two: assurance-risk reduction
Now price the second axis as expected value, not false precision. Suppose a restatement of the sustainability disclosure plus the required re-assurance and the management time it consumes would cost the company in the region of EUR 1,500,000 to EUR 2,500,000, before reputational and financing effects. That range is a judgement, and it is labelled as one. Suppose further that a cleaner, fully traceable, reconstructable basis of preparation lowers the annual probability of such an event by an estimated 3 to 6 percentage points, again a judgement informed by where the company's current findings cluster.
| Input | Low | High | Note |
|---|---|---|---|
| Consequence of a restatement event | EUR 1,500,000 | EUR 2,500,000 | Re-assurance, management time, before reputation |
| Probability reduction per year | 3 percentage points | 6 percentage points | From a more reconstructable basis of preparation |
| Expected avoided cost per year | EUR 45,000 | EUR 150,000 | Consequence multiplied by probability reduction |
The expected avoided cost on axis two falls in a range of roughly EUR 45,000 to EUR 150,000 per year. Even at the low end it is larger than the year-one efficiency shortfall; at a central estimate it comfortably exceeds it. Present this as a range with the inputs labelled as judgement, never as a single confident number, because the probability is estimated and a CFO will trust the range more than a false decimal.
The net read
Combine the axes. Axis one is minus EUR 32,200 in year one and turns positive as implementation cost falls away and the tested time-saving compounds across cycles. Axis two adds an expected EUR 45,000 to EUR 150,000 per year of avoided risk cost. On a central read the program is value-positive from year one once both axes are counted, and clearly positive thereafter. But the recommendation is conditional and must be stated as such: fund it because both axes move favourably, and only because both move favourably. If the proof of concept had shown the tool closing data gaps with unverified estimates, axis two would move the wrong way, the expected avoided cost would turn into expected added risk, and the correct answer would be to decline despite the speed gain. Hand the CFO the five assumptions to see verified, present the risk axis as a labelled range, and let the decision rest on both numbers at once.
Presenting it to the CFO
The packaging matters as much as the math. Lead with the dual-axis frame itself, so the CFO knows from the first slide that you are not selling speed in isolation and that you have already priced the risk she is about to ask about. Show the efficiency axis built from hours, with the baseline sourced and the time-saving labelled as tested rather than claimed. Show the assurance-risk axis as expected value with a visible range and inputs marked as judgement. Then give the net read with its condition attached: fund it because both axes move the same direction.
Name the assumptions before the CFO does. A strategist who lists the five things that must be verified, and says which have been verified and which are still open, earns the credibility that a strategist who hides them loses the moment one assumption breaks. The vendor landscape is crowded, with platforms spanning carbon-and-data-focused tools and disclosure-and-controls-focused tools, and a market measured in the low billions of dollars for 2026, but the platform you choose does not absorb your obligation. The accountability for the numbers stays with the company and with you. Present the business case as what it is: a decision to spend money to move two axes at once, with the assumptions on the table and the risk priced honestly, so that the saving you book is one the auditor will let you keep.
Key Takeaways
- The fundable reporting AI business case has two axes: efficiency (cycle time and cost-to-report) and assurance-risk reduction (fewer findings, cleaner basis of preparation, lower restatement and greenwashing exposure). Single-axis cases get punished.
- Build the efficiency axis from your own analyst hours and a fully-loaded rate, not from a vendor percentage. A vendor's time-saving claim is a hypothesis to test in a proof of concept on your data, never a number to put straight in a board deck.
- AI shifts work to review, it does not delete it. Always add oversight and verification hours back, and subtract the full annual platform cost (licence plus amortised implementation plus integration) before claiming a net saving.
- Price the assurance-risk axis as expected value and as a range: the consequence of a restatement event multiplied by the reduction in its annual probability. For the largest in-scope companies the consequence is a board-level event, so even a small probability reduction can rival or exceed the entire efficiency saving.
- The worst outcome is speed that hides risk: an AI that closes data gaps with unverified estimates books the time-saving and inherits the restatement. The dual-axis frame exists to make sure speed cannot be sold in isolation.
- A real win moves both axes the same direction, because traceability is their shared root: the discipline that makes an AI output reconstructable and defensible is the same discipline that makes the next cycle faster.
- Verify five assumptions before any number reaches the board: the tested time-saving percentage, the baseline hours, the oversight time added back, the full platform cost, and the assurance-posture claim. Name them out loud before the CFO finds them.
- Every figure traces to evidence; "the AI estimated it" is not evidence, and accountability stays human and does not transfer to the platform. Fund the program because both axes move favourably, and only because both do.
Skill.re