Before you start: why most AI value claims fall apart
Most AI value stories die in the room with the CFO, and for a predictable reason. They are anecdotes. Someone says the assistant saved the team hours, everyone nods, and nobody can point to a number that moved on a report the finance team already trusts. In 2025 MIT found roughly 95% of enterprise generative AI pilots returned nothing measurable. Part of that is projects that genuinely did not work. A large part is value that was real but never proven, because nobody set up the measurement before switching the AI on. Proving value is not a slide you make at the end. It is an instrument you install at the start. These steps are the order that survives scrutiny.
Step 1: Pick one workflow that already costs money
Do not start from the model or the technology. Start from a workflow that already shows up as a cost: hours of skilled time, slow cycle time that delays revenue, error rates that trigger rework or refunds. Name it precisely. Not 'customer support', but 'the time an agent spends triaging and routing an inbound case before a human replies'. A workflow this specific has a number attached to it already, which is exactly what you will need later. If you cannot point to where a workflow costs money today, you have picked the wrong one to prove value on.
Step 2: Measure the baseline before you deploy anything
This is the step everyone skips and the step that decides everything. Capture the current-state number before the AI touches the workflow. How long the task takes now, how many cases per day, the current error or rework rate, the current cost per unit. Get it from the systems of record, not from memory, because a baseline someone recalls is a baseline a CFO can dismiss. If the data does not exist yet, spend a week collecting it. A pilot with no baseline can never prove value. It can only claim it, and a claim is what gets cut in the next budget review.
Step 3: Define the metric and the financial line it maps to
Pick one primary metric the AI is supposed to move, and trace it to a line the finance team already reports. Time saved becomes a fully loaded labor cost. Faster cycle time becomes revenue pulled forward or a service level you were paying penalties to miss. Fewer errors becomes rework and refund cost avoided. Write the equation down before you deploy: if the metric moves by X, the financial impact is Y, calculated this way. Doing this in advance protects you from the temptation to invent a flattering conversion after the fact, which is the fastest way to lose a finance team's trust for good.
Step 4: Ship narrow and give it one owner
Deploy the use case on the narrow workflow you scoped, with the controls it needs to run safely on real data, and give one person accountability for the outcome. Not a steering committee. One owner who reports the number. Keep the scope small on purpose, because a narrow use case produces a clean measurement, and a clean measurement is what you can defend. Build the logging in from the start so the system records what it did, both for the audit trail a regulated business needs and because your value evidence and your compliance evidence come from the same trace.
Step 5: Run the comparison and report in about 30 days
Let it run long enough to gather real data, which for most workflows is around 30 days, and then compare against the baseline you captured in step two. Same workflow, same metric, before and after. Convert the movement into the financial line you defined in step three. Report it as a range, not a single heroic number, and be honest about what you cannot yet attribute. A defensible 'this workflow costs 22% less to run and here is the before and after from the system of record' beats an exciting number nobody can trace. If the value is real, this is where it becomes provable. If it is not, you have found out cheaply, which is also a win.
Step 6: Only then widen the scope
With one use case proven on real numbers, you have earned the right to expand, and you have a template. Apply the same six steps to the next workflow: cost, baseline, metric to financial line, narrow ship with an owner, comparison, report. Resist the urge to skip straight to a broad rollout on the strength of one win, because the second use case has its own baseline and its own risks. Operators who have taken AI to production at 300,000-organization scale compound value this way, one proven use case at a time, rather than betting a program on a single unmeasured leap. Value first, proven before it is scaled, with the controls that let you scale it safely. That is what a CFO funds twice. And keep the evidence: a folder of before-and-after numbers, each traceable to a system of record, becomes the business case for the next budget cycle and the answer when someone asks whether the AI spend is working. The teams that struggle to renew AI budgets are rarely the ones without value. They are the ones who never wrote the value down in a form finance could check.
Frequently asked questions
What is the biggest mistake when proving AI value?
Skipping the baseline. If you do not capture the current-state number before deploying, you can only claim value, never prove it. Measure how long the task takes, how many units, and the error rate from the systems of record first, so the after can be compared to a before a CFO will accept.
How long does it take to prove AI value?
For a well-scoped workflow, about 30 days of production data is usually enough to compare against the baseline and convert the movement into a financial line. If a use case cannot show measurable value in that window, the scope is probably too broad or the metric was never tied to a cost.
How do you make an AI value claim credible to finance?
Tie one metric to a line the finance team already reports, write the conversion equation before you deploy, pull the baseline and result from systems of record, and report a range rather than a single number. Evidence traceable to trusted reports survives scrutiny; anecdotes do not.