Each structural change in ERP‑based finance introduces new layers of technical debt: 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 remains unresolved, architectural workarounds proliferate and continuity gaps widen. Over time, these effects compound. The result is finance data that may suffice for manual reporting, but is ultimately fragile, opaque, and ill‑suited for scalable control, reliable analytics, 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 form the shared language that makes comparison possible, across periods, across entities, and across decisions.

When those definitions are inconsistent or weakly governed, the foundation begins to crack, not visibly but structurally. Finance teams adapt. Bridge files are created. Footnotes multiply. Reports are still delivered. Yet the data beneath them gradually diverges from what it appears to represent.

Consider a group with fifteen business units across eight countries. Each unit operates its own ERP instance. The group chart of accounts was standardised in 2014, but three units were acquired later, and two others negotiated local exceptions that were never fully resolved. Since then, every consolidation has depended on a manual mapping layer. Everyone is aware of it. No one has had the mandate or capacity to fix it.

That mapping layer is definitional debt. It is not a technical issue, it is a governance failure that has been deferred often enough to become structural.

Chart‑of‑accounts inconsistency is its most visible form, but KPI definitions are often just as fragile.

Gross margin at the business unit level may include different cost components than at the group level. EBITDA varies depending on how legacy ERP configurations treat depreciation. Working capital is calculated differently in acquired entities than in organically built ones, because inherited logic was never reconciled with group standards.

The consequence is that finance teams spend each reporting cycle not analysing performance, but negotiating which version of a number is actually valid. In complex organisations, weak chart‑of‑accounts standards and poor KPI governance remain among the most persistent barriers to comparability.

For human analysts, this is expensive and time‑consuming, but manageable. For AI models, it is something else entirely. A model trained on structurally inconsistent definitions is not truly learning to forecast performance, it is learning to navigate inconsistency. Those are fundamentally different tasks.

Architectural debt: workarounds baked into the system

Where definitional debt resides in the meaning of data, architectural debt resides in the structures that move and transform it.

Architectural debt takes the form of integration layers, mappings, and customisations introduced to make inconsistent definitions work together. Local add‑on tables reconcile divergent charts of accounts. Custom ETL scripts align KPI logic across data platforms. Point‑to‑point integrations embed assumptions about how entities map to business areas.

Individually, these workarounds are rational, they keep the business running. Collectively, they produce an architecture that is fragile, opaque, and increasingly costly to change.

Two patterns recur. First, critical business logic becomes embedded in middleware, scripts, and reports rather than in governed metadata. As a result, it is difficult to determine where definitions actually reside, and even harder to change them consistently. Second, temporary fixes for acquisitions, reporting demands, or local exceptions become permanent features of the landscape. Over time, the distinction between intentional design and accumulated compromise disappears.

Architectural debt is often where symptoms surface: performance bottlenecks, reconciliation breaks, and long lead times for change. Yet in many cases, the root cause is definitional. The architecture is complex because the underlying definitions are neither stable nor consistently governed.

Continuity debt: broken time series and shifting structures

Continuity debt concerns what happens to data and control as structures change over time.

It accumulates when reorganisations, acquisitions, and structural shifts are not accompanied by systematic remapping and clear documentation of how legacy structures relate to new ones. At the centre of this issue are organisational dimensions: cost centres, profit centres, segments, regions, which define how management control is exercised and how data can be analysed. These dimensions are critical, and they change frequently.

When they change without historical remapping, longitudinal comparability breaks down. Last year’s cost centre is no longer this year’s cost centre, even if the label remains the same. “Business Area North” in 2021 does not necessarily represent the same underlying structure as “Business Area North” in 2024.

Any group finance team that has attempted to build a five‑year trend across a business that has been reorganised more than once recognises the outcome. The data exists for each individual period, but comparability across periods does not, at least not without extensive manual reconstruction.

This is a core failure mode for AI‑enabled planning and forecasting. Time‑series models depend on temporal stability. When the underlying definition of what is being measured shifts mid‑series, the signal becomes a mix of operational performance and structural change. Distinguishing between the two is precisely what the model cannot do on its own.

Continuity debt is therefore not only a data science challenge. It is a management control problem. If an organisation cannot clearly reconstruct its own history, it cannot reliably separate true performance from the effects of structural change.

Why the order matters

Putting the three layers together:

• Definitional debt lives in the language of finance: charts of accounts, KPI logic, and organisational dimensions.

• Architectural debt lives in the systems and integrations built to make that language operational.

• Continuity debt lives in how change over time is, or is not mapped, documented, and made comparable.

Definitional debt comes first because it sits closest to the meaning of the data. Architectural debt follows, as systems attempt to reconcile inconsistent or evolving definitions. Continuity debt accumulates when those definitions and structures change without preserving comparability over time.

Addressing architectural issues without resolving definitions is like repairing the plumbing in a building whose floor plan keeps changing. Addressing continuity issues without stable definitions and transparent architecture is like reconstructing a history where the same place names are repeatedly assigned to different locations.

When definitions are unstable, every analysis becomes a bespoke exercise. When architecture is opaque, every change becomes a risk. 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 understanding of the debt that already exists, the triggers likely to create more of it, and the long‑term direction of the finance system landscape.

This assessment must extend beyond current pain points. It should also identify future triggers, expected end‑of‑life in core systems, major upgrades, planned reorganisations, acquisitions, and changes in reporting logic. Viewed 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 intensify if future structural changes are not mapped from the outset.

Valuation becomes clearer when the same lens is used for evaluation. Definitional debt should be assessed in terms of how it undermines comparability and control. Architectural debt should be assessed in terms of how it locks the organisation into a brittle landscape of integrations and custom logic. Continuity debt should be assessed in terms of how it erodes the organisation’s ability to interpret trends over time. This creates a more disciplined basis for prioritisation: the question is not which issue is most visible today, but which form of debt most constrains the finance function’s future operating model.

Long‑term direction matters because technical debt in finance is not static, it evolves with the system landscape. Where organisations once described their target state as “best of breed,” the more useful question today is what kind of system ecology the finance function aims to sustain over time: what should be core, what can be modular, what must be standardised, and where flexibility justifies its cost. In this perspective, strategic goals should be defined in relation to the debt stack itself, what degree of definitional stability is required, what level of architectural simplification is achievable, and how continuity will be preserved through future change.

This also implies that the work is never truly complete. The desired system ecology must be continuously reviewed, and the debt stack reassessed as conditions evolve. Technical debt in finance is not a one‑off clean‑up exercise. It is an ongoing management discipline, one that keeps 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, how much is architectural, and how much is continuity debt built on top of the first two?

Beneath that sits a more fundamental question:

How many of the key definitions in the finance environment are formally governed—and how many persist simply because someone once configured them that way?

#DefinitionalDebt #ArchitecturalDebt #ContinuityDebt #TechnicalDebt #ERP #FinanceLeadership #AIreadiness #KaldLabs

The ambition is real. The investment is substantial. The people involved are capable. Yet, two years later, the organisation is not where it set out to be and no one can fully explain why.

Estimates in the change management literature often place failure rates around 60–70 percent, although results vary by context and methodology. Consultant and survey‑based evidence suggests the rate may be even higher for complex and ambitious programmes (BCG Henderson Institute, 2024; Errida and Lotfi, 2021).

Programmes tend to fail when they start without a concrete definition of success, drift when that definition is not sustained, and reach end users too late to deliver meaningful impact. This article examines each of these failure modes in sequence and explores what organisations that navigate them successfully do differently.

These observations are grounded in work inside large organisations, focusing on process change, performance management, and operating model design. The patterns described here are not outliers, they are systemic.

The need that was never properly understood

Most programmes start with a solution rather than a need. The question that gets skipped, what exactly needs to be different, for whom, and how we would know, often determines whether the programme succeeds.

Most change programmes begin with a solution. A new system. A restructured function. A redesigned process. The decision to act comes before the underlying need has been clearly understood.

Heifetz and Linsky identify this as a consistent predictor of failure: organisations apply technical solutions to adaptive problems (Heifetz and Linsky, 2002). Technical problems have known solutions. Adaptive challenges require changes in how people think and work, changes that no technical implementation can resolve on its own. The outcome is predictable: superficial improvements that do not hold, resistance reframed as non‑compliance, and change fatigue that accumulates over time.

I have sat in many rooms where programmes were built around objectives that no one could translate into operational terms. “Improve efficiency.” “Strengthen governance.” These are directions, not destinations. They indicate where to move, but not when you have arrived.

Evidence from large‑scale transformation studies shows that organisations which define roles clearly and maintain transparent progress tracking achieve significantly higher success rates than those that do not (Vayyavur, 2015). The gap between direction and destination is not a minor planning issue, it is where most programmes lose their way.

That gap cannot be closed without a definition of success that is concrete enough to navigate by.

The picture that needs to exist before the work begins

A vision is not enough. What matters is a description of success so concrete that it produces the same judgement regardless of who applies it. Without that, what looks like consensus is often just untested agreement.

Before any design work begins, one thing must exist: a concrete picture of what the organisation looks like when the change has actually worked. Not a vision. Not principles. A description specific enough that two people reading it would independently agree on whether a given situation matches it.

What decisions are made differently? By whom? What can a controller do on a Monday morning that they cannot do today? What has stopped happening, activities that currently consume time and create friction?

