Executive summary
An AI finding is a claim about your business: cash will fall short, a customer is paying later. It arrives as one confident sentence with a number in it. The number may be right. Most findings give you no way to tell.
You already know how to trust a person with this kind of work. A new analyst is trained for the job, their manager signs off, they build a track record, and their work leaves a trail. Nobody hands a new hire's cash warning to the CEO without asking where it came from.
Apply the same standard to any AI finding, from any vendor. A finding you can trust shows its source records (named files, with export times), arithmetic you can redo, the cause and what was ruled out, who reviewed it, who approves what happens next, and where all of that is recorded.
This guide works one cash finding two ways on the same facts, shows how to redo the arithmetic in two minutes, and ends with a one-page finding review form, approval-quality metrics and the questions to ask any vendor. If a tool cannot answer them, do not act on what it tells you.
When to use this
Use this method when:
- A tool (an AI assistant, a forecasting add-on, a feature in your accounting software) produces findings that people act on.
- Someone has asked "where did this number come from?" and nobody could answer in under five minutes.
- You are about to let a tool propose or take actions: delay a payment, change a forecast, chase a customer, adjust a price.
- An approver signs off on tool-generated requests and you cannot remember the last time they said no.
The method assumes the underlying records exist and can be exported. If they are unreliable, fix that first. See data foundations for operating reporting.
Diagnostic questions
Answer these about the last AI finding someone in your business acted on.
- Which files did it read, and when were they exported?
- Could you redo its arithmetic with a calculator, from what the finding shows?
- Did it name a cause, or only describe a symptom ("cash will be tight")?
- Did it say which other causes it ruled out, and why?
- Who approved the action that followed, and what did they see when they approved it?
- Next period, did anyone check whether the stated cause was right?
If you answered "no" or "don't know" to the first three, the finding was a confident number nobody could check. That is the hidden risk this guide is about.
Framework: the standard you already use for people
How a business trusts a person, and what that means for a finding
| To trust a person, you check... |
To trust an AI finding, ask for... |
| Training for this specific job |
What the tool is trained and checked to do, and what it is not allowed to do |
| A manager's sign-off |
Who reviewed the finding, and who approves any action that follows |
| References and a track record |
How often its past findings held, and how often its stated causes proved wrong |
| A written trail: files, workings, minutes |
Named source files, arithmetic you can redo, and a record of who approved what |
None of this is new. It is how a controller reviews a junior analyst's work. The only new thing is that the author is software, and software skips the trail unless someone demands it. The same test applies to a consultant's slide that says "working capital is the issue" with no aging behind it. What decides trust is whether the number traces to a record you can open. Whose logo is on the finding does not change the answer.
Here is the uncomfortable part. Most businesses already apply a lower standard to AI findings than they would to a first-week analyst. The analyst's cash warning would come back with "show me the workings." The tool's warning gets acted on because it arrived quickly and sounded sure.
The first row of the table is the one buyers skip, and it matters most. A general-purpose assistant asked about your cash has no job description. Nobody defined what a good cash finding looks like, checked its work against that standard before it reached you, or limited what it may do. Ask what the tool was checked against, and by whom, before it went live. "It was trained on a lot of data" describes what it read. It does not describe what it is qualified to do.
What a finding should show
| Element |
What it looks like in plain words |
The question it answers |
| Sources |
Named files or reports, with the time each was exported |
What is this based on, and is it current? |
| Arithmetic |
The figures and the sum, laid out so you can redo it |
Is the number right? |
| Cause |
One specific reason, with its own evidence |
Why is this happening? |
| Ruled out |
The other likely causes, and the evidence that excludes each |
Why this cause and not another? |
| Reviewed by |
A named person (or a stated check) that looked at the finding before you |
Has anyone besides the tool looked at this? |
| Approver and action |
The proposed action, and the named person who must approve it before it runs |
Who decides, and what happens if they say no? |
| Recorded where |
The place the finding, approval and result are kept |
Can we find this in six months? |
The reframe is simple. The useful question about an AI finding is whether you can check it, and the question people usually ask, "is the AI accurate?", is one you cannot answer from a single sentence. A finding that can be checked can be trusted one finding at a time. A finding that cannot be checked is an opinion with a decimal point.
After the finding: approval that can be judged
A finding usually leads to an action. When a tool proposes or takes that action (moving a payment, changing a forecast, sending a reminder to a customer), a named person approves it before it runs. That rule only means something if the approver can judge the request.
The request should carry the finding's reasoning, its sources and the record for this kind of action. "Approve: delay payments to protect week 7" can only be signed. A request showing the arithmetic, the cause and the exact payment to move can be judged.
Watch for approval fatigue: when most requests are fine, review becomes a reflex. Track the quality of approvals as well as their volume: approve, reject and send-back rates, time to approve, and approvals later reversed. Zero rejections over two quarters should worry you. Perfect tools are rare; approvers who have stopped reading are common. Who may approve what is a decision-rights question, covered in decision rights for AI actions.
Step-by-step process
Run these steps on any finding that could lead to an action above your own threshold (for example, anything that moves cash, changes a forecast the board sees, or contacts a customer).
- Restate the claim in one line: what, which period, how big. If you cannot, send it back.
- Check the sources. Every figure should trace to a named file with an export time. An aging exported last Tuesday, with three large customers paid since, makes the finding stale.
- Redo the arithmetic with a calculator, from the figures shown. Two minutes when the finding is built properly. Impossible when it is not.
- Test the cause. Add it back. Does the problem disappear? Then read what was ruled out and ask whether anything obvious is missing.
- Find the reviewer. If nobody looked at this before you, you are the first reviewer. Act like one.
- Route the action to its named approver with the full finding attached. The action does not run until that person says yes.
- Record it, and check next period. Did the stated cause hold, and did the action work?
Worked example: one cash finding, two ways
Illustrative. The company, figures, files and causes below are invented to demonstrate the method. They are not benchmarks.
The finding
A company runs a 13-week cash forecast with a $50,000 minimum cash floor. On Monday morning a tool produces this:
Week 7 closing cash is $31,600, which is $18,400 below the $50,000 floor.
Strong and weak, side by side
The weak version of the same facts reads: "Cash will be tight in week 7. Consider delaying payments."
|
Strong finding |
Weak finding |
| Claim |
Week 7 closing $31,600, $18,400 below the $50,000 floor |
"Cash will be tight in week 7" |
| Sources |
Bank balance (export Monday 07:05); receivables aging (07:12); payables schedule (07:14); payroll calendar |
None |
| Arithmetic |
Weeks 1 to 7: opening $212,640 + receipts $386,200 - payments $417,240 - payroll $150,000 |
None; "tight" cannot be checked |
| Cause |
Largest customer has paid its last 6 invoices in 61 days against 38 over the prior year, moving $29,000 from week 5 to week 8 |
None |
| Ruled out |
Seasonality (37 days this time last year); disputes (none open) |
Nothing considered |
| Reviewed by |
Treasury analyst, reran from the same exports |
Unknown |
| Action |
Account owner calls the customer this week; fallback: move one named $20,000 supplier payment from week 6 to week 8, within terms |
"Consider delaying payments" (which ones, by how much?) |
| Approver |
The controller, by name, before anything changes |
None |
| Recorded |
Cash forecast log, result due week 8 |
Nowhere |
The weak finding is even right: cash is tight in week 7. Look at what it invites. Someone delays whichever payments are easiest, perhaps to a supplier who matters. The real cause, a large customer paying 23 days later than it used to, goes untouched, and next month the same warning appears.
A composite pattern. What follows is illustrative, a pattern commonly described in deal and diligence work rather than any one company. A business gets repeated "cash is tight" warnings and handles each the easy way: it pays the suppliers who complain least a little later. Days payable creep up, the warnings quiet down, and the dashboard looks calm. Underneath, two or three customers have been paying later for a year, and suppliers have been financing the gap without being asked. It surfaces when a buyer or lender rebuilds working capital month by month. The apparent improvement turns out to be stretched payables, it gets treated as borrowed rather than earned, and the conversation about value changes. Every warning was right. None named a cause, so every fix treated the symptom. A right number with no cause is more dangerous than a wrong number, because nobody goes back to check it.
Redoing the arithmetic in two minutes
With the strong finding open and a calculator:
| Step |
Sum |
Running total |
| Opening cash |
|
$212,640 |
| Add expected receipts |
$212,640 + $386,200 |
$598,840 |
| Subtract scheduled payments |
$598,840 - $417,240 |
$181,600 |
| Subtract payroll (3 × $50,000) |
$181,600 - $150,000 |
$31,600 |
| Gap to the floor |
$50,000 - $31,600 |
$18,400 short |
Then test the cause. Put the $29,000 back into week 5: $31,600 + $29,000 = $60,600, which is $10,600 above the floor. The stated cause accounts for the whole shortfall. Had the balance stayed below $50,000, a second cause would be missing.
Check the fallback too: $31,600 + $20,000 = $51,600, which clears the floor by $1,600. That is a thin margin, and the approver should know it before saying yes.
Last, open the receivables export and look at the largest customer's last six invoices yourself. If they average about 61 days, the cause stands. The free customer payment terms drift check shows whether other customers are drifting the same way.
Where recording is not enough
Suppose everything above is done well. The finding is logged, the controller approves the fallback, the supplier payment moves, and week 7 closes at $51,600. Then the customer pays the $29,000 in week 8, at 63 days.
The record now holds a finding, an approval and a payment that moved. It does not hold the thing that matters most: this customer now pays about 23 days later than the forecast assumes, and next month's forecast still uses 38 days. The system recorded what happened. Nothing was responsible for what happened next. Unless someone owns the follow-up (updating the collection assumption, raising terms with the customer, checking whether the fallback is needed again), the same finding will arrive in four weeks, and someone will approve the same fallback again.
Templates
Finding review form (one page)
| Field |
What to write |
| Finding |
The claim in one line, with the period and the amount |
| Sources |
Each file or report, with its export time |
| Arithmetic redone by |
Name, date, and "matches" or the difference found |
| Cause stated |
The cause, with its own evidence |
| Alternatives ruled out |
Each alternative and the evidence that excludes it |
| Reviewed by |
Name, or the check that was applied, before the finding was used |
| Approver |
The named person who approves the action |
| Action |
What will change, where, by how much, by when |
| Recorded where |
The log, file or system that keeps this form |
| Result next period |
Did the cause hold? Did the action work? Held / adjust / wrong |
One form per finding above your action threshold. A finding that cannot fill the first four fields is not ready to act on.
Questions to ask any vendor on a call
Pick a real finding from the demo and ask them to walk through it on screen.
- "Show me this finding's sources. Which files did it read, and when were they exported?"
- "Can I redo this arithmetic with a calculator, from what's on the screen?"
- "What cause did it state, and what other causes did it rule out? Where does it show that?"
- "Who or what reviews a finding before I see it, and is that review recorded?"
- "What is this tool trained and checked to do, and what is it not allowed to do?"
- "Can anything change in my systems without a named person on my team approving it first?"
- "When my approver gets a request, what do they see? Show me the screen."
- "Do you report approve, reject and send-back rates, time to approve, and approvals later reversed?"
- "When a stated cause turns out to be wrong, how is that recorded, and can I see how often it happens?"
- "Where is the record kept, is it append-only, and can I export it if I leave?"
If a vendor cannot answer the first three with a real example, the rest do not matter yet. For one example of how a finding can carry its evidence, see Performis's trust page. Hold every vendor to the same questions, including us.
Metrics and KPIs for finding and approval quality
| Metric |
Formula |
Data source |
Target by method |
| Sourced findings |
Findings with named sources and export times ÷ findings acted on |
Finding review forms |
100% |
| Arithmetic redone |
Findings with arithmetic redone by a named person ÷ findings acted on |
Finding review forms |
100% above your threshold |
| Approval rate |
Requests approved ÷ requests decided |
Approval log |
Track by approver; no fixed target |
| Reject and send-back rate |
(Requests rejected + sent back) ÷ requests decided |
Approval log |
Above zero over any long period |
| Time to approve |
Median time from request to decision |
Approval log |
Your own trailing range; very short times on large items need a look |
| Approvals later reversed |
Approved actions undone or corrected later ÷ actions approved |
Approval log and record |
Your own trailing best; investigate each |
| Cause accuracy |
Stated causes later proved wrong ÷ causes stated |
Result next period field |
Track by tool and by type of finding |
Cause accuracy is the track record, the equivalent of a person's references, and the metric most tools never report.
Common mistakes
- Checking whether the number "looks right." Most teams test an AI finding against their gut. A finding that matches your gut feels confirmed and has not been checked at all. Redo the sum.
- Accepting a symptom as a cause. "Cash is tight" and "receipts are lower" describe the problem. A cause names who or what changed, and by how much.
- Skipping the add-back test. If the stated cause is smaller than the gap, there is a second cause nobody has named.
- Sending the approver a request without the finding. If the approver sees only "approve: move $20,000," they cannot judge it. They can only sign it.
- Celebrating a perfect approval rate. It may mean the tool is excellent. It may also mean nobody reads the requests. Check reversals and time to approve before deciding which.
- Never closing the loop. If nobody records whether the stated cause held, you never build a track record, and every finding is trusted on the same blind terms as the first.
AI prompt assistance
These prompts make a tool show its work. Do not paste confidential data into a tool your company has not approved.
1. Make a finding fill the form.
Restate your finding using exactly these fields: finding (one line, with period and amount), sources (each file with its export time), arithmetic (each figure and the sum), cause (with evidence), alternatives ruled out (with evidence), and what you are less sure of. If you cannot fill a field, write "not available" rather than estimating.
Check: open each named source yourself. Any field marked "not available" means the finding is not ready to act on.
2. Redo the arithmetic independently.
Here are the figures from a cash finding: opening balance, expected receipts, scheduled payments and payroll for weeks 1 to 7, and a minimum floor. Compute the closing balance and the gap to the floor. Show each step. Then add back a stated $29,000 delayed receipt and show the result.
Check: do the sum by hand. If the three totals differ, stop and find why.
3. Challenge the cause.
A finding says week 7 cash falls short because our largest customer now pays in 61 days instead of 38. List other plausible causes of a week-7 shortfall, and for each, the record that would confirm or rule it out. Do not say which is correct.
Check: test each alternative against your records with the person who owns that area, and note on the form which you ruled out.
Implementation guide
| Phase |
Days |
Owner |
Exit criteria |
| Set the standard |
1-30 |
CFO or controller |
Action threshold written; finding review form in use for every finding above it; first ten forms completed |
| Make approval real |
31-60 |
Controller, named approvers |
Every approval request carries the finding, sources and record; approve, reject, send-back and time-to-approve tracked by approver |
| Build the track record |
61-90 |
CFO |
"Result next period" filled for every finding; cause accuracy and reversals reported monthly; vendor questions asked of every tool that produces findings |
In the first month, try to complete the form for the last five findings someone acted on; the gaps show where to start. In the second, change what approvers receive. In the third, put cause accuracy and approval quality on the monthly review agenda, alongside the operating review system you already run.
Governance: the CFO owns the standard and the threshold. Each named approver owns their decisions and approval-quality numbers. The owner of each vendor relationship asks the vendor questions at purchase and renewal. How the broader rules fit together is set out in AI governance for finance and operations.
Downloadable assets
The finding review form, the vendor questions and the metrics table above are designed to be copied into a document or spreadsheet. For the worked example's cause, the free customer payment terms drift check shows which customers have started paying later than their usual pattern.
Related resources
Frequently asked questions
How do I know if I can trust AI output?
Check it the way you would check a new analyst's work. Ask for the sources with export times, redo the arithmetic, and test whether the stated cause accounts for the whole gap. If the output cannot show those, treat it as a lead to investigate before anyone acts.
What should an AI audit trail include?
The source files and export times, the arithmetic, the cause and alternatives ruled out, who reviewed it, who approved any action, what was done and what happened next. The record should be append-only (entries added, never overwritten) and exportable.
Is a human approval step enough to make AI safe in finance?
Only if the approver can judge the request and actually does. An approver who sees only "approve this payment change" can do nothing but sign. Give approvers the finding, the sources and the record, and track reject rates, send-backs, time to approve and reversals to see whether review is real.
How long should it take to verify an AI finding?
For a well-built cash finding, about two minutes for the arithmetic and a few more for the cause. If it takes much longer, the finding is missing its sources or workings, which is itself the answer.
What should I ask an AI vendor before buying?
Ask them to walk through a real finding's sources, arithmetic and cause on screen. Then ask what the approver sees, whether anything can change without a named approver, and whether they report approval quality and wrong causes. The full list is in Templates above.
How this works in a System of Performance
A finding is only as useful as the next thing that happens to it. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. To see where your own numbers stand first, bring it to us as a launch partner.