Why the data foundation decides whether finance AI works
Finance teams adopt AI expecting faster answers and earlier warning of what's coming. But too often it underdelivers, and the data is usually the reason.
Just 7% of finance functions report real-time transactional data flows, according to Aptitude, Microsoft and HSO's Global Autonomous Finance Benchmark – for most, it reaches the AI batched, summarized and days old, with the detail the model needs already stripped out before it arrives.
This is why evaluation is better aimed at the foundation than the AI on the surface. The model on top can be swapped or upgraded as the technology moves on – while the data architecture underneath sets the bar on what any of it can do.
The AI Reckoning sets out five things finance AI needs from your data. Here are five questions – one for each – to put to ERP vendors, with what to look for in their answers.
Question 1: Does your AI work on transaction-level data in real time, or on batch summaries?
This tests real-time granularity.
What a good answer sounds like: the AI reads individual transactions as they’re processed, with the detail preserved all the way from source to ledger. Finance can drill from a summarized balance to the transactions underneath without raising an IT ticket.
What a vague answer reveals: ‘near real-time’, nightly syncs, or ‘we feed the AI from the data warehouse’. This means the AI is working from data that’s already summarized and after the fact – and no amount of model sophistication will make up for detail that was stripped out on the way in.
Question 2: Can every AI-generated output be traced back to the event that created it?
This tests transaction-level lineage.
What a good answer sounds like: every figure traces back to its originating event and the rules applied along the way, programmatically and on demand. The trail is preserved inside the architecture, not rebuilt on request.
What a vague answer reveals: ‘we can reconstruct it’, or ‘our team can investigate when you need to’. Reconstruction is a workaround. It’s the difference between an output that’s plausibly right and one that’s provably right – and in finance, only provably right will survive an audit.
Question 3: Does your processing run continuously, or only when we close?
This tests continuous processing.
What a good answer sounds like: reconciliation and validation run as transactions arrive, exceptions surface immediately, and the close becomes a confirmation of work already done rather than a reconstruction exercise.
What a vague answer reveals: ‘real-time dashboards’ that still depend on a period-end close. Live data feeds and continuous processing are not the same thing. The question is whether finance acts on the data as it flows, not just whether it arrives quickly.
Question 4: Are your controls built into the architecture, or applied on top?
This tests embedded controls.
What a good answer sounds like: governance lives in the accounting engine. AI operates within defined tolerance thresholds and escalation paths, subject to the same access controls as a human user, and every automated action is recorded alongside its output.
What a vague answer reveals: governance is handled by ‘policies’, a separate compliance tool, or manual review after the event. Controls bolted on after the fact don’t scale as automation grows – and this is where audit findings tend to start.
This tests audit-ready outputs.
What a good answer sounds like: outputs are transparent, explainable and repeatable by design. An auditor can verify them independently, and the same inputs return the same result on every run. Fynapse CEO Alex Curran describes this as ‘glass-box AI’ – built so the reasoning is inspectable and the result is reproducible.
What a vague answer reveals: a confident demo that can’t promise consistency. Generative explanations that vary from one run to the next are a non-starter in a function where every number has to be defensible the moment it’s produced.
What the pattern of answers tells you
A vendor that keeps describing features added to a finished system is describing AI that’s enabled. A vendor that describes a system built so AI can operate inside it, on governed and traceable data, is describing AI that’s native. And only an AI-native foundation can deliver all five requirements at once.
Most large incumbents are adding AI to architecture designed for a pre-AI, batch world. This can speed up individual tasks, but it can’t move the ceiling the architecture sets.
Another warning sign – extended timelines. An implementation programme that stretches into years usually traces back to the limitations of the architecture. A long modernization timeline can say a lot about the system being sold.
The good news for anyone partway through an evaluation: testing for these five capabilities doesn’t mean ripping out the operational ERP you’ve spent years embedding. A finance system of record is designed to sit alongside Oracle, SAP or whatever runs your operations, taking the finance layer and giving AI the data it needs.
For the full five requirements, and what good can look like when the right foundations are in place, download The AI Reckoning.
)
)
)
)
){kind=icon}