Vague ambitions produce precise disappointments.

This level of concreteness is uncomfortable early on. It forces choices before people feel ready. It surfaces disagreements that are easier to defer. And for that reason, it is often skipped.

A workshop is scheduled. The facilitator has a deadline. The group brainstorms. The output resembles clarity, but functions as ambiguity. Two weeks later, different teams are designing toward different end states, and no one has noticed.

Kotter argues that a vision must be concrete enough to guide individual decisions (Kotter, 1996). In practice, the absence of an operationalised end state is one of the most common points at which programmes lose direction. Armenakis and Harris show that readiness for change depends on whether people understand a clearly defined future state, when that picture is vague, commitment does not follow (Armenakis and Harris, 2002).

The disagreements that emerge when the end state is described concretely are not a side effect. They are the work. Addressing them early costs a conversation. Leaving them unresolved until execution costs months.

The model below maps this across the four phases where these decisions are made and where they are most often deferred (see Figure 1).

Figure 1: Navigating Complex Change

Having a picture is necessary. Keeping it honest throughout the work is harder.

The comparison that never gets made

Programmes that measure activity rather than direction drift without noticing. Parked exceptions become permanent features. The solution goes live, while the problem it was meant to solve quietly remains.

Even when a programme starts with reasonable clarity, something tends to go wrong in the middle. Milestones are met. Budgets are tracked. Status reports are produced. What is missing is a regular, honest comparison between where the programme is heading and the concrete picture of where it was supposed to go.

The mechanism is gradual. A complex process has too many edge cases to resolve before a deadline, so exceptions are parked. “Later” arrives, and those exceptions have become permanent features of the solution, each requiring the manual handling the design was meant to eliminate.

Research on implementation fidelity shows that drift from the intended design is a common pattern when delivery is not actively measured against original intent (Carroll et al., 2007). Studies of process workarounds further show that these deviations are not random; they are goal‑driven adaptations to constraints the formal process cannot accommodate (Alter, 2014). When parked exceptions are absorbed into the final solution, temporary workarounds become structural. The distance from the original intent grows until acknowledging it would mean admitting the programme has been heading in the wrong direction. That admission is costly and so it is avoided.

Understanding why programmes drift is not enough. The more immediate question is why they begin to slow down before the drift becomes visible.

Why things slow down

Slowdown is seldom about resistance or resources. It is about clarity. When the problem is not understood well enough for people to judge what a meaningful next step is, increasing pace does not create progress, it amplifies confusion. Speed is not the answer, clarity is.

One of the most common reasons programmes lose momentum is both simpler and harder to admit than resistance or lack of resources: no one fully understands the problem or how to approach it. Understanding a problem well enough to discuss it is not the same as understanding it well enough to act on it.

This often shows up in a familiar pattern. A key stakeholder is senior enough to matter and busy enough that their calendar is always full. The planning cycle intervenes. Forecast work takes priority. Weeks pass. The person whose input is critical has not been in the room, and the programme adapts by working around their absence instead of resolving it.

This is rarely a question of commitment. Studies of BPR initiatives point to competing priorities and weak planning as recurring drivers of stakeholder disengagement, more so than outright unwillingness (Bashein and Markus, 1994). While the evidence comes from a BPR context, the pattern generalises. When involvement is not defined concretely enough to compete with other demands, it will not compete.

When a programme slows without an obvious cause, the right question is not about pace or effort. It is whether the people doing the work have a clear enough understanding of the problem to recognise what a good next step looks like.

Working at the right level, all the time

Strategy, process design, and daily operations require different types of conversations. When these levels are conflated, alignment becomes assumed rather than real, and people leave with the impression of agreement that does not hold in practice. Keeping them connected without collapsing them into one is not a matter of structure. It is a matter of discipline.

Complex change unfolds simultaneously at the level of strategy, process design, and daily operations. Each level requires different conversations, different language, and different decisions. When they become conflated, people leave the room believing they have agreed when in reality they have not.

A steering group agrees that the new process must “support the business.” Three weeks later, the operations team designs approval workflows requiring four sign‑offs for every purchase order. No one connects the two. The strategic decision was made at one level; its operational consequences were designed at another. No one was present in both conversations.

Research on multi‑level change shows that failures to translate across organisational levels are a recurring cause of breakdown in implementation (Whelan‑Berry and Gordon, 2000). Navigating complexity requires that people are explicit, at any given moment, about which level they are operating on and how it connects to the others. Not as a one‑time alignment exercise, but as a continuous discipline.

When this breaks down, the symptoms are predictable. Senior leaders believe the change is further along than it is. Operational teams optimise for problems that strategic decisions have already made irrelevant. Middle layers absorb the cost of the disconnect between them.

Keeping the levels connected is not primarily a structural problem. Governance models can support it, but they do not solve it. It is a discipline exercised in individual conversations and it must be built into how the programme works from the outset.

But even this is not the whole story. The most damaging failures in complex change are often not structural. They are human.

The human side that gets abstracted away

Abstract warnings create alibis rather than readiness. Communication mantras fill silence but do not create stability. Late handovers delegate the hardest work without the authority required to carry it out. All three are predictable and all three are preventable.

Change management is present in most large programmes. What it rarely contains is the same level of concreteness that the rest of the programme lacks.

Many programmes warn that things will get worse before they get better. When that warning is not tied to what will be harder, for whom, and when, it does not create readiness, it creates an alibi. People can prepare for specific difficulty. They cannot prepare for difficulty in general.

Then there is the communication mantra. At the very point where uncertainty is real, the response becomes repetitive: we do not know yet, but we will communicate when we do. Said once, this is honest. Repeated throughout a programme, it signals that no one is in control. Weick’s work on enacted sensemaking explains why: in uncertainty, people construct meaning from whatever cues are available, and those interpretations shape behaviour (Weick, 1988). When communication fails to provide stable reference points, people fill the gaps themselves typically with more negative assumptions than reality warrants (Barr et al., 1992).

The third failure is the late handover. Users are involved too little for too long, and then too much too late. A general training session before go‑live is not change management. It is notification. Both academic and practitioner research show that insufficient user involvement creates risks comparable to poor problem definition (Maditinos et al., 2011; Prosci, 2024). People do not resist change because they cannot handle it. They resist when asked to carry outcomes they were not part of shaping.

Bringing people in earlier does not slow programmes down. It removes the resistance that slows them down later.

Staying oriented during the work

Orientation requires more than alignment in principle. It requires a shared reference point concrete enough to be applied in the moment, and the discipline backed by mandate to ask the question organisations avoid once momentum builds: are we still going where we said we were going?

Keeping a programme oriented toward its original purpose requires more than good intentions.

The end state must remain visible and shared throughout the programme—not just at the beginning. Every significant decision needs to be tested against it. Not “does this seem reasonable?” but “does this move us closer to the specific outcome we agreed on?”

A programme director in a finance transformation described it this way: every week we reviewed what had been delivered. Nobody reviewed whether it was still pointing at the same destination. By the time that question was asked, six months of work had quietly shifted the target.

This requires someone with both the mandate and the perspective to ask the question organisations find most uncomfortable: are we still going where we said we were going, or have we quietly started going somewhere else?

What this looks like in practice

The organisations that navigate complex change well invest disproportionate effort at the outset, maintain a living picture of the end state, and treat slowdown as a signal to investigate rather than a problem to work around.

The organisations I have seen navigate this well share a few habits.

They invest disproportionate effort at the outset, conversations about what the end state means in concrete operational terms, before any design work begins. These discussions are often frustrating. They surface disagreements early and prevent the slower, more expensive breakdowns that occur later.

They maintain a living description of the target state, updated when genuine learning changes the picture, and held firm when pressure pushes to lower ambition.

They build regular comparison into the programme rhythm. Not just “are we on track,” but “on track toward what and how do we know?”

They make levels of abstraction explicit in every significant conversation, and treat mismatches as issues to resolve, not something to work around.

They involve the people closest to the work early enough that their knowledge shapes the design rather than so late that their resistance shapes the outcome.

Not everyone reading this has the mandate to redesign how a programme operates. But anyone involved can ask the question that matters most: do we have a concrete enough picture of where we are going that I would recognise if we started moving away from it?

If the answer is no, that question is worth raising regardless of where you sit.

The question worth asking before the next programme starts

Most of what goes wrong in complex change is not inevitable. It is the predictable outcome of questions left unasked because they were uncomfortable at the start.

Change is hard. Organisations are complex. Resistance is real.

But a surprising share of the difficulty comes not from the complexity of the change itself. It comes from never having established a concrete enough picture of what the change is actually for, and never maintaining that picture clearly enough to navigate by.

Before the next programme starts, one question is worth sitting with longer than feels comfortable.

If this works, what exactly will be different, and how will we know?

If that question does not have a concrete answer, everything built on top of it is built on assumption. And assumption is not a foundation. It is a reason to start over.

References

Alter, S. (2014). Theory of workarounds. Communications of the Association for Information Systems, 34, 1041-1066.

Armenakis, A.A. and Harris, S.G. (2002). Crafting a change message to create transformational readiness. Journal of Organizational Change Management, 15(2), 169-183.

Barr, P.S., Stimpert, J.L. and Huff, A.S. (1992). Cognitive change, strategic action, and organizational renewal. Strategic Management Journal, 13(S2), 15-36.

