Finance Process Ownership: Who Owns the Number from Start to Finish?

One thing implementation work forces you to do is ask deceptively simple questions.

Where does this number originate? Who validates it? Who decides the accounting treatment? Who approves it? Who makes sure it reaches the final report correctly?

Usually, there is an answer to every question.

And yet, across implementations, I have encountered processes where something still feels missing. Everyone knows what they are responsible for. The SOPs exist. Approval matrices are clear. System access has been assigned. But ask a slightly different question: who owns the outcome from beginning to end? And the answer becomes less obvious.

That distinction matters more than it first appears.

Finance is organised vertically. Numbers travel horizontally

Take intercompany accounting. One entity raises the transaction. Another books the corresponding entry. Treasury may be involved in settlement. Tax may determine part of the treatment. Local finance teams validate balances. Group finance eventually has to eliminate them.

Every participant can perform their responsibility correctly and an intercompany difference can still reach consolidation.

Related-party reporting has similar characteristics. So do allocations, certain disclosures and several processes that feed group reporting. The number crosses organisational boundaries before it becomes a reported number.

Most organisations, however, allocate responsibility function by function. That is logical. People need clear roles.

The difficulty is that the financial outcome does not respect those boundaries.

The RACI can be completely right

This is where implementations have taught me to be a little cautious about beautifully documented responsibility matrices.

A RACI can tell us exactly who performs each activity. It can tell us who approves it, who should be consulted and who needs to be informed. That is useful process discipline.

But activity ownership and outcome ownership are not quite the same thing.

Suppose an intercompany mismatch appears at month-end. The originating entity has booked its side correctly according to its information. The counterparty has done the same. Both teams have met their deadlines. Group finance discovers the mismatch and spends time resolving it.

Nobody necessarily failed.

The process did.

That is a much harder problem because there may be no individual error to correct. What is missing is ownership of what happens between responsibilities.

Implementation makes the gaps visible

This tends to surface during implementation because systems are less tolerant of ambiguity than organisations are.

When we configure workflows, validations and reporting logic, somebody eventually has to answer questions that the existing process may have managed informally for years. What happens if the two entities disagree? Who resolves the difference? At what point does it escalate? Whose definition prevails? How long can an unresolved item remain open?

In a manual environment, experienced people often bridge these gaps without anyone thinking much about them. They know whom to call, which email to chase and when to escalate.

The process appears to work because people compensate for the spaces between the boxes.

When you try to put that process into a system, those spaces become much harder to ignore.

There is another side to this

End-to-end ownership can also be overdone.

Putting one person “in charge” of a process does not magically give that person control over everything required to produce the outcome. Group finance cannot prevent an entity from originating poor information simply because group finance has been declared the process owner.

That merely replaces fragmented accountability with nominal accountability.

The more useful question is whether someone has the authority, visibility and mechanisms required to manage the outcome across the boundaries it crosses.

That might mean common definitions. It might mean validations at the point of entry rather than at consolidation. It might mean exception workflows, ageing rules or escalation paths. Sometimes it simply means making one team responsible for seeing that an issue reaches closure, even when another team must fix it.

Ownership has to travel as far as the number does.

The space between the boxes

We spend considerable effort defining roles in finance, and rightly so. Segregation of duties itself depends on responsibilities being separated.

But some of the most persistent problems I have seen do not sit inside a role. They sit between roles.

That is why they survive reorganisations, new SOPs and sometimes even new systems. Each box can be functioning exactly as designed while the hand-offs between them continue to create friction.

Perhaps that is the more useful way to examine an end-to-end finance process: not only by asking whether every activity has an owner, but by looking carefully at what happens when ownership changes hands.

Because the number does not know that it has crossed from one person's responsibility into another's.

It just keeps travelling.

Ledger Note

A finance process can have an owner for every activity and still have nobody owning the journey from transaction to reported number.