The AI business case is being used to justify the wrong decision
A board commits to AI-driven finance, and the ERP program already on the agenda gets reframed as the route to it. But two years on, the AI outputs are still being questioned, and the project has stalled.
The post-mortem usually points to vendor overpromising or integration complexity. It rarely points to the assumption underneath the program – that a new ERP would change the financial data AI depends on. It won’t, and that data is where most of the problems begin.
What AI actually needs from your finance data
In most cases, the gap between AI ambition and delivery in finance is a data problem rather than a model or vendor problem.
For AI to work inside financial workflows – detecting anomalies, automating close, forecasting, generating real-time reporting – it needs three things from the underlying data:
Transaction-level detail. The individual events that make up a financial position, preserved end-to-end, rather than summaries or period-end aggregates.
Full traceability. Every output, journal entry, balance and reported figure traceable back to the originating transaction and every rule applied along the way. Without it, AI can tell you a number changed, but not why.
Immutability and auditability. Data fixed at the point of capture, with an audit trail that’s a property of the architecture rather than a process bolted on afterwards.
This is what finance-grade data means. It’s a function of how the finance ERP architecture processes financial events, not a feature you configure later. It’s the integrity an enterprise subledger is built to preserve, and what continuous close and finance data governance depend on downstream.
The scale of the gap is well documented. Just 7% of finance functions report real-time transactional data flows, according to Aptitude, Microsoft and HSO’s most recent Global Autonomous Finance Benchmark. For most, data reaches the AI batched, summarized and days old, with the detail the model needs already stripped out.
Most ERP architectures still process data the wrong way for AI
The most widely adopted ERP platforms – SAP, Oracle, Workday and NetSuite among them – were built around a model where financial data is collected, aggregated and then processed. Batch cycles, period-end consolidation and accounting logic are applied after reconciliation.
That was a reasonable design for statutory reporting, and it still works for it. But as a foundation for AI, it doesn’t.
When data is aggregated before it’s processed, detail is lost. The granularity AI needs is stripped back to what the general ledger requires for compliance, so what reaches reporting is a summary of what happened, rather than the full record of it.
Layering AI on top of this summary amplifies the problem. Anomaly detection that can’t separate genuine variance from a reconciliation artifact produces false positives finance can’t act on. Forecasting built on period-end aggregates is working from a reconstruction. The outputs get questioned and re-validated, and the effort to verify them often outweighs the time saved. Because this is architectural, it follows you into the new ERP if the new ERP processes data the same way.
How the two architectures process financial data |
Aggregate-first architecture | Finance ERP architecture |
Data collected, aggregated, then processed | Financial events processed individually as they occur |
Reconciliation happens downstream at period-end | Reconciliation runs continuously in the flow of data |
Detail stripped back to what the ledger requires | Transaction-level detail preserved from source to ledger |
AI works on a reconstruction of what happened | AI works on a record of what’s happening |
The sequence most evaluations get wrong
Most ERP evaluations start by choosing the platform, then configure it to handle the data, then build AI on top. The order is the problem.
By the time anyone tests how financial data is actually processed, the configuration, integrations and implementation assumptions are locked in. Fixing the foundation at this stage is slower and far more expensive – and the AI initiative that justified the program is the element that suffers.
The work that prevents this happens before selection. Defining what finance-grade data requires – transaction-level processing, end-to-end traceability, controls in the flow of data – and making these the criteria a platform has to meet.
Put the data model before the system decision, and you know what the architecture has to do before any contract is signed. The sequence is also how you de-risk the migration itself.
There’s a fuller test worth running once you’re in vendor conversations – a set of questions, one for each requirement your finance AI needs from your data, with what a strong answer should sound like and what a weaker one reveals. (You can read about them in our blog, ‘Five questions your ERP vendor doesn’t want you to ask about AI.’)
What changes when the architecture is right
When financial events are processed at the transaction level – individually, as they occur, with accounting logic applied immediately and lineage preserved from source to ledger – AI operates on a record rather than a reconstruction.
Anomaly detection runs continuously, against real events instead of period-end summaries. Forecasting is built on granular, traceable data finance can defend. The close becomes a confirmation step, because the underlying work has already been handled in the flow of data.
Finance shifts from reporting on what happened, to operating on what’s happening now. That’s the AI ambition boards want to achieve, and the ERP decision is where it’s enabled or lost.
Where Fynapse fits
This is the model finance-grade architecture points to, and it’s the principle Fynapse is built on. The Super Ledger processes financial events as they occur – transaction-level, traceable, immutable from the point of capture. Accounting logic is owned by finance rather than buried in code-heavy ERP customization, and every output is explainable by design.
For organizations already committed to SAP, Oracle or Workday, Fynapse can sit alongside the existing ERP as the finance system of record, providing the finance-grade foundation the operational ERP wasn’t built to deliver. For organizations replacing fragmented finance systems, Fynapse operates as the Finance ERP itself.
Either way, the AI program that justified the ERP investment gets the data it needs to work.
For the full diagnostic – what to look for, the questions to ask, and how to put the data foundation before the platform – download The ERP Illusion: How to de-risk your ERP migration
)
)
)
)