Bashein, B.J. and Markus, M.L. (1994). Preconditions for BPR success and how to prevent failures. Information Systems Management, 11(2), 7-13.

BCG Henderson Institute (2024). Familiar yet fatal: 10 common pathologies of failed change efforts.

Carroll, C., Patterson, M., Wood, S., Booth, A., Rick, J. and Balain, S. (2007). A conceptual framework for implementation fidelity. Implementation Science, 2(1), 40.

Errida, A. and Lotfi, B. (2021). The determinants of organizational change management success. International Journal of Engineering Business Management, 13, 1-15.

Heifetz, R.A. and Linsky, M. (2002). Leadership on the Line. Harvard Business School Press.

Kotter, J.P. (1996). Leading Change. Harvard Business School Press.

Maditinos, D., Chatzoudes, D., & Tsairidis, C. (2011). Factors affecting ERP system implementation effectiveness. Journal of Enterprise information management, 25(1), 60-78.

Prosci (2024). Why do ERP implementations fail?

Vayyavur, R. (2015). ERP implementation challenges & critical organizational success factors. International Journal of Current Engineering and Technology, 5(4), 2347-5161.

Weick, K.E. (1988). Enacted sensemaking in crisis situations. Journal of Management Studies, 25(4), 305-317.

Whelan-Berry, K.S. and Gordon, J.R. (2000). Effective organizational change: New insights from multi-level analysis. In Academy of Management Proceedings (Vol. 2000, No. 1, pp. D1-D6). Briarcliff Manor, NY 10510: Academy of Management.

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

AI investment in finance has reached macro scale. Yet finance teams continue to spend a disproportionate share of their time fixing data rather than analysing it. The organisations deriving real value are not those with the most advanced algorithms, but those that entered this wave with cleaner data, tighter controls, and governance that stands up to assurance. The constraint is not technical capability. It is the accumulated structural debt embedded in the finance data model.

If your finance systems produce sophisticated reports that controllers still do not trust, this article is for you.

The Data

Recent studies from Gartner, FP&A Trends, and KPMG point in the same direction: AI investment is accelerating rapidly, while the data foundations in finance remain weak.

Gartner’s 2026 forecast estimates that global AI-related spending will reach approximately $2.5 trillion by 2026 (Gartner, 2026). At the same time, around one-third of finance leaders identify poor data quality as the single biggest barrier to adopting AI in finance (Gartner, 2025).

The 2025 FP&A Trends Survey provides more granular evidence (FP&A Trends Group, 2025). Only 2 percent of organisations consider their FP&A functions optimised. More than 60 percent remain constrained by manual processes and inconsistent data, and just 17 percent rate their data quality as good. Most strikingly, nearly half of FP&A time—46 percent—is still spent on data collection and validation rather than on analysis and decision support.

KPMG’s 2026 Global AI in Finance report, based on responses from 1,013 senior finance leaders across 20 countries and 13 sectors, offers a third perspective (KPMG, 2026). Active AI use in finance has more than doubled over the past two years, and 71 percent of organisations report that AI is meeting or exceeding ROI expectations. However, the strongest gains are concentrated in judgement-intensive activities. Data quality, integration, and assurance readiness consistently emerge as the key differentiators between organisations achieving performance at scale and those that are not.

Three findings are consistent across all three sources:

• AI investment in finance has moved from experimental to macro scale.

• Finance teams continue to spend a significant share of their time fixing data rather than analysing it.

• Organisations with cleaner data and stronger governance realise disproportionately higher returns from AI.

Taken together, the implication is clear: AI does not compensate for structural weaknesses—it amplifies them. Existing data quality, control environments, and process design are not bypassed; they are exposed and scaled.

What AI Actually Learns in Finance

AI models in finance learn whatever patterns the data allows them to see including structural inconsistencies. When an experienced analyst encounters an unexpected variance, they apply context and professional judgement. They recognise that a reorganisation took place in Q2 last year, that cost centres were restructured, or that a new revenue recognition policy was introduced.

A forecasting model trained on three years of P&L data has no such contextual buffer. If cost centre structures were reorganised twice during that period and historical data was not consistently remapped, the model will treat those structural breaks as part of the underlying pattern. Its outputs may appear plausible, even statistically well calibrated, while embedding distortions that a controller would have discounted almost instinctively.

This is not primarily a failure of the algorithm. It is a reflection of the data-generating process. The model has inherited the organisation’s structural data debt and encoded it as parameters.

One effective response is to establish restated history domains, where past reorganisations are systematically remapped and exposed through governed data products. Models can then learn from a stable, internally consistent slice of history rather than from a fragmented landscape. However, this approach depends on visibility: breakpoints, remappings, and data lineage must be explicit in the underlying structures. Where these foundations are missing, each new AI use case simply propagates the same structural flaws into a wider set of decisions.

Two Decades of ERP and the Finance Data Model

Enterprise resource planning systems were rolled out across the 1990s and 2000s with a promise of integration: one system, one version of the truth. A substantial body of research and practical experience has since pointed to a more ambivalent reality. In many organisations, ERP has reshaped fragmentation rather than eliminated it.

Charts of accounts that are internally coherent within each business unit, yet difficult to compare across entities. Cost centre structures redesigned multiple times without systematic restatement of historical data. Integration landscapes that have evolved into layered combinations of ERP modules, consolidation tools, treasury systems, and spreadsheet-based shadow systems.

For group finance, the consequences are immediate and familiar. Reconstructing a ten-year trend across multiple reorganisations quickly reveals the underlying problem: the data exists, but it does not align. It resides in different systems, reflects different structures, and follows different logics over time.

Comparability is not missing by accident. It has been systematically eroded.

AI Removes the Human Buffer

For much of the past two decades, finance functions have managed data debt through human buffers rather than structural fixes. Controllers and analysts have acted as intermediaries between imperfect systems and decision-makers identifying anomalies, reconciling inconsistencies, and applying judgement where systems fall short.

AI changes the economics of this arrangement. As models are embedded into forecasting, performance management, and decision support and deployed at scale, the scope for manual intervention shrinks. What was previously contained through human oversight is now processed automatically.

Errors that once surfaced as visible anomalies no longer appear as exceptions to be investigated. Instead, they are absorbed into model outputs that appear internally coherent until decisions are made based on them.

Figure 1: Financial Data and Structural Debt

KPMG’s 2026 report captures this shift directly. Organisations that describe themselves as “assurance-ready” report three to six times higher rates of improvement in core finance metrics compared to those that are not. Trust operationalised through governance, controls, and human oversight does not constrain AI. It enables it to scale safely.

AI does not fundamentally change what good governance looks like. It changes the cost of operating without i

Three Practical Moves Before You Scale

1. Make one critical domain genuinely comparable
   Start with a single, high-impact area such as P&L by segment or cash flow by business unit and make it structurally consistent over time. Ensure that reorganisations, chart-of-accounts changes, and historical series are systematically restated. Assign a temporary data product owner with a clear mandate for that domain. The objective is not a perfect data landscape, but one end-to-end domain where models can learn from a coherent and comparable history

2. Build governance and assurance into AI from the outset
   Treat auditability, explainability, and human oversight as design requirements not as after-the-fact compliance. If you cannot trace a clear lineage from source data to model output at reasonable cost, the model is not ready to inform consequential decisions.

3. Shift FP&A capacity from data firefighting to data architecture
   Nearly half of FP&A time is still absorbed by data collection and validation. Continuing to solve that problem manually is a structural dead end. Redirect even a small share of that capacity toward improving the underlying finance data model through common definitions, unified data sources, and documented transformations. This delivers more durable value than adding another reporting or dashboard layer on top of the same fragmented foundation.

A Structural Question, Not a Tool Question

The persistent pattern across these studies points to architecture, not tooling. The relevant question is not technical, but structural:

If a model learned everything your current finance data can teach it today, would you trust the decisions it is empowered to influence?

If the honest answer is “not yet,” then the next investment decision is not primarily about which AI tool to choose. It is about which elements of your finance data architecture, governance, and assurance must change for that answer to become “yes”, not in theory, but in practice.

#FinanceTransformation #AIinFinance #DataQuality #ERP #FP&A #KaldLabs

Best practice in process management is well documented. SAP reference models, APQC’s Process Classification Framework, and industry benchmarks all describe how core processes are expected to operate. The body of guidance is extensive. What receives far less attention is the distance between these models and the conditions in which most organisations actually operate.

Moving from Level 2 to Level 3 process maturity requires standardisation, processes executed consistently against a defined standard. Best practice can provide that reference point.

This article focuses on what happens between defining the standard and achieving consistent execution. It examines why that translation is more difficult than it appears, and what best practice is actually useful for in the process.

The Promise and the Reality

Best practice describes how a process should operate under a set of simplified assumptions: clean data models, a single ERP instance, an organisational structure aligned with the process flow, clearly defined roles, and incentives that reinforce the intended outcomes.

Few large organisations operate under all of these conditions at the same time.

The ERP system was implemented fifteen years ago and has since been customised in ways that were sensible at the time but now act as structural constraints. The chart of accounts reflects a previous organisational model and has not been fully rationalised. Approval workflows were designed for a business model that has since evolved. Multiple acquisitions have introduced legacy systems with different data structures, integrated through middleware that is only partially documented and unevenly understood across the organisation.

