The finance operating model is the largest decision a CFO makes and the hardest one to undo. A software choice can be replaced in three years. A delivery model reshapes reporting lines, job design, location strategy, career paths and the informal knowledge that makes a finance function work — and once that has been dismantled and reassembled, restoring it is not a project anybody funds.
It is also the decision most reliably argued at the wrong altitude.
The debate that reaches an executive committee is almost always structural: centralise or federate, shared services or business-aligned, onshore or offshore, build a captive or engage a provider. Those are real questions. But they are consequences, not the decision. The decision that determines whether the model works is made one level down and is rarely made explicitly at all: for each capability, is this work that can be standardised away from the business, or work whose value depends on staying close to it?
Get that right and almost any structure can be made to function. Get it wrong and no amount of governance design, service catalogue or SLA discipline will recover it — because the failure is not in how the model is run, it is in what was asked to move.
Why this decision is hard
Four things make finance operating model design harder than it appears, and all four are structural rather than a matter of execution quality.
The benefit is legible and the cost is not. Consolidating transactional work produces a labour number that can be put on a slide before the programme starts. The offsetting cost — coordination effort, escalation volume, the retained-organisation friction, the judgement that used to happen informally and now requires a ticket — is real, distributed and arrives later. A business case that counts one and not the other is not wrong about the saving. It is silent about the price.
The organisation cannot tell you which of its processes are standardised. Almost every finance function believes its core processes are more standardised than they are, because the variation is absorbed by experienced people rather than documented as exceptions. That absorption is invisible until the work moves, at which point it surfaces as a migration that takes twice as long as planned. This is the same failure that makes automation disappoint, and it has the same root: "standardised" is rarely defined in a form that can be failed.
The decision is made once and re-examined never. Delivery models are set during a reorganisation and then treated as settled. Meanwhile the boundary of what can be standardised moves — first with workflow automation, now with document extraction, coding and matching. A model designed against 2020's boundary is not merely dated; it is holding capabilities in positions the technology has since made wrong, and nobody has looked, because looking implies another reorganisation.
Nobody in the room is neutral. A shared-services leader is measured on scope. A business unit CFO is measured on responsiveness. A provider is compensated on volume. The option that frequently deserves to win — change nothing structural this year and standardise in place first — has no advocate, produces no programme and gets no slide.
What an operating model actually decides
Before the map is useful, it is worth being precise about what is being decided, because "operating model" is used loosely enough to mean almost anything.
A finance operating model answers four questions, in this order:
- What work does finance do at all? Which activities belong to finance, which belong to
the business, and which should not be done by anyone.
- Where is each activity delivered from? Retained in the business unit, centralised in a
shared service or global business services organisation, delivered by a third party, or embedded in a centre of excellence.
- How is it governed? Who owns the process definition, who owns the outcome, who resolves
an exception, and what happens when the two disagree.
- Who does it, and what must they be able to do? Role design, skill profile, career path
and span of control.
Question 2 gets almost all the attention. Question 1 is skipped, which is why reorganisations frequently relocate work that should have been eliminated. Question 3 is deferred to implementation, which is where most of the disappointment originates. Question 4 is treated as an HR consequence rather than a design input, which is a mistake this guide returns to.
This guide is about question 2, on the explicit condition that question 1 has been answered first. Moving work you should have stopped doing is the most expensive form of this decision, and no delivery model corrects it.
The capabilities that matter
An operating model decision is only tractable at capability level. "Move Record-to-Report to the shared service" is not a decision — it is eight decisions wearing one name, and they do not all have the same answer.
The eight capabilities below carry most of the effort in a mid-market finance function and are where the delivery model decision is actually made.
| Capability | What it consumes | What makes it hard to move |
|---|---|---|
| ERP & Data Integration | Source systems | Nothing — it is infrastructure, and it is a prerequisite for moving anything else |
| Account Reconciliation | Integrated ledger data | Undocumented exception handling |
| Financial Close Management | Reconciled balances | Coordination across entities and time zones |
| Accounts Payable Automation | Supplier and PO data | Exception resolution requires supplier relationships |
| Procure-to-Pay Operations | Contract and catalogue data | Requisitioner behaviour is local |
| Collections Management | Invoice and credit data | The customer relationship is the asset |
| Budgeting & Forecasting | Certified actuals | The judgement is the deliverable |
| SOX Controls & Audit Readiness | Control evidence from all of the above | Evidence must be assembled wherever the work happens |
Two of these are frequently misclassified, and the misclassification is expensive in both directions.
Collections is treated as transactional and is not. It consumes structured data and produces a structured outcome, so it looks like a centralisation candidate. But a substantial share of overdue receivables are disputes rather than delinquency, and dispute resolution requires knowing the customer, the contract and the commercial relationship. Centralising collections without a working dispute path centralises the chasing and strands the resolving.
Budgeting and forecasting is treated as strategic and is partly not. The judgement — challenging a business assumption, framing a scenario — genuinely requires proximity. The mechanics underneath it, consolidating submissions, reconciling to actuals, maintaining the model, do not. Functions that treat planning as indivisible either centralise the partnering away, or leave expensive analysts maintaining spreadsheets.
The decision framework
Two questions place any finance capability. Both are answerable with evidence rather than opinion, which is the property that makes the map usable in a room where nobody is neutral.
Question 1 — how standardised is this process, really? Not whether a documented procedure exists. The test we use throughout our research is the one that can be failed: is this process materially harder when one specific person is on leave? If yes, the process is not standardised; it is experienced. Those are different things, and only one of them survives being moved. A second, complementary test: can you state the exception rate, and does anyone disagree with your number?
Question 2 — how much business proximity does the judgement genuinely require? Not how much proximity it has today. The discriminating question is what the person doing the work must know that is not in a system: the customer's commercial history, why a business unit's assumption changed, which supplier dispute is really a delivery problem. Where the answer is "nothing that could not be written down", proximity is a habit rather than a requirement.
Plotting the two produces four positions, and each carries a different instruction.
| Position | Standardisation | Proximity required | The instruction | The failure if ignored |
|---|---|---|---|---|
| Standardise in place | Low | Low | Do not move it yet. Fix the process where it is, then re-test. | Migrating variation, which makes it permanent and now remote |
| Centralise | High | Low | Consolidate — shared service, global business services or a provider. | Leaving scale benefits unclaimed and cost above peer |
| Retain in the business | Low | High | Leave it. Improve it locally; do not attempt to standardise it into a service. | Centralising judgement and receiving tickets instead of answers |
| Centre of excellence | High | Low–High | One method, one owner, delivered close to the business. | Either fragmenting the method or centralising the relationship |
The lower-left position is the one that matters most, because it is the one the room least wants to hear. A capability that is neither standardised nor proximity-dependent is not a centralisation candidate. It is a standardisation candidate. Moving it first is the single most common way this decision goes wrong: the migration encodes the variation, and the variation is now being handled by people with less context than the people who used to absorb it.
This is the same decision our recommendation engine reaches under the standardise before automating archetype, applied to organisation design rather than technology. The instrument differs; the sequence does not.
| Capability | Standardisation | Proximity | Position | Note |
|---|---|---|---|---|
| ERP & Data Integration | High | Low | Centralise | Prerequisite for moving anything else — do it first |
| Account Reconciliation | Usually low | Low | Standardise in place | The classic premature migration |
| Financial Close Management | Medium | Low–Medium | Centre of excellence | Method centralised; entity knowledge stays local |
| Accounts Payable Automation | High | Low | Centralise | The strongest and least contested case |
| Procure-to-Pay Operations | Medium | Medium | Centre of excellence | Requisitioning is local; sourcing and terms are not |
| Collections Management | Medium | High | Retain in the business | Disputes need the relationship; dunning can be centralised |
| Budgeting & Forecasting | Split | High for judgement | Split the capability | Mechanics centralise; partnering does not |
| SOX Controls & Audit Readiness | High | Low | Centre of excellence | Evidence follows the work wherever it sits |
Two entries in Exhibit 2 deserve their qualification. Account Reconciliation is placed in "standardise in place" not because reconciliation is inherently unsuited to a shared service — it is one of the best-suited processes in finance — but because in most functions it is not yet standardised enough to move. Once it is, it moves right and becomes a centralisation candidate. The map describes the current position, not a permanent property.
And Budgeting & Forecasting is the one capability we recommend splitting rather than placing. Treating it as a single unit forces a choice between two wrong answers.
The options, and what each one costs
Four delivery models, stated with their costs rather than their brochures.
Business-aligned (federated). Finance staff report into business units, close to the decisions. Buys: responsiveness, commercial context, credibility with the business. Costs: method fragmentation, duplicated effort, inconsistent numbers, and a control environment that must be evidenced separately in each unit. Fails when: the organisation scales past the point where informal coordination works, usually visible as the same question answered differently by two units in the same week.
Shared services (centralised captive). Transactional work consolidated into one or more internal centres. Buys: scale, standardisation, a measurable service, career paths for process specialists. Costs: coordination overhead, escalation latency, retained-organisation duplication, and a real risk of the centre optimising its own metrics rather than the outcome. Fails when: work is migrated before it is standardised, or when the retained organisation is not redesigned at the same time and quietly rebuilds a shadow team.
Global business services. Shared services extended across functions, with end-to-end process ownership. Buys: genuine process ownership across finance, procurement and parts of HR, which is where the residual value sits once basic consolidation is done. Costs: substantially higher governance load, and a dependency on process-owner authority that most organisations do not actually grant. Fails when: it is a shared service renamed — the label changes, the ownership does not.
Outsourced. A third party delivers defined processes. Buys: speed to a standard, access to tooling and scale without capital, and a genuinely variable cost base. Costs: the provider standardises to their model, change is priced, and institutional knowledge leaves. Fails when: the process was not standardised before transition — you are then paying a day rate to document your own exceptions, and the contract makes fixing them a change request.
| Business-aligned | Shared services | Global business services | Outsourced | |
|---|---|---|---|---|
| Unit cost | Highest | Low | Low | Lowest at steady state |
| Responsiveness to the business | Highest | Low | Medium | Lowest |
| Method consistency | Lowest | High | Highest | High — but their method |
| Control evidence | Fragmented | Strong | Strong | Contractual, not observable |
| Cost of changing the process later | Low | Medium | Medium | High — priced as a change |
| Requires standardisation first | No | Yes | Yes | Yes, most of all |
| Best for | Judgement work | High-volume standardised work | End-to-end process ownership | A defined process at a known standard |
The final row is the one that decides most cases, and it is why three of the four models share the same prerequisite. Only the business-aligned model tolerates unstandardised work — which is precisely why unstandardised functions keep choosing it by default, and why they should not confuse that tolerance for a recommendation.
What actually goes wrong
Five failure modes account for most disappointing outcomes. Four are decided before migration begins.
1 · Migrating variation. The process was not standardised; the move encoded it. Now the variation is permanent, remote and handled by people with less context. Decided before.
2 · The retained organisation was never designed. Scope moved out; roles did not change. Within eighteen months the business units have rebuilt an informal finance capability, and the function is paying twice. Decided before.
3 · Governance without authority. Process owners are appointed and given accountability for outcomes they cannot enforce, because the resources report elsewhere. Escalation becomes the operating mechanism. Decided before.
4 · Optimising the metric rather than the outcome. The centre is measured on cost per transaction and hits it, while cycle time, exception rates and business satisfaction all deteriorate — none of which appear on its scorecard. Decided before.
5 · Losing the informal knowledge. The people who absorbed the variation left during transition, and what they knew was never written down. This is the failure that shows up as "the numbers used to be right and now they are not". Decided during.
Note what is absent from that list: choosing the wrong location, choosing the wrong provider, choosing the wrong technology. Those failures happen, and they are recoverable. The five above are design failures, and four of them are settled before anybody moves a desk.
The people question, which is a design input
Question 4 — who does the work and what must they be able to do — is normally handled as a consequence of the structure. It is better treated as a constraint on it.
Three implications follow directly from the map.
Centralising transactional work removes the traditional training ground. The path from transactional finance to business partnering ran through doing the work and seeing where it breaks. Remove that step without replacing it and the function is left recruiting business partners externally at a premium — which appears in the cost line the model was supposed to improve, one level down and two years later.
A centre of excellence needs a genuinely different skill profile. Owning a method across a federated organisation is influence work: defining a standard, arguing it, maintaining it against pressure. Staffing a centre of excellence with the strongest process operators is a common and understandable error, and it produces a well-run centre nobody follows.
Retained roles are harder, not easier. Once the transactional work leaves, what remains is the judgement — which is the part that was previously subsidised by the routine work surrounding it. A retained team is a smaller team of more capable people, and if the design assumes the same people doing less, the model will underdeliver for reasons that look like attitude and are actually design.
What we would do — and when we would do otherwise
What we would do, in most mid-market finance functions:
Start with ERP and data integration regardless of the structural decision, because every other capability inherits it and no delivery model compensates for data nobody can trace.
Then run the map across your eight largest processes and act on the lower-left quadrant first — standardise in place, with no structural change and no business case. This is the least satisfying recommendation available and reliably the highest-return one. It requires no reorganisation, produces no announcement, and it determines whether everything that follows encodes a process or a variation.
Then centralise what the map places in the lower-right — beginning with accounts payable, which is the strongest and least contested case in finance. Design the retained organisation in the same programme, not afterwards.
Establish centres of excellence for close management, procure-to-pay and controls, and be honest that this is the hardest of the four models to run, because it depends on authority you must actively grant.
Leave collections and business partnering where the relationship is, and improve them locally.
When we would do otherwise:
When a hard external date exists. A carve-out, listing or acquisition integration has a timetable that does not care about standardisation readiness. Move to the date, and record the skipped standardisation as explicit debt with an owner and a remediation date, so that the rework is priced rather than discovered.
When the function is already at the cost frontier. If you sit at or below the top-quartile cost of finance — 0.8% of revenue against a peer median of 1.1% in our benchmark set — and revenue per finance FTE is above the $12.5M top quartile, a consolidation programme is unlikely to find much and will certainly cost capability. The upside at that point is in reliability and capacity, not in structure.
When the close is unreliable. A close running above the peer median of 6 days, or with a material restatement history, is telling you the problem is process integrity rather than delivery model. Restructure that and you will get the same close, delivered from further away.
When the last reorganisation was under three years ago. Change capacity is finite and largely unmeasured. A function still absorbing its previous model will underdeliver the next one regardless of design quality — and that outcome will be attributed to the design.
The strongest case against this framework is that it treats a political decision as an analytical one. Operating model choices are settled by who has sponsorship, which executive is protecting headcount, what the board was promised, and whether a cost commitment has already been announced. A CFO arriving with a capability-by-capability map may find the structural answer was decided before the analysis began — and being right on the merits is not the same as prevailing.
That critique is fair, and we would not claim the map wins the argument on its own. What it does is change what the argument is about. A debate conducted entirely at the level of structure has no evidence in it, which is exactly the condition under which the loudest sponsor wins. A debate that has to engage with "this specific capability is not standardised enough to move, and here is the test it fails" is one where a wrong decision at least has to be taken knowingly.
There is a second, sharper objection: both axes are judgements. Standardisation can be tested reasonably well; required business proximity is genuinely contestable, and a business unit leader defending local headcount will assess it differently from a shared-services leader defending scope. We publish the tests we use precisely so that disagreement lands on the test rather than on the conclusion. If you believe collections needs less proximity than we do, that is a productive disagreement — and it is a more useful one than agreement with a map nobody examined.
Finally, this guide recommends splitting one capability and deferring another, which makes the resulting model more complex than a clean centralisation. Simplicity has real operational value, and a slightly wrong model that everybody understands can outperform a precisely correct one that nobody can run. Where the map's answer is marginal, prefer the simpler structure.
Methodology and limitations
The capability placements in Exhibit 2 are editorial judgements derived from our capability model and its dependency structure, applied to the modal mid-market finance function. They are not measured outcomes, and we have not observed a population of operating models. Where a placement is contestable we have said so in the exhibit itself.
The benchmark figures are drawn from our independent benchmark models — peer set n=58, mid-market B2B software companies of comparable revenue and stage, as of 2026-01-01. They describe that population and no other. A comparison against the wrong peer set is worse than no comparison, because it produces confidence in a specific direction: if your organisation is not in that population, use the reasoning and discard the numbers.
The two axes of the map are ordinal, not measured. Standardisation admits a test that can be failed; required business proximity is a judgement, and we have flagged it as the weaker of the two throughout.
What to do with this
If you take one action, take this one: list your eight largest finance processes by effort rather than by prominence, apply the two tests, and mark every capability sitting in a quadrant it was never tested against. In most functions this identifies two or three — and they are usually the ones with an existing programme attached.
You then have a decision worth having: resequence, or proceed knowingly and price the debt. Both are defensible. Proceeding without knowing is not.
- The operating model decision is made at capability level, not at the org chart. Two
questions settle it — how standardised is the process, and how much business proximity does its judgement genuinely require. The structure is the output of those answers, not the input.
- Most disappointing outcomes are decided before migration begins. Four of the five common
failure modes — migrating variation, an undesigned retained organisation, governance without authority, and optimising the metric instead of the outcome — are settled at design time.
- The lower-left quadrant is where the value is, and it has no sponsor. Work that is neither
standardised nor proximity-dependent should be standardised in place, not moved. It requires no reorganisation, produces no announcement, and determines whether everything after it encodes a process or a variation.