How Should Shared Costs Split Across Cost Centres Be Approved?

Introduction

Most approval workflows are built on a clean assumption: an expense belongs to one cost centre, and that cost centre’s head approves it. The assumption holds for the large majority of transactions, which is why it survives design review so easily.

Then someone runs a marketing campaign that promotes two product lines, or books a venue for an event that three divisions attend, or renews a software licence used across the group. The cost is real, singular and shared. The requester belongs to one unit; the spend consumes budget in several. And the workflow, faithfully derived from the requester’s cost centre, routes the request to exactly one head.

The second unit finds out at month-end, when the charge appears in their results. This is one of the most common gaps in otherwise well-designed approval matrices, and it tends to be discovered during a phase-two design conversation rather than at initial rollout — often phrased as a question nobody had an answer for: what do we do when this must be signed by two cost centre heads?

This article covers routing and authority for split-coded spend. It assumes budget balances are already validated at entry, a control examined separately in real-time budget validation for expense requests.

For governance context on delegated authority and cost accountability see the Institute of Internal Auditors, CIMA management accounting resources and Gartner’s finance leadership research.

Why Does Requester-Based Routing Break for Shared Costs?

Requester-based routing breaks because it infers accountability from who submitted the request rather than from whose budget the money leaves. For single-owner spend those are the same thing, so the flaw stays invisible until an allocation splits them apart.

Consider the mechanics. A marketing manager in Business Unit A raises a request for a campaign benefiting units A and B equally. The workflow reads the requester’s profile, finds cost centre A, and routes to the head of A. That head approves — reasonably, since half the value serves their unit. The posting then charges both A and B. The head of B has approved nothing and will not learn of the commitment until the general ledger tells them.

The three consequences

Budget accountability becomes fiction. A cost centre head is held to a budget they cannot control, because charges can arrive from requesters in other units without any consent step.

Disputes move to the wrong place. Because the objection can only be raised after posting, it becomes a reclassification argument between finance and two business units, resolved by journal entry weeks after the money was committed.

The workaround is worse. Teams frequently respond by having the requester email the second head for informal sign-off and attach the reply. This creates approval evidence that lives outside the system, cannot be reported on, and does not block the workflow if it never arrives.

Should Every Affected Cost Centre Head Approve?

Every cost centre carrying a material allocation should approve, using AND logic, because the purpose of the control is consent to budget consumption and a partial consent does not achieve it. Routing to only the largest share reproduces the original problem for every smaller unit.

The obvious objection is latency. Three approvers take longer than one, and finance functions are rightly wary of adding steps. The answer is not to reduce who approves but to bound when the rule triggers.

Materiality thresholds

Set a floor below which an allocation does not pull its cost centre head into the chain. This can be a percentage of the total, an absolute value, or whichever is lower. A five percent allocation of a modest invoice does not warrant an additional approval cycle; a forty percent allocation of a large one clearly does.

The threshold should be a documented policy decision, not an implementation detail, because it defines the point at which the organisation accepts charges without explicit consent. Finance and the business units should agree it jointly, and it should be reviewed as spend patterns change.

AND across units, OR within

The two logics serve different purposes and both are needed.

AND across cost centres. Each affected unit must approve. One unit cannot consent on another’s behalf, because they are consenting to different budget consumption.

OR within a cost centre. Where a unit has several authorised approvers — a head and a deputy, or two delegates — any one of them may approve for that unit. This is what prevents leave and travel from stalling the chain, and it is the same fallback principle described in approval delegation and fallback approvers.

Configuring AND where OR belongs produces deadlock; configuring OR where AND belongs recreates the consent gap. Most implementations get one of these wrong on the first pass.

How Should the Allocation Itself Be Captured?

The allocation must be a structured field — a set of lines each holding a cost centre, a percentage and a derived amount — because approver routing has to be computed from it. A free-text note explaining the intended split cannot be read by a workflow engine.

This sounds obvious and is frequently violated. Many implementations capture the split as a comment for the finance team to action during posting, which places the allocation downstream of approval. Once that ordering exists, allocation-aware routing is impossible in principle: the system cannot route to approvers derived from data that does not yet exist when routing occurs.

Percentages, not fixed amounts