In this environment, best practice is not a template to follow. It is a description of a destination that is difficult to reach directly given the accumulated constraints.

This is not a failure. It is the normal condition of large, mature, multi-entity organisations, those that have grown through acquisition, operate across geographies, and carry layers of historical system and process decisions.

The relevant question is not whether the organisation deviates from best practice. It does, and it will. The question is whether those deviations are understood, intentional, and actively managed.

Answering that requires clarity on what best practice actually is, and what it is not.

What Best Practice Actually Is

Understanding best practice starts with a structural property shared by the major frameworks: the broader their applicability, the higher their level of abstraction and the more translation is required before they can be operationalised.

APQC’s Process Classification Framework applies across industries and organisational types because it defines processes at a level that strips away context. SAP’s reference processes specify transaction flows within a standard SAP environment, but the reference model and a heavily customised fifteen-year-old implementation rarely align. Industry benchmarks describe what leading performers achieve, yet the practices that produced those outcomes in one context do not necessarily transfer to another.

APQC makes this scope explicit in its own documentation: the framework does not claim to list every process present in a given organisation, nor that every process it lists exists in every organisation. That is a structural admission, not a caveat, the framework is declaring the boundary of what it can specify before any translation work begins.

In this sense, best practice is typically principled rather than prescriptive. This is particularly true for cross-industry frameworks such as APQC’s PCF, which is explicitly classificatory. Vendor-specific content, such as preconfigured SAP S/4HANA processes, is more prescriptive, but still assumes data models and organisational structures that many implementations do not reflect. In both cases, the framework defines what good looks like end-to-end flow, ownership, measurement, continuous improvement, but does not fully specify how to achieve it within a given organisation. That specification is the work that remains after best practice has been identified.

This is visible in the framework’s own architecture. APQC structures the PCF across five levels: Category, Process Group, Process, Activity, and Task moving from broad classification down to granular steps. The label gets more specific at each level, but the substance does not always follow. At Task level, where the language sounds most operational, “Maintain chart of accounts,” for instance the definition still resolves into an instruction to alter the structure “according to business requirements,” handing the configuration decision straight back to the organisation. Specificity of label is not specificity of guidance.

Consider a common situation in Procure-to-Pay. APQC’s PCF defines the process at a level that applies across industries: requisitioning, sourcing, contracting, ordering, receiving, and payment. SAP’s reference process outlines how these activities should flow in a standard SAP environment. Neither addresses how to design an approval workflow for a business unit with a mandatory four-eyes requirement above a locally defined threshold, a legacy ERP that cannot be upgraded before the next fiscal year, and a procurement function that reports into operations rather than finance. That is the real design problem. Best practice is the starting point, not the answer.

The generality of best practice frameworks is a feature, not a limitation. A framework that prescribed specific solutions would be too narrow to apply broadly. The implication is clear: translating best practice into an operational design requires substantial effort, and that effort is consistently underestimated.

Where the Gap Opens

The gap between best practice and operational reality opens at four points. The pattern is consistent across organisations and process families.

The first is data structure. Best practice assumes a data model in which transactions can be tagged, categorised, and linked to provide end-to-end visibility. In most organisations, however, the data model reflects historical decisions made for other purposes. Cost centres were designed for financial reporting, not for process performance. Supplier master data is fragmented across entities. Customer hierarchies do not reflect how commercial relationships actually operate. Creating process-level visibility therefore requires either restructuring the data model, which is costly and disruptive, or building analytical layers on top, which introduces ongoing complexity.

The second is the system landscape. Best practice assumes a coherent system environment. Most large organisations operate across multiple ERP instances, supported by specialist systems for treasury, HR, and tax. These are connected through integrations built incrementally over time and now difficult to change. Each integration point introduces potential deviation. Each system has its own data model, processing logic, and release cycle. The process does not flow cleanly end-to-end because the systems through which it flows were never designed as an integrated whole.

The third is organisational structure. Best practice assumes that process ownership is structurally feasible that an organisation can assign an owner with end-to-end visibility and the authority to act. In practice, functional structures, reporting lines, and incentive systems are rarely designed for cross-functional accountability. Best practice assumes governance conditions that many organisations have not yet established. This helps explain why process governance often stabilises at Level 3 rather than progressing to Level 4.

The fourth is business model specificity. Best practice is designed for a generic enterprise. Most organisations are not generic. A manufacturing company with engineer-to-order production, a professional services firm billing on time and materials, and a financial institution operating under regulatory constraints all face requirements that standard frameworks do not fully address. The adaptation required is not superficial. It affects the design of the process itself.

A fifth dimension, sometimes treated separately, is organisational culture and informal practice. Unwritten conventions, behavioural norms, and local interpretations shape how processes are executed regardless of what is documented. Culture is harder to map than the other dimensions, but it is equally decisive in determining whether standardisation efforts hold.

The typical response to these gaps is gap analysis. That response needs to be applied with care.

The Gap-Analysis Trap

Gap analysis is the standard method for linking as-is reality to best practice: compare the current process to the standard, identify the gaps, and build a program to address them.

The method is sound. The way it is applied often is not.

The most common issue is treating all gaps as problems to be eliminated. A more useful distinction is between deficiencies and adaptations. The terminology is not fully standardised, but the pattern is well recognised in ERP implementation research. Some gaps are deficiencies, deviations that reduce process effectiveness without a clear business rationale. Others are adaptations, deliberate responses to specific business conditions that best practice does not account for.

A customised approval workflow may diverge from best practice, yet exist because the standard workflow creates a bottleneck the business cannot absorb. A non-standard data structure may complicate reporting, yet reflect a business model that standard templates cannot represent.

Closing these gaps without understanding their origin produces processes that appear closer to best practice but perform worse in practice. The workarounds return because the constraints that created them remain.

Effective gap analysis depends on two disciplines that are often underapplied.

The first is gap classification. Before deciding on action, each gap should be explicitly classified as a deficiency or an adaptation. Deficiencies should be resolved. Adaptations should be understood, documented, and managed as intentional design choices.

The second is root cause analysis before solution design. Most gaps are symptoms of causes that are not visible at the point where they appear. A deviation at the approval step may stem from insufficient data quality upstream. The issue originates earlier in the process in how data is captured or validated. Designing a solution at the point of deviation without addressing upstream causes does not remove the gap, it relocates it.

Figure 1: Gap Analysis Classification Matrix

Gap classification determines the appropriate response to each deviation. Deficiencies should be resolved. Adaptations should be understood and actively managed. Gaps that have not yet been classified should be investigated before any action is taken.

What Best Practice Is Actually Good For

If best practice cannot be applied directly, and gap analysis must be handled with care, what role does it actually play in advancing process maturity?

First, it provides a shared language. Best practice frameworks offer a vocabulary for discussing process design that is not tied to a specific organisation’s history or system landscape. When a process owner and an ERP architect use APQC categories as a reference, they operate within a common frame that makes discussions more precise. Without that shared language, design conversations default to internal terminology, terms that often vary in meaning across functions.

Second, it acts as a diagnostic benchmark. The value of best practice lies less in the gaps it identifies than in the questions those gaps raise. Why does the organisation deviate at this step? Is the reason rooted in business requirements, system constraints, or simply in historical habit? The third explanation appears more often than expected, and best practice helps make it visible.

Third, it serves as a sequencing guide. Best practice clarifies the logical dependencies within a process: what needs to happen before what, and why. This sequencing logic is often the most transferable element, even when specific activities require adaptation. Understanding why goods receipt precedes invoice matching in Procure-to-Pay is more durable than knowing how to configure a three-way match in a particular system.

These three uses are what survives once best practice has been translated rather than applied directly.

Figure 2: What Best Practice Is Actually Good For

What This Means Before Your Next Best Practice Adoption

Before adopting a best practice framework or commissioning a gap analysis against one, three questions can help determine whether the program is likely to produce actionable results.

1. Is the best practice defined at the level of granularity where guidance is actually needed? Principles-level best practice, such as end-to-end flow, ownership models, and measurement approaches, is broadly applicable. Configuration-level best practice, such as workflow design and data structure choices, is context-dependent. Many gap analyses combine the two without distinguishing between them.

2. Does the gap analysis classify gaps as deficiencies or adaptations, or does it treat all gaps as issues to be addressed? An analysis that lists deviations without classifying them describes difference, but does not support design decisions.

3. Is root cause analysis built into the program before solution design begins? Designing solutions to gaps without understanding why they exist leads to changes that are correct in principle but ineffective in practice.

Best practice can appear, from a distance, closer to a theoretical ideal than an operational guide. It is a well-researched description of what effective process design looks like when the constraints of a specific organisation are set aside.

Advancing from Level 2 to Level 3 requires bringing that description into contact with those constraints. This means distinguishing between deficiencies to resolve and adaptations to manage, establishing root causes before designing solutions, and building a standard the organisation can actually operate, not one it only references.

Organisations that do this work gain something no framework can substitute for: a standardised process grounded in operational reality, rather than a description of what that reality is supposed to become.

#BPM #ProcessManagement #BusinessTransformation #ProcessImprovement #OperationalExcellence #ERP #BestPractice #KaldLabs

