Every reorganisation leaves a mark in your data
Most finance teams are still paying for it
Each structural change creates layers of technical debt in ERP‑based finance: definitional debt in the meaning of key concepts, architectural debt in the systems built to reconcile those meanings, and continuity debt in the organisation’s ability to compare performance over time. When definitional debt is left unresolved, architectural workarounds multiply and continuity breaks accumulate. The result is finance data that works well enough for manual reporting, but is fragile, opaque, and poorly suited for scalable control and AI‑enabled planning.
Definitional debt: unstable meanings
Every finance function runs on definitions: what counts as revenue, how cost centres map to business units, which KPIs steer performance at group versus local level. These definitions are the shared language that makes it possible to compare one period to another, one entity to another.
When those definitions are inconsistent or weakly governed, the foundation cracks, not visibly. Finance teams adapt. Bridge files are built. Footnotes are added. Reports get produced. But the data beneath them is no longer what it appears to be.
Consider a group with fifteen business units across eight countries. Each unit has its own local ERP instance. The group chart of accounts was standardised in 2014, but three units were acquired after that, and two others negotiated local exceptions that were never fully resolved. Every group consolidation since then has required a manual mapping layer. Everyone knows it. Nobody has had time to fix it.
That mapping layer is definitional debt. It is not a code problem. It is a governance problem that has been deferred so many times it has become structural.
Chart‑of‑accounts inconsistency is the most visible form of definitional debt. KPI definitions are often equally fragile.
Gross margin at business unit level may use different cost inclusions than at group level. EBITDA definitions vary across entities depending on how legacy ERP configurations handle depreciation. Working capital is measured differently in acquired businesses than in organically built ones, because the acquired systems brought their own logic, and nobody has reconciled them.
The result is that finance teams spend significant time each period not analysing performance, but negotiating which version of a number is the right one. The absence of global chart‑of‑accounts standards and weak KPI governance are among the most frequently cited barriers to comparable financial reporting in complex organisations.
For human analysts, this is manageable, expensive and time‑consuming, but manageable. For AI models, it becomes a more fundamental training problem. A model trained across entities with different cost inclusions for the same KPI is not really learning to forecast performance. It is learning to navigate inconsistency. Those are not the same thing.
Architectural debt: workarounds baked into the system
Where definitional debt lives in the meaning of data, architectural debt lives in the structures that move and transform it.
Architectural debt consists of the integration layers, mappings, and customisations introduced to make inconsistent definitions work together. Local add‑on tables that reconcile different charts of accounts. Custom ETL scripts that align KPI logic across data warehouses. Point‑to‑point integrations that hard‑code assumptions about which entities belong to which business areas.
Individually, these workarounds are rational. They keep the business running. Collectively, they create an architecture that is fragile, opaque, and expensive to change.
Two patterns appear frequently. First, critical business logic ends up embedded in middleware and reports rather than in governed metadata, making it difficult to see where definitions actually live and even harder to change them consistently. Second, temporary fixes for specific acquisitions, reporting requirements, or local exceptions become permanent parts of the landscape. Over time, no one remembers which parts of the system reflect current design and which are artefacts of past compromises.
Architectural debt is often where symptoms show up, performance problems, reconciliation breaks, long lead times for change. But in many cases, the root cause is definitional: the architecture is complicated because the underlying definitions are not stable or consistent.
Continuity debt: broken time series and shifting structures
Continuity debt concerns what happens to data and control when structures change over time.
Continuity debt accumulates when reorganisations, acquisitions, and structural shifts are not accompanied by systematic remapping and documentation of how old structures relate to new ones. The organisational dimension structure, cost centres, profit centres, segments, regions, is at the core of this. These dimensions are the lenses through which management control is exercised and the cuts of data available for planning and analysis. They also change frequently.
When dimensions change without historical remapping, longitudinal comparability breaks. Last year’s cost centre is not this year’s cost centre, even if the label is the same. “Business Area North” in 2021 is not necessarily the same combination of entities as “Business Area North” in 2024.
Any group finance team that has tried to build a five‑year trend across a business that has been reorganised twice knows the practical result. The data exists for each period. The comparability across periods does not, not without significant manual reconstruction.
This is one of the failure modes that makes AI‑based planning and forecasting fragile. Time‑series models depend on temporal stability. When the definition of what is being measured shifts mid‑series, the model is learning from a signal that is partly performance and partly structural change. Separating the two is precisely what the model cannot do on its own.
Continuity debt is not only a data science problem. It is a management control problem: if the organisation cannot see its own history clearly, it cannot reliably distinguish between operational performance and structural change.
Why the order matters
Putting the three layers together:
Definitional debt lives in the language of finance: charts of accounts, KPI logic, organisational dimensions.
Architectural debt lives in the systems and integrations built to make that language work in practice.
Continuity debt lives in the way changes over time are, or are not, mapped, documented, and made comparable.
Definitional debt comes first because it sits closest to the meaning of the data. Architectural debt arises as systems try to reconcile inconsistent or evolving definitions. Continuity debt accumulates as those definitions and structures change without preserving the ability to compare across time.
Addressing architectural issues without fixing definitions is like repairing the plumbing in a building whose floor plan keeps changing. Addressing continuity issues utan stable definitions and transparent architecture is like reconstructing a history where the names of places keep being reused for different locations.
When definitions are unstable, every analysis becomes a special project. When architecture is opaque, every change becomes risky. When continuity is broken, every trend becomes a negotiation.
How to evaluate and prioritise the debt stack
A realistic approach does not begin with a transformation programme. It begins with a structured view of the debt that already exists, the triggers that are likely to create more of it, and the long‑term direction of the finance system landscape.
The mapping should therefore cover more than today’s pain points. It should also identify future triggers such as expected end‑of‑life in core systems, major upgrades, planned reorganisations, acquisitions, and changes in reporting logic. Seen through the debt stack, this means identifying where definitional debt already distorts meaning, where architectural debt has accumulated as compensation, and where continuity debt is likely to worsen if future structural changes are not mapped from the start.
Valuation becomes clearer when the same debt stack is used as the evaluation structure. Definitional debt should be assessed in terms of how much it undermines comparability and control. Architectural debt should be assessed in terms of how much it locks the organisation into a brittle landscape of integrations and custom logic. Continuity debt should be assessed in terms of how much it weakens the organisation’s ability to interpret trends over time. This makes prioritisation more disciplined: the question is not which problem is most irritating today, but which debt most seriously blocks the finance function’s future way of operating.
Long‑term goals, strategies, and focus areas matter because technical debt in finance is not static. It evolves with the system landscape. Yesterday, many organisations described their direction as best of breed. Today, the more useful question is often what kind of system ecology the finance function wants to sustain over time: what should be core, what can be modular, what must be standardised, and where flexibility is worth the cost. In that perspective, long‑term goals should be framed against the debt stack itself, what degree of definitional stability is needed, what level of architectural simplification is realistic, and how continuity will be preserved through future change.
That also means the work can never be completely “finished”. The desired system ecology has to be reviewed continuously, and the debt stack needs to be re‑evaluated as conditions change. Technical debt in finance is not a one‑off clean‑up. It is an ongoing management discipline for keeping definitions stable, architecture governable, and history readable.
The question worth asking
Before the next finance transformation, ERP rollout, or AI‑enabled planning initiative, one question is worth asking more concretely than most organisations currently do:
How much of our technical debt is definitional debt, how much is architectural debt, and how much is continuity debt built on top of the first two?
And beneath that:
How many of the key definitions in the finance environment are formally governed and how many still exist only because someone once set them up that way?
#DefinitionalDebt #ArchitecturalDebt #ContinuityDebt #TechnicalDebt #ERP #FinanceLeadership #AIreadiness #KaldLabs