Finance Transformation
Clarity Is the Precondition
Most shared service transformations are sold as system projects or process projects. After running Accounting & Control across five business areas, 150 legal entities, and EUR 5B in turnover — I think that is the wrong diagnosis. The systems worked. The processes existed. What was missing was legibility: shared understanding of scope, roles, and what happens when something fails. This is an account of what changed when we made the model visible, and why clarity turned out to be the active ingredient — not the software, not the methodology.
---
The problem was that skilled people, working hard, could not always explain who was responsible for a given outcome — or escalate effectively when something failed. Not because the organisation lacked talent. Because it lacked clarity.
That gap does not show up in project plans. It shows up at period close.
What we tried first
The instinct was to fix the process. Then to fix the system. Finance harmonisation established a mandate to reduce local variation. A digital service portal brought structure to how requests were logged and tracked. Process-oriented working methods redefined ownership and handoffs.
Each of these helped. None of them solved it.
The issue was not that processes were undefined. It was that the same process meant different things to different teams. Controllers, accountants, subject matter experts, and reporting responsibles each operated from a partial view of the model. The model existed — it just was not legible.
Documenting it did not create clarity. It revealed how much was already there, and made it accessible to everyone at once.
What changed when it became visible
The model governs Record-to-Report — from subledger close to handover of validated data for group consolidation. Consolidation itself and system ownership sit outside the boundary, by design. That boundary sounds administrative. It is not. It is what keeps accountability intact when something goes wrong at period close and four functions are trying to establish who owns the problem.
Five roles carry the delivery. Controllers own accuracy and business alignment. Accountants execute standardised recurring tasks. Subject Matter Experts lead process improvement. Reporting Responsibles connect financial output to business context. Shared Service Representatives own governance and escalation.
The roles overlap intentionally. A Controller may serve as Reporting Responsible. An Accountant may be a Subject Matter Expert. This is not ambiguity — it is flexibility with defined constraints. The difference matters. Ambiguity means no one knows who acts. Flexibility means the right person can act, because the boundaries are clear enough to stretch without breaking.
Before the model was documented, overlap looked like a gap. Afterwards, it became a feature.
Governance as proof
The governance routines — monthly, with SMEs, Reporting Responsibles, SSRs, and team managers — did not change in format when the model became explicit. What changed was what happened in the room. Issues surfaced earlier. Escalation paths were used because people knew they existed. Decisions were made rather than deferred.
Escalation is now explicit: delivery issues move from Reporting Responsible to Team Manager to Department Head. Process concerns go from SME to SSR to Process Owner. This is not bureaucracy. It is the difference between an issue that resolves in one cycle and one that recurs for six months because no one was certain who should act.
The metrics — close cycle time, reconciliation coverage, reporting accuracy — did not improve because the governance routine existed. They improved because the routine could now produce decisions. Governance without clarity produces meetings. Governance with clarity produces resolution.
The case for building clarity first
Finance harmonisation reduced noise, which mattered. The service portal created traceability, which mattered. The ERP infrastructure made scale possible, which mattered.
But none of them made improvement systematic. Improvement became systematic when teams could see the model clearly enough to identify what was wrong with it. You cannot improve what you cannot describe. You cannot escalate through a structure you cannot see. You cannot hold someone accountable for a boundary that is not defined.
Clarity is not the outcome of a well-run shared service. It is the precondition. Build it first, and the systems and processes start working the way they were designed to. Build the systems first and assume clarity will follow — and you will be back at the same problem in 18 months, with better software.
---
Clarity is not what shared services produce. It is what makes them work.