Many process improvement programs begin with documentation that describes how work is supposed to happen. Far fewer start with evidence of how it actually happens. The gap between the assumed process and the real one is one of the most common, and least acknowledged, barriers to effective process governance.

This article examines what as-is mapping actually requires, why most organizations underinvest in it, and what it enables when done well. It is part of a series on why BPM investments stall at mid-level maturity.

The Gap Between Written and Real

Every organization has process documentation. Flowcharts, RACI matrices, SOP libraries, ERP configuration guides. Most of it was created in conference rooms by people describing how the process should work, or how it worked when the last system was implemented, often several years and several reorganizations ago.

The gap between documented and actual begins at the moment of writing. Process documentation captures intent. It describes what the process is supposed to do and how it was designed to work. What it often fails to capture is how work actually happens today.

Processes accumulate workarounds. Documentation does not. A step that once relied on a system that no longer exists gets replaced by a spreadsheet sent every Friday. An approval that takes too long is quietly bypassed for orders below a threshold. A handoff between procurement and finance that no one clearly owns is handled differently depending on who is available. These adaptations are rational. They solve immediate problems. But they do not make their way back into the documentation. Over time, the gap between what is written and what is done continues to widen.

Process variation across organizational units amplifies the problem. Most large organizations maintain a single documented version of their core processes. In reality, Procure-to-Pay in a Nordic business unit operates differently from Procure-to-Pay in Central Europe. Approval thresholds differ. Supplier onboarding steps differ. Goods receipt practices differ. Each variant has evolved locally to fit specific systems, management preferences, or legacy practices from acquisitions that were never fully integrated. Some of this is documented locally. Very little is consolidated into a shared view. All of it shapes how governance, KPIs, and improvement initiatives actually play out.

Process improvement investments are typically built on this incomplete picture. Organizations start from the official version of the documentation. They design governance structures, appoint process owners, and define KPI frameworks on top of a description that only partially reflects reality. The governance is real. The foundation beneath it is not.

Process owner effectiveness depends directly on the quality of the picture they operate from. A process owner with end-to-end visibility of the documented process sees an assumption, not the actual flow of work, the real handoffs, or the points where performance breaks down. The data needed to act often exists in underlying systems. What is missing is the correct frame for interpreting it.

Effective governance at any maturity level depends on an accurate as-is baseline. Without it, governance investments may be structurally sound but operationally misaligned. Level 3 governance built on a Level 1 understanding of reality will behave closer to Level 1 than to Level 3. Not because the governance model is flawed, but because it is applied to an incomplete representation of the process.

What As-Is Mapping Actually Is

That complete picture is what as-is mapping is designed to produce. It is the discipline of documenting how work actually happens, not how it is supposed to happen, not how systems are configured to support it, but how people in the organization execute the process today.

It sounds straightforward. It is not.

The quality of as-is mapping varies significantly, and most organizations produce a version that is insufficient as a foundation for improvement. The most common outcome is a recreation of existing documentation, where participants describe the process as they believe it should work. The second is a cleaned-up version of reality, a map that captures formal steps while omitting the workarounds, exceptions, and informal fixes that shape most transactions.

Neither provides a reliable foundation for improvement. Both reproduce the same incomplete picture.

Effective as-is mapping requires three elements that most organizations underinvest in.

First, observation and data before interviews. Pull transaction data before any mapping session. How many purchase orders have a corresponding requisition? How many invoices require manual intervention? What is the average end-to-end cycle time? Then observe how work is done, or analyze the data trail left by transactions through process mining. The data shows where to look. Interviews explain why. Without this grounding, people describe the process they believe they follow, not the one actually in operation.

Second, exception mapping alongside the main flow. In most processes, exceptions are not marginal. They represent a meaningful share of volume. In Procure-to-Pay, orders without requisitions are not rare; in some organizations they account for a significant share of spend. In Order-to-Cash, manual credit overrides, split invoicing, and early delivery confirmations are common. A process map that captures only the happy path reflects a minority of transactions.

Third, variant mapping across organizational units. A single process map captures one version of the process. In reality, the same process is executed differently across business units, geographies, or legal entities, each with distinct approval thresholds, system configurations, workarounds, and informal practices. These variants are not random. They reflect legacy structures, acquisitions, and local system choices. Mapping them is essential. A standardization effort that ignores existing variants will face resistance it cannot explain and deliver compliance it cannot sustain. Variants are not deviations to control. They are the reality that must be understood before it can be standardized.

The patterns below illustrate what this looks like in practice.

Figure 1: The As-Is Gap: Procure-to-Pay

The as-is gap illustrated in P2P — the same pattern of workarounds and variants appears in O2C, R2R, and most other end-to-end processes.

The Gap in Practice: Two Familiar Patterns

Consider what as-is mapping typically reveals in Procure-to-Pay, and how far the actual process diverges from the documented version.

The documented process is straightforward. Need identified. Purchase requisition created. Purchasing reviews and approves. Purchase order issued. Goods received. Invoice matched. Payment made. Clean, sequential, auditable.

The actual process, in many organizations, diverges at almost every step. Needs are identified, but requisitions are created after the fact, if at all, because operational pressure requires ordering before the approval cycle completes. Purchasing reviews activity, but often retrospectively. Purchase orders are issued, but frequently after a verbal commitment has already been made. Goods receipt is confirmed, sometimes before physical delivery, to keep invoice processing moving. Invoice matching fails more often than the documented flow assumes, requiring manual intervention that is absent from the process map.

These workarounds are not random. Each exists because the formal process introduces a bottleneck that operations cannot absorb. Requisition requirements slow ordering. Approval cycles do not match operational timelines. Goods receipt confirmation is tied to system requirements that lag physical reality. Each workaround is locally rational. Together, they produce a process that appears controlled on paper but is not controlled in practice.

The problem is further compounded by variation. Workarounds are not applied consistently. One business unit develops one set of adaptations. Another develops a different set. When a process owner is assigned to govern Procure-to-Pay at organizational level, they are not managing a single process with deviations. They are managing multiple distinct variants that share a name and a high-level map but differ materially in execution.

Standardization, the transition to a genuine Level 3, depends on making those variants visible. Many as-is mapping efforts do not.

Order-to-Cash follows the same structural pattern, with different points of divergence. Credit limit policies are interpreted differently across commercial teams. Revenue recognition timing varies between entities. Collection escalation procedures that are standardized centrally are adapted locally to preserve customer relationships. Each variant is defensible in isolation. Together, they prevent meaningful comparison of performance across units and make it difficult to identify which variant produces the best outcomes.

Record-to-Report is structurally the most complex of the three, and the one where variation is least visible from the center.

Figure 2: The As-Is Gap: Record-to-Report

The as-is gap in R2R — with an additional variant dimension that reflects differences in entity size, system maturity, and accounting policy interpretation across business units.

The documented process is straightforward. Transactions posted. Period-end close activities performed. Consolidation completed. Financial statements prepared, reviewed, and approved. Disclosed. Each step has an owner, a timeline, and a supporting system.

The actual process tells a different story. Journal entries are posted after the nominal close. Manual adjustments appear at consolidation, often for issues that should have been resolved at entity level. Restatements surface during audit preparation and require reopening periods that were already reported as closed.

Close cycle time is tracked as a single aggregated metric. The distribution of effort within that cycle is rarely visible. Which entities consistently run late? Which account types generate the highest volume of manual adjustments? At what point in the process does data quality break down?

In many organizations, these questions cannot be answered at group level. The data exists in the ERP, but it is not analyzed as a process flow. It is reviewed as a set of accounting outcomes.

The variation dimension is particularly pronounced in Record-to-Report. In multi-entity organizations, each business unit operates with its own close calendar, account structure conventions, and judgment on accruals and provisions. Group accounting policies are interpreted locally. Group finance sees the consolidated result. It rarely sees the process variation that produced it.

When close quality deteriorates, the symptoms are visible in late submissions, restatements, and audit findings. The root cause is not. Identifying it requires as-is mapping at the entity level, with enough detail to expose where and how the process diverges.

That diagnostic capability is what determines whether an organization can move beyond its current maturity level.

Why This Matters for Maturity

Most organizations meet the documentation requirement associated with Level 2. Fewer achieve consistency in execution. The documentation describes the intended process, not the actual one. Repeatability requires more than a process map. It requires that the map reflects how work is truly performed.

Documentation that describes intent creates governance that is formally correct but operationally misaligned. When used as the basis for training and system configuration, it embeds assumptions rather than reality. People follow the workarounds because they are effective. The formal process is not.

This creates a specific trap at Level 3. An organization can establish the visible elements of Level 3, process owners, documented processes, a center of excellence, a BPM framework, while the underlying transactional reality remains closer to Level 1. The governance structures are in place. The foundation they rely on only partially reflects how the process actually runs.

Moving from Level 2 to Level 3 requires more than documentation. It requires standardization, with processes executed consistently, in the documented way, across the organization. Standardizing an incorrect as-is baseline produces a consistent description, not a consistent process. The workarounds remain. They are simply no longer visible in the official version.

Genuine as-is mapping removes this barrier. It makes the gap between documented and actual visible and creates the foundation for every subsequent step in process improvement. Gap analysis against best practice, process hierarchy design, automation sequencing, and interpretation of process mining all depend on an accurate picture of what is happening in practice.