Percentage splits survive value changes; fixed-amount splits do not. When a request is approved on an estimate and the final invoice differs — the ordinary case for services and events — a percentage allocation redistributes automatically while a fixed-amount allocation leaves a remainder nobody has agreed to carry.

The same estimate-to-actual dynamic causes approval rework elsewhere in expense workflows, as discussed in travel request estimate versus actual approval rework. Percentage allocation is the mechanism that keeps a variance from becoming a full re-approval.

What each approver should see

Each approver should see the complete request with their own allocation highlighted. The two failure modes here are symmetrical and both common.

Showing an approver only their own share hides the context needed to judge whether the split is fair — a head cannot assess a thirty percent allocation without knowing who holds the other seventy. Showing the total without highlighting their portion produces the opposite error, where approvers believe they are authorising the entire amount and escalate unnecessarily or refuse outright.

How Should Budget Validation Work Across Multiple Allocations?

Each allocation line must be validated against its own cost centre’s available balance before submission, and a breach on any single line should block the request. Validating only the total is a control that appears to work and does not.

The reason is straightforward. A request for a shared campaign might pass comfortably against the combined budgets of three units while the smallest unit has no remaining balance at all. Aggregate validation would pass it, the posting would push that unit negative, and the breach would surface at close — which is precisely the failure that pre-submission validation exists to prevent.

Failing on one line

When one allocation fails, the whole request must stop. The alternative — advancing the lines that pass and holding the one that fails — fragments a single commercial commitment into partially approved pieces and leaves the payment instruction ambiguous.

The requester should be told which cost centre failed and by how much, so the choice is clear: reduce that unit’s share and redistribute, secure a budget top-up, or defer. Naming the specific unit matters; a generic budget failure message sends requesters to finance to find out what happened.

What Happens When One Cost Centre Head Rejects?

A rejection should return the request to the requester for re-allocation, not cancel it, because the underlying commercial need usually survives the objection. What is being rejected is a proposed split, not the purchase.

Most rejections in shared-cost workflows are disagreements about proportion rather than about merit. A unit head who believes their share overstates their benefit is not blocking the campaign; they are negotiating. Treating the rejection as terminal forces the requester to raise a fresh request, losing the approvals already given and restarting a cycle that may have taken a week.

Re-routing after revision

When the split is revised, only newly affected approvers need to act. If a unit already approved and its share is unchanged or reduced, re-approval adds nothing — the consent they gave covers the smaller amount. If a share increases, or a new cost centre is added, those approvers must be asked.

This selective re-routing is what keeps re-allocation cheap enough to be usable. Full restarts on every revision push teams back to informal email negotiation before submission, which restores the invisible-consent problem the workflow was built to remove. Related routing patterns are covered in AP approval workflow automation and multi-entity expense management architecture.

Payment stays singular

Allocation affects accounting distribution and budget consumption. It does not affect the payment instruction. One invoice to one supplier is one payment regardless of how many cost centres share it, and the same holds for an employee claim distributed across units but reimbursed to one person. Conflating allocation with payment produces split remittances that suppliers cannot reconcile.

How to Implement Allocation-Aware Approval Routing: A Step-by-Step Guide

Step 1 — Identify recurring shared-cost categories. Shared marketing, group events, joint licences, shared facilities and group insurance are the usual population. Knowing the categories keeps the design grounded.

Step 2 — Make allocation structured. Replace free-text splitting instructions with allocation lines holding cost centre, percentage and derived amount.

Step 3 — Set the materiality threshold. Agree with the business the minimum share that pulls in an approver, and document it as policy.

Step 4 — Derive approvers from allocations. Compute the approver list at submission from the allocation lines, not from the requester’s profile.

Step 5 — Configure AND across units, OR within. Every material cost centre must approve; any delegate within a unit may approve for it.

Step 6 — Validate each line against its own budget. Block the request on any single allocation breach and name the failing cost centre.

Step 7 — Build the re-allocation loop. Return rejections to the requester, allow revision, and re-route only to newly affected approvers.

How Peakflo Routes Shared-Cost Approvals

Peakflo derives the approval chain from the allocation itself, so every unit consuming budget is asked before the commitment is made rather than informed after it posts.

Allocations post through Peakflo’s ERP integrations, including SAP and NetSuite, and sit within the wider travel and expense module. Size the impact with the savings calculator or request a demo.

Our Verdict: Route From the Money, Not From the Requester

