A good AI pilot gets waved away in a finance review more often than a bad one gets caught, usually for a fair reason. Here's the evidence ladder that separates a claim from proof, and what to say when it genuinely did not work.
AI business results only count as proof once they can answer one question: what else changed in that window? This piece walks through what gets waved away in a finance review and why the objection is usually fair, what a real baseline requires, a six-rung ladder ranking evidence from weakest to strongest with a worked example at each rung, a one-page write-up template, and what an honest negative result looks like.
Picture the monthly ops review. An operations manager pulls up one slide: invoice exception handling, the queue of purchase orders and invoices that don’t match automatically and have to be chased down by hand, is averaging 6.1 days to clear. Three months ago, before the AI matching tool went live, it was averaging 9.2. The number comes straight out of the same system finance already trusts. It’s a good result.
The room likes it, right up until the CFO asks one question: “Compared to what, and what else changed this quarter?” The real answer is a lot messier. Two new hires finished training in July. A vendor portal migration in May quietly removed a whole category of manual matches. August is typically the slowest month for invoice volume at that company. Any one of those could move the number alone, and all three landed in the same window as the AI rollout.
Nobody in that room thinks the operations manager is lying. The number is real. It’s just being asked to prove something it can’t prove on its own, and most people in the meeting half know it, which is why the conversation moves on to the next slide rather than getting into it properly.
This happens constantly, and it isn’t because finance and ops leaders are hostile to AI. It’s because the people who approve a pilot and the people who have to defend the number afterward are often working from two different timelines. Open Future Forum’s August 2026 survey of finance-seat and CEO-seat respondents found a 27-point gap in how fast each side expects an AI investment to pay off: 72% of CEOs and founders expect a measurable return inside six months, against 45% of the people actually sitting in finance.[1] The optimism sits with whoever signed off on the budget. The scepticism, and the burden of proving it, sits with whoever has to stand behind the number once someone asks a hard question about it.
Getting a fair hearing for a genuinely good AI business results claim starts with understanding that gap, not resenting it. The rest of this piece covers what actually closes it: what gets waved away and why that’s usually fair, what a real baseline has to include, and what a number needs before it survives the question the CFO just asked.
Before you can build something a finance lead actually accepts, it helps to know exactly what gets waved away, and why. The instinct is to read the pushback as stubbornness, or as finance being naturally allergic to anything new. Most of the time that isn’t what’s happening. Each objection below is a fair complaint about what the evidence in front of them can and can’t support.
| What gets said | The objection | Why it’s fair |
|---|---|---|
| “This is saving me about six hours a week.” | There’s no baseline and nothing measuring it. It’s an estimate from the person the tool is supposed to make look good. | In practice, reclaimed hours only turn into a business result if the organisation removes a cost, redeploys the freed time to something with measurable value, or produces more without adding staff. Hours that just get absorbed as slack are real for the employee and invisible on the P&L. |
| “Look how much it’s dropped since we turned it on.” | Nothing was captured before the tool went live, so there’s no real “before” to compare the “after” against. | Without a genuine baseline, a finance lead can’t tell whether the AI moved the number or whether a new hire, a system change, or an ordinary seasonal dip did. All three usually did something in the same window. |
| “The team loves it, everyone’s using it.” | Adoption and enthusiasm are a different claim from impact. | People logging in tells you the tool got installed. It doesn’t tell you the underlying work got better, faster, or cheaper because of it. That’s a Use signal, not an Impact signal, and finance is being asked to fund Impact. |
| “It’s early days, give it time.” | Fair the first time it’s said. Less fair every time after, if nothing was set up to actually measure the thing once time passes. | “Give it time” is a real request when the operating metric genuinely needs a full cycle to move, a monthly close or a quarterly renewal. It stops being fair the moment the deadline for “later” arrives and the answer is still a feeling instead of a number. |
Four objections finance leads raise most often in a pilot review, and the actual reasoning behind each one.
Run these through a lens that’s more useful than a straight before-and-after: are people actually using it, do they keep using it once nobody’s reminding them to, and is the work itself different because of it. Use, Persistence, Impact. Most of what gets waved away in a finance review never gets past Use. PEX’s 2026 State of Finance Report, based on responses from nearly 700 finance and operations leaders, found that just 9% of finance teams use AI broadly, and only 5% can measure the return on it.[2] That gap between “we’re using it” and “we can measure what it’s worth” is most of this article in one stat.
None of this means finance is right to dismiss every pilot that can’t yet show a clean number. A pilot two weeks old showing early Use and real Persistence is a legitimate, sayable stage, not a failure to write up. It just isn’t proof of Impact yet, and saying so plainly is more credible than dressing up Use as something bigger.
A baseline is just the number before. Not a memory of what things used to feel like, an actual figure, pulled from the same system you’ll use to measure the after. Skip it, and every claim you make later is unfalsifiable: nobody can check it, including you.
Most pilots skip it for an ordinary reason. Capturing a baseline means someone has to decide, before the exciting part starts, exactly which number matters and go pull it. That’s unglamorous work, it happens in week one when everyone’s focused on getting the tool switched on, and it’s usually the first thing that gets dropped when a pilot moves fast.
A usable baseline needs three things, worth checking a candidate metric against before you commit to it:
If you can’t say what the number was before, you can’t say what changed after.
For the invoice exception example from earlier, the baseline was easy because finance already tracked exception handling time as a monthly metric, for reasons that had nothing to do with AI. That’s the common case worth looking for first: a number your own team already reports on, sitting in a dashboard or a monthly pack somewhere, that you can simply start watching more closely the moment the pilot begins. The AI Adoption Checklist covers what to line up before a rollout even starts, and naming the baseline metric belongs on that list, not added in afterward.
Once you’ve got a real baseline, the question becomes what to build on top of it. Not every kind of evidence is worth the same amount in a finance review, and treating them as interchangeable is exactly what gets a good pilot waved away. Here’s the climb, from what a finance lead will wave away on sight to what will actually survive a hard question, using the same invoice exception example throughout so you can see the same underlying result read as stronger or weaker depending on what’s actually behind it.
Invoice exception time is a metric finance already tracked monthly for two years. It held steady around 9 days for the six months before rollout, then dropped to 6.1 days within the first quarter after, with no other process, staffing, or system change logged in that window. This is the one that survives “what else changed,” because the answer is genuinely nothing else did.
Two AP teams, similar size and volume, same month. The team using the AI tool cut exception time from 9.2 to 6.1 days. The comparable team, not yet rolled out, held flat at 9.0. The comparison group does the work that “what else changed” would otherwise demand.
Exception time went from 9.2 days to 6.1 days since rollout, measured against the same number the team already tracked before. Real, and still open to “what else happened that quarter,” because nothing rules out the other explanations.
42 of 50 AP staff logged into the tool at least once last week. This proves Use. It says nothing about whether exception time, or anything else finance cares about, actually moved.
“I think this saves me about six hours a week.” A real feeling, with no instrument behind it and no way to check it against anything.
“The team says it feels faster now.” Worth listening to as a signal something might be worth measuring properly. Not evidence on its own.
Same underlying pilot, six different ways to describe its result. Only the top two survive a skeptical question about what else changed.
What actually separates rung 4 from rung 6 comes down to one thing: whether the number can answer the specific question a finance lead is trained to ask, what else happened in that window that could explain this. Rung 4 is honest and still real progress. It just hasn’t done the work of ruling out the other explanations yet, and a finance lead who’s seen a few of these before knows to ask for it.
A number that can’t survive one honest question about what else changed hasn’t earned the word proof. It’s still a claim waiting to be tested.
You don’t always need rung 6 to get a fair hearing. A pilot reporting honestly at rung 4, with the gap named out loud rather than glossed over, will usually get more trust from a finance lead than one that quietly presents rung 2 evidence dressed up in rung 6 language. Your AI Might Be Working. Right Now You Can’t Prove It. goes deeper into building a comparison group from scratch, worth reading alongside this piece if rung 5 or 6 is genuinely within reach for what you’re testing.
Whatever rung you land on, it needs to fit on one page. A twenty-slide deck reads like a sales pitch. A one-pager, with the gaps named honestly instead of hidden, reads like something a finance lead can actually act on.
| Field | What goes here |
|---|---|
| What we tested | AI-assisted invoice matching for the AP exception queue, one team, 12 weeks. |
| Baseline | Average exception handling time, 9.2 days, stable for the six months before rollout (source: monthly ops pack, already tracked). |
| Comparison | A second AP team of similar size and volume, not yet rolled out, tracked over the same 12 weeks. |
| What moved | The AI team’s average dropped to 6.1 days. The comparison team held at 9.0 days over the same period. |
| What else changed in that window | None logged for the AI team. The comparison team absorbed one new hire in week 8, noted so it isn’t mistaken for a control problem. |
| Rung reached | 5 of 6: before/after against a baseline, checked with a comparison group. |
| What we’re recommending | Expand to two more AP teams for a further quarter before rolling out company-wide, using the same baseline-and-comparison method. |
Seven fields, filled in against the same invoice exception pilot used throughout this piece.
Notice the write-up names its own rung. That’s deliberate. A finance lead who’s read a few of these will find the number faster than the argument, and stating the rung up front, rather than making them work it out, is what makes the document read as credible rather than as a pitch.
Who this lands with shapes what belongs on the page. A controller wants the line-level detail behind “what moved,” because their job is to defend it if someone audits it later. A CFO wants the headline movement and the comparison, without the line items, because their question is whether to keep funding it. A budget owner wants the ongoing cost next to the baseline, because their decision is whether the licence cost stays justified. One page can serve all three if the number sits up top and the detail sits underneath, rather than writing three separate documents.
Building a case finance actually accepts is a specific skill, separate from knowing how to use the tool itself, and it’s part of what separates an AI-powered professional from someone who’s just comfortable clicking around inside one.
| What AI does | What the human still owns | How it gets checked |
|---|---|---|
| Drafts the one-pager from the raw baseline, comparison, and result numbers you give it | Decides which rung the evidence actually reaches, and whether “what else changed” has genuinely been ruled out | The pilot owner and their manager read the draft against the raw numbers before it goes to finance, not after |
AI can assemble the document quickly. Judging whether the evidence is actually strong enough stays a human call.
If you need the fuller framework for tracking AI ROI beyond a single pilot write-up, including the cost side of the equation, The Honest Guide to Measuring Your AI ROI covers that ground in more depth than this piece needs to.
Sometimes the ladder never gets past rung 3. The team used the tool, some of them kept using it a month later without being told to, and the metric you were watching didn’t move, or moved for a reason that had nothing to do with the AI. That’s a real outcome, and it deserves the same one-page treatment as a success, not a quiet decision to stop mentioning the pilot in the monthly update.
Use the same fields. What we tested, what the baseline was, what actually moved, or didn’t. If the answer is that the exception rate held at 9 days regardless, say that plainly, and say what you’d try differently rather than what you’re recommending next. A negative write-up that reaches rung 4 or 5, cleanly, is more useful to a finance lead than a positive one that never got past rung 2, because it tells them something they can actually act on:
This is also where Persistence matters more than it usually gets credit for. A pilot can show real Use and even real Persistence, with people genuinely still opening the tool a month in, and still show zero Impact on the metric that was supposed to move. That’s a legitimate finding worth having, not a failed measurement: the tool changed behaviour without changing the outcome, worth knowing before you scale it rather than after.
Killing a pilot cleanly, with a real baseline and a real comparison behind the decision, is itself a credibility signal. A finance lead who’s watched one team write up a clean no is more likely to trust that same team’s next yes. That’s the payoff of measuring properly even when the result disappoints you: not this pilot, but the next one you bring into the room.
If a pilot genuinely does clear the bar and you’re now looking at scaling it past one team, that’s a different problem with its own failure modes, mostly organisational rather than evidentiary. Why Your AI Pilots Never Scale (and How to Get Unstuck) picks up close to where this piece leaves off.
Pick one process you’re already running AI on, or about to. This week, before anything else changes, go find the number it should move and write down what it is right now. That’s the whole first step, and it’s the one most pilots skip.
A number a finance lead accepts needs three things: a real baseline captured before the AI touched the process, a way to account for what else changed in that window, ideally a comparison group, and a plain statement of which of those two you actually have. Self-reported time savings and enthusiasm don’t clear that bar on their own.
A metric your team already tracks, or could easily start tracking, captured before the AI touches the process rather than reconstructed from memory afterward. Watch for the trap that catches most pilots: picking a metric that was already scheduled to change for unrelated reasons, a seasonal dip, a known system migration, a planned headcount shift, which makes even a real result impossible to defend later.
Reclaimed hours only become a business result if the organisation removes a cost, redeploys that time to something with measurable value, or produces more without adding headcount. Hours that just get absorbed as slack are real for the person doing the work and invisible on the P&L, which is exactly why a finance lead waves them away.
What was tested, the baseline and its source, what moved, and what else changed in that window. The most commonly missing field isn’t a number at all, it’s an explicit line stating what you are not claiming, so nobody upgrades a rung-4 result into rung-6 language after the fact.
Long enough for the operating metric to complete a real cycle, a monthly close or a quarterly renewal, not a fixed number of weeks picked in advance. No movement by that point is a genuine warning sign. Real movement with no financial number booked yet usually means the freed capacity wasn’t redeployed, not that the tool failed.
This article draws on two sources, both listed below: Open Future Forum’s August 2026 analysis of the gap between how fast CEOs and finance leaders expect an AI investment to pay off, and PEX’s September 2026 State of Finance Report on AI use and measurement inside finance teams. The invoice exception handling example used throughout is a worked example built to show how the same pilot result reads differently depending on what evidence sits behind it. Every template and table in this piece is original to Future Factors AI.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.