An accurate as-is baseline is a primary enabler of effective governance. It is also one of the most commonly skipped steps. Organizations that invest in it gain something that no governance framework, process owner appointment, or KPI redesign can replace: a shared, evidence-based understanding of the process they are actually trying to improve.

What This Means Before Your Next Transformation Investment

Before launching any process improvement initiative, whether a new governance structure, system implementation, best practice adoption, or automation program, a more fundamental question comes first.

Are you working from an accurate picture of how work actually happens today?

Three questions determine this:

1. Was the current process documentation produced through observation and transaction data analysis, or through workshop reconstruction?

2. Does the documentation explicitly map exceptions and workarounds alongside the main flow, or does it show only the intended happy path?

3. Does the organization have transaction-level data that quantifies the gap between documented and actual execution, such as the percentage of orders with purchase requisitions, first-time-right rates, and the frequency of manual overrides?

If the answer to any of these is no, the as-is baseline is incomplete. Governance investments built on an incomplete baseline will improve the description, not the process. The limitation is not the governance design. It is the picture it is built on.

#BPM #ProcessManagement #BusinessTransformation #ProcessImprovement #OperationalExcellence #ProcessMining #P2P #R2R #KaldLabs

Most organizations that have invested in process improvement recognize these four names: Procure-to-Pay, Order-to-Cash, Record-to-Report, and Hire-to-Retire. They appear in ERP implementations, shared services design, and process maturity assessments across industries and geographies.

What remains less understood is why all four resist meaningful improvement, not marginal optimisation but structural change, consistently across organisations and sectors.

This article maps these four process families, examines what makes each structurally distinct, and highlights the governance pattern they share. It is the second in a series on why BPM investments tend to plateau at mid-level maturity.

Two Problems You Have Seen Before

Consider a familiar sales problem. A customer complains about a late delivery and a missing invoice. Sales confirms the order was placed correctly. Production confirms it was manufactured on time. Logistics confirms the shipment went as planned. Finance confirms the invoice was issued according to procedure.

In most organizations, no one owns the problem as a whole. Each function has performed correctly within its own perimeter. No one has visibility of the full timeline, from order confirmation to payment, that would reveal where the cycle actually broke down.

The incentive misalignment surfaces next. The customer delays payment. Finance applies a late fee according to policy. Sales pushes back. This is a strategic account, and the fee risks the relationship. Finance responds that days sales outstanding is already above target and that payment terms must be enforced. The issue escalates.

What remains unspoken is this. Sales already hit its target. The invoice was issued, revenue was booked, and the bonus secured. Whether cash actually arrives, and when, is someone else’s problem.

This is not cynicism. It is rational behavior. Sales measures what it controls. The invoice was sent, the order was correct, the revenue recognized. Payment depends on credit terms and collection activities owned elsewhere. The issue is not the metric. The issue is that no one owns the end-to-end metric.

This is not a sales problem. Nor is it a finance problem. It is an Order-to-Cash problem. No one owns Order-to-Cash.

The KPI structure makes the conflict inevitable. Sales is measured on invoiced revenue. The target is achieved the moment the invoice goes out. Logistics is measured on OTIF, on time and in full, which ends when goods leave the warehouse. Finance is measured on DSO, which only begins once the invoice is issued. Three functions. Three clocks. None aligned.

In most cases, no one is measured on whether cash actually arrives or how long the full cycle takes.

A process-oriented KPI would make the failure visible. Order-to-cash cycle time, or the share of orders fulfilled, invoiced, and collected without exception. No single function can own such a metric. A process owner can. In most organizations, there is none.

Now consider a familiar procurement problem. Purchasing negotiates framework agreements to lower prices, yet total procurement cost does not fall. Purchasing blames Finance. Too many invoices fall outside agreements. Finance blames Production. Orders are placed without requisitions. Production blames Purchasing. The agreements do not cover what is actually needed.

Maverick spend persists because no one measures Procure-to-Pay as an integrated flow. Requisitions are bypassed because no one owns the process required to enforce them. When the issue surfaces in a budget review, it appears to be a discipline problem. It is not.

Again, the KPI structure drives the outcome, and in some cases rewards the wrong behavior. Purchasing is measured on price variance, which registers nothing when contracts are bypassed. Production is measured on supplier delivery reliability, creating pressure to order through the fastest available channel. Agreements become optional. Finance is measured on cost per invoice processed. This is a legitimate efficiency metric that is, paradoxically, improved by maverick spend. Fewer purchase orders create simpler processing flows.

Finance is not optimizing incorrectly. The metric is well designed for what Finance controls. The problem lies in what all three functions optimize simultaneously. Each KPI is locally rational. Together, they produce a system that rewards bypassing the process.

A process-level KPI would expose the gap immediately. Maverick spend rate, or the percentage of orders initiated with a purchase requisition. That metric belongs to a process owner. In most organizations, there is none.

These are not edge cases. They are the default state in organizations with strong functional structures but weak process ownership, where no one has the authority, visibility, or accountability for end-to-end outcomes.

Understanding why requires a precise definition of what a process family actually is.

What a Process Family Is and Isn’t

A process family is not a department or a function. It is an end-to-end flow of work that crosses multiple functional boundaries, beginning with a trigger and ending with an outcome.

Large organizations are typically structured around a small number of core functions such as Sales, Production or Service Delivery, Logistics, Procurement, Finance, and HR. Each is optimized for within-function performance, with its own KPIs and reporting lines.

Process families cut across all of these. In day-to-day operations, a process does not operate as an integrated whole. It runs as a sequence of handoffs between units that optimize locally.

This is exactly why the problems described earlier persist. It also explains why each process family behaves in distinct ways once you look at its structure rather than its functions.

Figure 1: The Four Process Families

The Four Families

Each process family shares a structural property: it spans the functional configurations large organizations actually use in a way that makes integrated accountability predictably fragile.

Procure-to-Pay covers the full cycle from need identification through supplier selection, purchase order creation, goods receipt, and payment. It typically involves five to eight contributing units. The accountability gap is predictable. Procurement targets price variance. Finance targets processing cost. Operations targets delivery compliance. These are separate metrics applied to a single integrated process, and no one is accountable for the whole. The underlying issue is the same as in the O2C case. No one has a process-level view.

Order-to-Cash connects a customer order to cash receipt, passing through order management, fulfillment, logistics, billing, and collections. Sales is measured on order intake. Logistics on delivery performance. Finance on days sales outstanding. Separate targets. Separate reporting lines. One process. Order-to-delivery cycle time, the metric that would reveal end-to-end performance, is often not tracked or managed across functions.

Record-to-Report is the most structurally complex of the four. It integrates transactional accounting from every business unit with group-level consolidation, reporting, and external disclosure. The number of contributing units can reach twenty or more. The accountability gap here is inverted. Business units own the transactions but have no stake in reporting outcomes. Group finance owns the reporting but does not control the transactions. In many large organizations, no single actor is accountable for the data quality that determines whether financial statements can be trusted. Close cycle time, the clearest end-to-end metric, is rarely managed as an integrated process outcome.

Hire-to-Retire spans the full employee lifecycle, from workforce planning and talent acquisition through payroll, development, and offboarding. HR sub-functions hold separate metrics such as time-to-hire, payroll accuracy, and training completion rates. Line managers are accountable for headcount outcomes but not for the HR process performance that underpins them. End-to-end workforce lifecycle cost is often not visible to any single actor.

These four families appear in virtually every large organization, regardless of industry. Other process families follow the same structural logic. The names change. The pattern does not.

Issue-to-Resolution spans customer service, technical support, and back-office operations. Customer service is typically measured on first-contact resolution. Technical support on ticket closure time. Back-office on SLA compliance. Separate clocks for one customer experience.

Bid-to-Bill, common in project-based organizations, runs from commercial proposal to final invoice. Sales owns the margin at bid. Delivery owns the cost at execution. Finance owns the invoicing. No one owns the gap between bid margin and realized margin.

The Pattern They Share

What stands out is not the differences between these process families, but how similar they are. In each case, the contributing units are known. The accountability gaps are known. The missing metrics are known. Yet the gaps persist, year after year, across organizations that have invested seriously in process improvement.

These organizations are not unaware of the problem. They are unable to resolve it with the tools they currently use. APQC has tracked “defining and mapping end-to-end processes” as the top process management priority for several consecutive years, cited by around 40 percent of organizations in its 2025 survey (APQC, 2025). The priority remains. The outcome does not change.

This points to something structural. These process families are not difficult to improve because of insufficient effort, weak methodology, or lack of executive attention. They are difficult because each cuts across the coordination logic of the organization.

Each function is optimized for its own performance. The process depends on shared accountability across functions. The tension between the two is built into the design.

What Advancing Beyond Level 3 Would Change

Both cases share the same underlying condition. Functional KPIs are present and working. Process-level accountability is absent. This defines Level 3 and is exactly what Level 4 requires an organization to resolve.

At Level 3, the O2C scenario unfolds as described. The issue escalates into a management discussion that should never have been necessary. The process owner appears on the organization chart but lacks a consolidated view of order-to-cash cycle time, has no authority to realign incentives across Sales and Finance, and carries no direct accountability for whether cash arrives on time. The role exists. The governance does not.