The single design principle worth taking from this is that approval should follow the budget, not the person. Requester-based routing is a convenient proxy that works until spend is shared, and it fails silently rather than loudly — no error is raised, no request is blocked, a charge simply appears in a unit that never agreed to it.

Allocation-aware routing costs more to configure and adds approvers to a minority of requests. In exchange, cost centre accountability becomes real, month-end reclassification arguments largely disappear, and the informal email approvals that currently sit outside every reporting system stop being necessary. The materiality threshold is what keeps the cost proportionate, and getting that number agreed is genuinely the hard part of the project. Broader guidance on cost accountability is available from Deloitte’s finance transformation research and PwC’s finance function insights.

Best for:

• Multi-entity groups where campaigns, events or licences routinely benefit several business units
• Organisations holding cost centre heads accountable to budgets they do not fully control
• Finance teams resolving allocation disputes through month-end reclassification journals
• Groups where second-approver consent currently lives in email attachments
• Shared-services functions absorbing allocation exceptions from many units

Not recommended if:

• Shared costs are rare and handled adequately by a standing allocation rule
• Your organisation runs a single cost centre hierarchy with no meaningful budget ownership
• Splits routinely exceed five cost centres, where internal recharge is the better mechanism
• Approval latency is already the binding constraint and no materiality threshold can be agreed

Conclusion

Shared costs expose a quiet assumption in almost every approval matrix — that whoever raises a request is the person whose budget it consumes. For most spend that is true, which is why the exception goes undesigned until a marketing campaign spanning two units forces the question.

The remedy is not more approvers everywhere. It is capturing the split as structured data, deriving the approver list from that data, and setting a materiality floor so the rule fires only when the stakes justify it. Route from the money rather than from the requester, and cost centre accountability stops being a reporting fiction maintained by month-end journals.

Frequently Asked Questions

What is a shared cost in expense and payables workflows?

A shared cost is a single purchase or claim whose benefit spans more than one cost centre or business unit, so its value is allocated across several charge codes rather than posted to one owner.

Why does a single-approver workflow fail for shared costs?

Because routing is normally derived from the requester’s own cost centre. When the spend also consumes another unit’s budget, that second unit’s head never sees the request, and the charge appears in their results without their consent.

Should every cost centre head approve a shared cost, or just the largest?

Every cost centre carrying a material allocation should approve, using AND logic. Approving only the largest share means smaller units absorb charges they never agreed to, which is the exact problem the control is meant to solve.

What is the difference between AND and OR approver logic?

AND logic requires every named approver at a level to approve before the request advances, while OR logic lets any one of them approve on behalf of the level. Shared-cost allocation needs AND across cost centres and OR only within a single cost centre’s delegates.

Should approvers see the whole request or only their own share?

Each approver should see the full request with their own allocation highlighted. Showing only their share hides whether the split is reasonable, and showing the total without emphasis makes approvers assume they are liable for the whole amount.

How should budget validation work for a split-coded expense?

Each allocation must be validated against its own cost centre’s available balance before submission. A request that passes on total value but breaches one contributing budget should not reach approval at all.

What happens when one cost centre head rejects a shared cost?

The request should return to the requester for re-allocation rather than being cancelled. The commercial need usually survives the rejection; what changes is the split, so the workflow should support revising percentages and re-routing.

Should shared costs be split by percentage or fixed amount?

Percentage splits are preferable because they survive changes to the invoice value, whereas fixed amounts break when the final figure differs from the estimate and force a full re-allocation.

How many cost centres should a single expense be split across?

Practical limits sit at three to five. Beyond that, approval latency grows faster than the allocation accuracy gained, and a standing allocation rule or internal recharge is usually a better mechanism.

How should a shared cost be paid if it is allocated to several units?

Payment is a single transaction to one payee regardless of allocation. Splitting affects accounting distribution and budget consumption, not the payment instruction, and conflating the two creates reconciliation problems.

Do approval thresholds apply to the total or to each allocation?

Thresholds should apply to the total value for escalation purposes, because the organisation is committing that full amount. Allocation size determines who must approve, not how high the request escalates.

How long does it take to implement allocation-aware approval routing?

Typically 6 to 12 weeks, with most of the effort spent agreeing the materiality threshold and the approval matrix rather than configuring the workflow itself.