Every agentic AI project we are asked to rescue has the same shape. The demo looked brilliant. The business case was signed off. Then, six weeks into build, the team discovers that the agent cannot reliably answer the question it was hired to answer — not because the model is weak, but because the data is.
The uncomfortable truth is that AI is a data project wearing a clever interface. If your numbers are inconsistent, late, poorly mapped or governed by handshake, the agent will simply automate the confusion faster. The CFO's job is to spot that risk before the budget is spent.
Here is the pre-flight checklist we use before any agent goes near a finance process.
1. Completeness: does the agent see the full picture?
An agent drafting variance commentary cannot do its job if half the cost centres are missing from the feed. A reconciliation agent cannot match what it cannot see. Before you build, audit the coverage of every source the agent will touch.
The question is not "do we have the data?" Most organisations have dozens of versions of it. The question is "does the agent have the same view the finance team would defend to an auditor?"
2. Timeliness: is the data fresh enough to act on?
Agents promise real-time decisions, but many finance data pipelines are still batch affairs that finish at 6 a.m. the following day. That is fine for some use cases and fatal for others.
Map the decision cadence to the data cadence. If the agent is expected to flag a mismatch during the close, it needs close-cycle data. If it is summarising month-end, next-day freshness may be perfectly acceptable. Mismatch the two and you have an expensive disappointment.
3. Lineage: can you trace the answer back to the source?
When an auditor asks why the agent posted a particular adjustment, "the model said so" is not an answer. Every output needs a trail: which source systems, which transformations, which mappings, which version of the prompt.
Finance-grade AI requires finance-grade traceability. If you cannot draw the lineage today, do not expect an agent to do it for you.
4. Governance: who owns the data when the agent breaks it?
Data ownership in most organisations is fuzzy. The ERP team owns the chart of accounts. Operations owns the product hierarchy. Commercial owns the customer segmentation. The agent touches all three.
Before deployment, define the owner of every data domain the agent relies on. When the agent produces an unexpected result, someone needs to know whether the source data changed, the mapping changed, or the model drifted. Without owners, you have a blame spiral, not a control environment.
A worked example: the variance commentary that failed
We recently reviewed a project where an agent had been trained to draft management commentary on P&L variances. The demo was impressive. In production, it kept attributing revenue swings to the wrong product lines.
The model was not the problem. The mapping between the sales system and the finance chart of accounts was. Two product families shared a legacy code. The human analysts knew the workaround. The agent did not. Until the mapping was fixed and governed, the agent was a liability.
The payoff
Teams that do the data work first deploy faster, spend less, and sleep better. Their agents are easier to audit, simpler to maintain, and far more likely to survive the first real close cycle.
The ones that skip it end up with a clever prototype and a long list of data debt to clear before it can ever go live.
Start with the data. The agent can wait.