At Level 4, the same situation plays out differently. The process owner has access to integrated performance data: order-to-cash cycle time, first-time-right rate, and percentage collected within terms, across all contributing functions, updated at least monthly. When DSO deteriorates, the root cause is visible. It can be traced to credit decisions, billing errors, or breakdowns between logistics and invoicing. The process owner can convene the relevant functions and require action without escalating to the CFO. Because the role is evaluated on end-to-end outcomes, the incentive to act is built into the structure.

For Sales, one practical change stands out. Late payment disputes no longer land with the sales team. When a strategic customer delays payment, the process owner is responsible for investigation and resolution. Sales retains its invoicing metric. What changes is that someone else now owns the end-to-end result, with the authority and visibility to act. The conflict remains, but it is handled at the right level.

In Procure-to-Pay at Level 3, maverick spend remains largely invisible because the process is not measured as a whole. Purchase requisitions are bypassed because the process owner lacks authority over ordering behavior in Production. At Level 4, maverick spend becomes a visible metric with clear ownership. The process owner has both the data to detect it and the mandate to address it, including the ability to work with Finance to adjust the cost-per-invoice KPI that currently encourages bypassing the process.

In Record-to-Report, the most structurally complex case, Level 3 means close cycle time is not managed end-to-end. It reflects whatever each business unit delivers, while group finance lacks the authority to enforce consistent data quality. At Level 4, the process owner tracks a first-time-right rate at entity level, the share of submissions requiring no restatement. This exposes data quality issues early and creates a basis for structured engagement with business unit CFOs, rather than relying on periodic escalation.

Moving from Level 3 to Level 4 does not require a new methodology or a new governance model. It requires making the existing process owner role operational. That means end-to-end visibility, cross-functional authority, and incentives tied to process outcomes.

Without all three, the KPI conflicts described earlier are not management failures waiting to be resolved. They are structural features of the organization, as predictable as the processes themselves.

What This Means Before Your Next Process Investment

Before investing further in any of these process families, whether in a new governance structure, a new system, or a redesigned operating model, a more basic question needs to be answered. Do the structural conditions for cross-functional accountability actually exist?

If you have read the first article in this series, these three questions will be familiar. They are repeated here deliberately. They apply to every process family described above, and the answer is often different in each case.

An organization may have the conditions in place for Procure-to-Pay, but not for Record-to-Report. The diagnosis is not organizational. It is process-specific.

Three questions determine this:

1. Does the process owner have integrated performance data spanning all contributing units, not just functional reports, but a consolidated end-to-end view?

2. Does the process owner have the authority to approve improvements that require changes across multiple functions, without separate sign-off from each function head?

3. Does the process owner’s performance evaluation include at least one end-to-end process KPI with meaningful weight?

If the answer to any of these is no for a given process family, the structural conditions for effective governance are not in place. Additional investment will create more infrastructure. It will not create more maturity.

#BPM #ProcessManagement #OperationalExcellence #ProcessImprovement #BusinessTransformation #P2P #O2C #R2R #H2R #KaldLabs

Most organizations that invest seriously in business process management reach a documented, repeatable level of performance and then stop advancing. Many BPM programs are “mature on paper” but stuck in practice. This article maps the five BPM maturity levels, explains why Level 3 is where the majority stall despite continued investment, and gives you three questions to diagnose whether your process governance is structurally functional — or just formally in place.

If your process owners have the title but not the authority, this article is about you.

The Data

Recent BPM studies suggest that only a minority of organizations progress beyond early-to-mid BPM maturity, and that overall distributions have changed little between 2023 and 2025. The 2025 BPM study by ZHAW School of Management and Law and BOC Group, covering almost 300 organizations in the DACH region, finds that most organizations continue to operate at lower to mid levels of BPM maturity, with only around 15% reaching higher maturity levels.

APQC’s BPM maturity benchmarks and assessment tools similarly show that many organizations remain in the lower half of maturity scales, despite having formal BPM structures in place, and report ongoing challenges in moving to more advanced levels of process governance. “Moving to process-based thinking” and embedding process management into the organizational culture recur as high-ranked challenges.

In other words: two or more years of active BPM investment often result in limited or no measurable movement in overall maturity distributions.

If methodology were the primary constraint, we would expect sustained use of established BPM frameworks to gradually translate into higher maturity scores; yet large-sample surveys show persistent clustering in early-to-mid levels. The studies cited above focus on organizations that actively invest in BPM, use formal frameworks, and participate in structured assessments, so the stagnation is not simply a sponsorship problem.

The implication is that something structural in how governance is designed and operated is constraining advancement.

The Five Levels: What Each One Actually Requires

All dominant BPM maturity frameworks — including OMG’s Business Process Maturity Model (BPMM), Rosemann and de Bruin’s BPMM, and other CMMI-inspired models — share a broadly similar five-level architecture, even if terminology differs. Hammer’s Process and Enterprise Maturity Model (PEMM) is structured somewhat differently, with an emphasis on capability dimensions, but is frequently interpreted in practice as defining staged maturity progression.

Figure 1: The Five Levels of BPM Maturity

Across these models, the underlying logic is consistent: lower levels describe ad-hoc and functionally siloed practices; mid-levels describe standardized, documented, and repeatable processes; higher levels describe managed, quantitatively controlled, and continuously optimized processes. Understanding what each level structurally requires, rather than just how it is labeled in an assessment report, is essential for understanding why advancement so often stalls at Level 3.

The maturity models are detailed in describing where organizations are — they provide taxonomies, levels, and assessment criteria with considerable sophistication — but systematic reviews have repeatedly observed that they provide much weaker explanations for why organizations stall at specific levels or how to overcome structural barriers. Röglinger and colleagues, as well as Tarhan, Turetken, and Reijers, note that empirical evidence on the validity and usefulness of BPM maturity models is limited and that prescriptive guidance for progressing between levels remains underdeveloped.

Existence vs. Operationality

The progression from Level 1 to Level 3 is largely about governance infrastructure: creating documentation, defining process architectures, assigning roles, and establishing a process management function. Many organizations can reach this stage through sustained BPM investment, implementation of frameworks such as APQC’s BPM Maturity Assessment, and deployment of centers of excellence.

The progression from Level 3 to Level 4 requires something different: that the governance infrastructure actually functions as intended — that process ownership and cross-functional control mechanisms are operational, not just defined on paper. A process owner who lacks end-to-end visibility, cross-functional decision rights, and incentives aligned with process outcomes is an infrastructure element, not an operative governance mechanism; the role exists, but the governance does not.

Consider Record-to-Report. In many groups, central finance has full visibility of the consolidated picture but lacks authority to mandate changes in business unit closing procedures; business unit CFOs have authority within their silo but lack end-to-end visibility across entities. No single actor holds both visibility and authority, yet a formal “process owner” may still be appointed. In such a design, very little changes in practice; this is not a failure of individual managers so much as a structural misalignment.

Similar patterns appear in Procure-to-Pay, where procurement is measured on price variance, finance on processing cost, and operations on delivery reliability — three separate metrics for one integrated process, with no single owner accountable for end-to-end performance. And in Order-to-Cash, improving days-sales-outstanding almost always requires coordinated behavior changes across functions measured on incompatible KPIs.

Systematic reviews of BPM maturity models confirm that most frameworks concentrate on describing the presence of governance elements — structures, roles, and practices — rather than on assessing whether these elements have the visibility, authority, and incentive alignment needed to function effectively. Existing models are predominantly descriptive and lack robust, empirically validated mechanisms linking specific governance configurations to performance improvements.

The critical distinction most maturity models currently do not systematically assess is therefore not which governance structures are present, but whether those structures are operationally capable of delivering cross-functional control.

What Standard Assessments Don’t Measure

Standard BPM maturity assessments, including those used in industry surveys, primarily measure the horizontal dimension of governance infrastructure: the existence and quality of documentation, formal ownership roles, frameworks, and defined process architectures. These assessments answer questions such as: “Is there a documented process map?” “Is a process owner formally assigned?” “Is there a BPM governance framework?”

What they typically do not measure is the vertical dimension of governance operationality: whether the assigned owner has integrated visibility across all contributing functions, cross-functional investment or change authority, and performance incentives that are materially linked to end-to-end process outcomes.

You can visualize this difference as a nine-box grid.

Figure 2: Process Governance Diagnostic Matrix

Horizontal axis — Governance Infrastructure: quality and completeness of , formal roles, and frameworks.

Vertical axis — Governance Operationality: degree to which the process owner has end-to-end performance insight, authority crossing functional lines, and incentive alignment with process KPIs.

Most large organizations with established BPM programs appear to cluster in the bottom-right cell of this grid: strong governance infrastructure combined with weak governance operationality. Public summaries from BPM studies and benchmarking collections show a prevalence of formal process structures and architectures, but continued challenges around practical end-to-end ownership and cross-functional decision-making.

In this “stagnation zone,” additional investment produces more infrastructure — better documentation, more defined roles, improved frameworks — but not more maturity in the sense of operational, cross-functional control. The governance looks correct on the org chart, while underlying authority, information flows, and incentives remain misaligned. Because standard assessments primarily measure the horizontal axis, organizations systematically underdiagnose these constraints and misallocate remediation effort.

Evidence on End-to-End Ownership

