Most CFOs can tell you the value of their ERP investment
Few can tell you the cost of what it has accumulated
Over the past two decades, ERP systems have been customised, extended, integrated with adjacent platforms and patched to handle exceptions the original implementation did not anticipate. Each decision was reasonable at the time. Collectively, they have produced something with a name in software engineering: technical debt.
Technical debt is not a metaphor for bad technology. It is a structural condition: the accumulated cost of deferred decisions that were individually defensible but collectively constraining. In finance, that debt sits in the data layer. When AI models are built on top of it, the debt does not disappear; it becomes a design flaw in the systems that are supposed to replace human judgement. The more of the decision process those systems automate, the more directly the debt shows up in outcomes.
If your ERP environment were a balance sheet, how large would the liability side be?
What the debt looks like and why it compounds
Three scenarios illustrate what this debt looks like in practice.
The chart of accounts that was ‘standardised globally’ except for the acquired entities that retained their local structures because the integration project ran out of time and budget. Five years later, those exceptions are still there, and every group consolidation requires a manual bridging file.
The ERP customisation that was built to handle a specific regulatory requirement in one market. The consultant who built it left. The documentation was never completed. The customisation now touches seven downstream reports, and nobody is certain what breaks if it is modified.
The planning model that runs on extracts from four different systems, reconciled in a spreadsheet that one senior controller maintains. It works. When that controller is on leave, it does not.
Each of these is a liability. None of them appears on any balance sheet. All of them become critical the moment you try to train an AI model on the data they produce.
Figure 1: Liabilities built over time
The debt compounds because it is invisible to the tools designed to manage it. ERP systems report on business performance; they do not report on the structural integrity of their own data models. The debt accumulates in the gaps between what the system was designed to do and what it has been adapted to do over time. A chart-of-accounts inconsistency that is tolerable in manual reporting becomes a semantic problem in AI feature engineering. A customisation that is manageable in a stable system becomes an integration risk in a cloud migration. A spreadsheet workaround that handles ten entities becomes unscalable at fifty.
Successive waves of technology, business intelligence, cloud analytics, advanced planning platforms, have not resolved this. They were built on top of it.
Three layers, one framework
The problems that accumulate in ERP-based finance environments are not random. They follow recognisable patterns, the same categories of failure appear across organisations, industries and implementation approaches. When mapped systematically, they organise into three layers. Understanding which layer a problem belongs to matters, because the appropriate response differs at each level.
The first layer is definitional: inconsistent or ungoverned definitions of the measures organisations use to run the business, KPIs, chart-of-accounts structures, organisational dimensions. The second is architectural: the accumulated weight of customisations, integrations and master data governance failures. The third is continuity: the erosion of historical comparability through reorganisations, system changes and compensating workarounds.
Definition. Architecture. Continuity. Not a technology framework, but a diagnostic lens for understanding where ERP data debt sits and why it persists.
The three layers are not independent. Definitional inconsistency tends to generate architectural workarounds. Architectural workarounds tend to break historical continuity. The debt compounds across layers, which is why addressing it requires understanding the sequence, not just the symptoms.
The balance sheet question
The honest answer, for most finance functions, is that the liability side is larger than anyone has formally assessed. The debt is not hidden; its symptoms are visible in every manual reconciliation, every bridging file, every report that requires a footnote to explain why this period is not directly comparable to the last. What has been missing is a way to see it as a single structural problem rather than a collection of operational inconveniences.
That distinction matters more now than it did before AI. When the cost of the debt was absorbed by human judgement, it was manageable. When AI models inherit it, the judgement that was compensating disappears, and the debt is exposed at scale.
The more specific question is where the debt tends to accumulate, and which layer does the most damage to AI-readiness.
What does the liability side of your ERP balance sheet look like and which item would you address first?
#TechnicalDebt #ERP #FinanceLeadership #AIreadiness #DataQuality #KaldLabs