)
)
We all know the unfortunate statistics. By 2027, more than 70% of recently implemented ERP initiatives will have failed to meet business objectives. What's less known is that these failures were set in motion long before the ink dried on the contract.
The demo landed well, the implementation partner’s delivery plan looked credible to the finance team, and the business case cleared. Commercial negotiation finalizes the terms across scope, SLAs, and implementation obligations.
But no one has realised they're simply replacing a legacy system with a traditional ERP that can only recreate the same financial limitations. They're already heading for a costly, slow and high-risk transformation.
This is 'The ERP Illusion'. It's easy to fall for, and you don't realise you have until it's too late.
A year or two in, and the AI program this investment was supposed to enable is underperforming, the close hasn’t shortened, and reconciliation effort has grown with transaction volume. In the aftermath, blame is apportioned to the vendor or the complexity of the integration. Rarely is it apportioned to the evaluation itself.
Demos only test what a system can show.
The questions here form a practical finance ERP evaluation framework for leaders who want to test the architecture, not just the interface. The questions we’ve compiled test the finance ERP architecture. Specifically, what it’s built on, how it processes financial events, and who controls the logic applied to them. Processing model, lineage design, and rules governance are where the limitations that follow you into a new system originate, alongside implementation decisions and data quality. These matter too, but they are choices made after the architecture is set.
Here are the five essential questions we've designed to test a finance ERP's architecture before you sign:
1. Are financial events processed individually as they occur, or after they’ve been aggregated?
Most ERP platforms collect transactions over a period and post summary entries to the general ledger after batching them. Accounting logic runs at the point of aggregation. It was a suitable design when real-time processing was expensive, and it still works adequately for statutory reporting in stable, lower-volume environments.
But when volume and complexity increase, operational cost becomes visible.
When events are batched before processing, source-level detail is compressed before it reaches the ledger. Subledgers and source systems may retain granularity, but the general ledger holds only a period summary. When balances don’t tie, reconciliation works backwards from those summaries, which means investigation work, adjustment work, and exception handling all land in the closing window.
For AI use cases that depend on finance data, specifically anomaly detection and forecasting built on finance records, event-level lineage is the baseline requirement. A period-end reconstruction limits what the model can explain and verify.
Ask your vendor:
Does the system process each financial event at the point it occurs, or does data move through batch cycles before posting? Where batch dependencies exist, are they architectural constraints or configuration choices?
A vendor who defaults to feature descriptions or cites implementation flexibility in place of a specific answer to how events are processed is indicating that the design hasn’t been resolved at the product level. Or, that the capability depends on how the system is configured rather than what it actually is.
2. Where does reconciliation happen, inside the data flow, or downstream?
Where reconciliation sits tells you how the system handles disagreement between data sources.
In an aggregate-first system, reconciliation runs after data has been batched and posted, with mismatches surfacing against ledger totals. In high-volume environments, the backward investigation work that follows is a standing operational task that grows as transaction count grows.
In an event-level system, matching runs during processing, with each payment tied to its settlement as it arrives. A discrepancy surfaces against the specific transaction that caused it before it reaches the general ledger.
Ask your vendor:
At what point in the data flow does matching occur? Is reconciliation a scheduled process that runs after posting, or does it happen at the transaction level during processing?
If it’s described as a scheduled job or separate module, that tells you matching depends on after-the-fact reconstruction of the data flow output. For high-volume environments, that has direct consequences for close length and analyst time.
3. Can finance own the accounting logic, or does changing it require IT?
In heavily customized ERP implementations, accounting logic lives in code built during implementation, usually by an SI partner. Adjusting it means a change request and a development cycle. Finance identifies the need; IT owns the delivery.
For CFOs, the cost is time and budget on every change. For CIOs, the structural risk is different. As the business evolves, the finance function’s dependence on the IT delivery cycle to update accounting rules creates a governance gap between what the business needs and what the system can reflect.
In a finance-owned rules model, accounting logic is configurable by finance directly, and it is subject to the same controls and audit governance that apply to any accounting policy update, without requiring a development ticket.
Ask your vendor:
If a new accounting standard takes effect next quarter, who initiates the change, who implements it, and what does a realistic end-to-end timeline look like?
‘Finance-friendly’ is a positioning claim. The change process, described specifically, is what separates a claim from a capability.
4. Is the audit trail a property of the architecture, or something added on top?
Two common patterns exist. The first is a logging layer or audit table that tracks changes after they’ve been made. This may be adequate for basic compliance, but its usefulness under audit pressure depends on whether the right information was logged in the first place, and how much work is needed to reconstruct the full picture.
The second is architecture where lineage is built into how data is stored. Figures traceable to their originating transactions, with the rules applied along the way captured as part of the record. When an auditor questions a balance or an anomaly surfaces in an AI output, the lineage is present and accessible. It doesn’t need to be assembled.
Ask your vendor:
If I ask for the full lineage of any posted figure, from source system and subledger treatment to general ledger posting, how is that produced? Is it available in real time, or does it require extraction and manual reconstruction?
The answer tells you whether lineage is complete and accessible by design, or produced on demand through investigation. Audit trail automation in finance depends on the former.
5. Does the system process data in real time, or does finance still depend on batch cycles?
In legacy ERP, data runs on a schedule. Overnight processing means positions reflect the last completed batch. The close falls at period-end because the system processes data in periods, and the closing window absorbs the accumulated transactions, exceptions, and reconciliation work from the period before it.
Real-time processing changes what finance can act on. For the AI-ready ERP architecture finance teams are investing in, particularly anomaly detection and forecasting, the gap between current transactional data and a period-end batch output determines whether the AI use case produces operational value. Or just produces a delayed picture faster.
Some batch dependency is expected and manageable, particularly in complex multi-system environments where source systems themselves don’t produce events in real time. The question is whether real-time capability is live and architectural, or on the product roadmap.
Ask your vendor:
Are financial positions available in real time? Where batch dependencies remain in the close process, are they structural constraints or configuration choices?
If real-time processing is a roadmap, the contract runs on today’s architecture. That’s worth knowing before it’s signed.
What the answers tell you
Vendors who answer these questions with specifics give you something contractually useful. They give you commitments around processing model, lineage completeness, rules governance, and real-time capability that can be built into implementation acceptance criteria.
Vendors who redirect to feature descriptions or cite implementation flexibility as the answer are indicating either that the design hasn’t been resolved at the product level, or that the sales process is doing work the product can’t.
It’s also advisable to run these questions against your current system before starting an evaluation. The architecture gap is often easier to identify in what you already have than to spot in a vendor demo of something new.
When ERP programs carry data problems into a new system, it's because the evaluation tested the wrong things.
The ERP Illusion examines what the right sequence looks like for how to choose a finance ERP, and when an ERP coexistence strategy makes more sense than a full replacement. Think architecture requirements defined before system selection, contract terms anchored to specific capability commitments, and what finance gets when that order holds.
If these questions have opened gaps, that’s where the analysis continues.
)