Global surveys of shared services and business services functions have for several years reported unresolved questions around end-to-end process ownership and accountability design. In Deloitte’s analyses of global business services trends, issues of cross-functional ownership, fragmented responsibilities, and unclear accountability appear consistently among the most frequently cited design challenges in service delivery models.

Similarly, work by consulting firms and academic studies on operating models regularly points to fragmented ownership as a structural barrier that precedes and amplifies other barriers such as technology limitations, local resistance, and change fatigue. Before organizations can address methodological or tooling issues, they often face unresolved questions about who actually owns end-to-end processes and with what authority.

Other reports on operating models and performance structures indicate that only a minority of organizations operate with truly horizontal performance structures that align measurement and accountability with end-to-end processes rather than functions. Horizontal structures are the exception, not the rule; most organizations continue to manage performance primarily through functional lines.

Taken together, these findings support the thesis that the appointment of process owners is common, but that these appointments often do not create the operational authority structures originally envisioned.

Three Diagnostic Questions

Before committing further BPM investment to any major end-to-end process, you can test whether governance for that process is structurally functional by asking three questions.

1. Does the process owner receive integrated performance data spanning all contributing functions — at least monthly?

Without a consolidated, end-to-end view of cycle time, error rates, and cost across functions, the owner cannot see what they are supposed to manage. Many maturity assessments verify that metrics exist, but not whether they are integrated across functions and regularly available at process-owner level.

2. Can the process owner authorize an improvement requiring changes in more than one function, without each function head’s separate approval?

If every cross-functional initiative requires individual sign-off from each affected silo, the process owner is a coordinator, not an owner. Studies of operating models and BPM governance repeatedly highlight fragmented authority and siloed decision rights as primary obstacles to realizing process-oriented changes.

3. Does the process owner’s formal performance evaluation include at least one end-to-end process KPI with meaningful weight?

Without a KPI that links the role’s evaluation to outcomes such as end-to-end cycle time or total cost per transaction, the incentive link is severed. Kerr’s classic 1975 paper, “On the Folly of Rewarding A, While Hoping for B,” describes precisely this problem: organizations reward functional performance (A) while hoping for cross-functional outcomes (B), and effort naturally follows the rewarded dimension. Where instrumentality is absent, process-level effort will not be sustained — regardless of job title.

If the answer to any of these questions is “no” for a given process, the role is formally assigned but structurally unsupported. In such a case, the organization has created a governance artifact, not a governance mechanism.

Importantly, this diagnosis is process-specific, not organization-wide. An organization can govern Procure-to-Pay effectively — with integrated data, cross-functional authority, and aligned incentives — while Record-to-Report remains structurally fragmented and high-risk. The three questions above are designed to surface that distinction for each process individually.

The Question Worth Asking Before Your Next BPM Investment

Most readers in large organizations will recognize the bottom-right cell of the nine-box grid: robust governance infrastructure combined with weak governance operationality. Many organizations with formal BPM programs are precisely in this situation.

The more precise and practical question is: does your process owner have all three of the conditions above — integrated data, cross-functional authority, and incentive alignment — or primarily the job title?

If the answer is “mostly the job title,” then the investment decision in front of you is not whether to appoint a more capable owner or implement an even more sophisticated governance framework. It is whether the structural preconditions for ownership to function are in place. Measurement infrastructure comes first; authority structures second; incentive alignment third. Improvements in descriptive frameworks and documentation alone have limited impact without corresponding changes in these structural dimensions.

Governance investments made in the wrong sequence will tend to produce more of what many organizations already have: well-designed roles and frameworks that cannot perform as designed because they are not supported by data, authority, and incentives at the right level.

BPM stagnation at Level 3, in this light, is less a management or methodology failure than an architectural one. Architectural problems require architectural solutions — redesigned ownership structures, aligned performance architectures, and integrated information flows — not simply more of the same investment applied with greater resolve.

Which of your core processes would fail at least one of these three conditions today?

#BPM #ProcessManagement #OperationalExcellence #ProcessOwnership #BusinessTransformation #KaldLabs

As organisations grow and diversify, shared services must do more than process transactions, they must provide clarity, consistency, and confidence. This article outlines how we developed an operating model for Accounting & Control that supports five business areas and over 150 legal entities. Rather than a one-off transformation, the model emerged by connecting strategic initiatives, finance harmonisation, process orientation, and digital workflows with local operational improvements. The result is a coherent structure with clear roles, governance, and scope. The model enables cross-functional collaboration, strengthens business partnership, and supports strategic finance capabilities making it scalable, resilient, and built to evolve.

Clarity Is the Operating System

In shared services, structure is not just a framework — it is what keeps complexity from becoming chaos. Without clarity, even skilled teams struggle to deliver at scale.

Our operating model for Accounting & Control did not come from a single transformation. It evolved through practical necessity shaped by strategy, local improvements, and the cumulative impact of decisions made by those closest to the work. Over time, we saw that what held it all together was not a new system or process, but a shared understanding of scope, roles, ownership, and governance.

Documenting the model turned that understanding into something visible and durable.

Connecting Strategy with Operational Reality

Several strategic directions helped shape the model. Finance harmonisation established a mandate to reduce variation and centralise recurring tasks. In parallel, process-oriented ways of working gave new definition to ownership and handoffs. And our digital service portal, built in ServiceNow, brought structure to how services were requested, tracked, and improved.

These shifts did not all come from the centre. Many were led by teams responding to concrete challenges, reporting gaps, bottlenecks, or unclear responsibilities. The breakthrough came not from launching yet another initiative, but from aligning what was already working. By defining the model, we created a framework that supports consistency without dampening initiative.

Scope, Structure, and Role Clarity

The model governs the Record-to-Report (R2R) process — from subledger close to the handover of validated data for group consolidation. It explicitly excludes consolidation itself and system ownership. These boundaries keep accountability intact.

Within this scope, five roles form the backbone of delivery:

- Controllers ensure accuracy, integrity, and alignment with business understanding.

- Accountants execute standardised, recurring tasks across entities, enabling scale and efficiency.

- Subject Matter Experts (SMEs) secure quality and lead process improvement.

- Reporting Responsibles (RRs) coordinate the reporting flow and link financial output with business context.

- Shared Service Representatives (SSRs) drive governance, manage collaboration, and own escalation pathways.

These roles overlap by design. Controllers may serve as RRs; Accountants may be SMEs. This overlap enables flexibility and supports development, allowing teams to scale work without duplicating structure.

Governance That Solves, Not Slows

Governance routines translate structure into action. Monthly meetings bring together SMEs, RRs, SSRs, and team managers. Their purpose is not just control, but resolution: surfacing issues early, tracking improvements, and preparing for change.

Escalation paths are simple and visible. Delivery issues move from RR to Team Manager to Department Head. Process concerns move from SME to SSR to Process Owner — and, when needed, to the Financial Management Team for cross-functional intervention.

Metrics turn governance into learning. Close cycle time, reconciliation coverage, reporting accuracy, and stakeholder feedback are reviewed routinely. Case data from ServiceNow provides traceability and trend visibility. Capability-maturity assessments help identify where automation or further standardisation is needed. Most importantly, governance ensures that decisions are made and followed through.

Harmonisation That Enables Judgement

Harmonisation reduces noise so judgement can travel. Finance harmonisation was never about one-size-fits-all; it was about removing unnecessary variation. With fewer local deviations, it became possible to compare, analyse, and act with confidence. Teams could focus on insight rather than reconciliation.

Alignment, not enforcement, made harmonisation stick. Clear scope, mutual trust, and shared targets created the conditions for convergence. Harmonisation worked because the model respected both central structure and local accountability.

A Model That Develops People

Role clarity turns the operating model into a development system. Because roles are transparent and responsibilities structured, individuals can grow across functions — becoming RRs, SMEs, or stepping into governance roles.

This structure makes people decisions more deliberate. Resource planning, succession management, and coaching can be based on visible roles and capabilities. Managers can shift attention from firefighting to capability-building. Teams become less dependent on individual heroes and more resilient as a whole.

Over time, the model has helped us become not just scalable, but sustainable.

Strategic Finance in Action

Strategic finance emerges when operational clarity frees capacity. With the operating model in place, teams can deliver more than compliance. Controllers participate in business reviews and support planning. Reporting Responsibles ensure numbers are not just accurate, but meaningful. SMEs anchor quality while enabling process change.

The RR role, in particular, moves the centre of gravity closer to the business. Positioned between business units and shared services, RRs translate business needs into finance language and finance insights back into business discussions. Strategic finance becomes a capability embedded in how we work, report, and connect, rather than a separate staff function.

Durable Clarity in a Changing Environment

Durable clarity makes change manageable. Our operating model continues to evolve — and it has to. ERP landscapes shift, reporting demands grow, and the business environment becomes more complex. Because the structure is anchored in purpose and shared logic, these changes are absorbable rather than disruptive.

Shared services succeed when they enable others to succeed. For us, that has meant investing in clarity: in ownership, in roles, in routines. Clarity is what makes performance repeatable and improvement possible.

If you are navigating similar complexity or designing a model of your own, I would be glad to exchange perspectives.

The Accounting & Control function described here supports five business areas with more than €5 billion in turnover and covers financial reporting for over 150 legal entities. The operating model described was implementation-ready in June 2025.

A version of this article was originally published as a LinkedIn article in June 2025.