Two views of the same money
Every payment can be described two ways: what it was for, and who it was for. The first gives you a cost report — software, travel, rent. The second gives you a cost centre report — engineering, sales, the northern site.
Most organisations produce the first well and the second badly, and the reason is structural. The type of a cost is usually stated on the document. The centre it belongs to is not stated anywhere; it is a fact about your organisation that has to be applied on top, and applying it consistently is work that nobody owns until someone insists on a departmental report.
This page is about that layer: how to assign spending to centres, what to do with the costs that belong to several at once, and how to produce something each owner can check rather than dispute.
Why the report gets disputed
Cost centre reports attract more argument than any other management report, and the arguments are usually about three things — only one of which is really about allocation.
“That cost is not mine.” The most common objection and the easiest to settle, if the report is traceable. Open the line, show the payments, and either the manager recognises them or a genuine misallocation has been found in thirty seconds. Without traceability the same exchange takes a week of email.
“Why am I carrying that share of the overhead?” A real question about the basis, and it deserves an answer once — in writing, at the start of the year — rather than every month.
“I cannot control that anyway.” Often correct. Allocating an uncontrollable cost to a manager for accountability purposes achieves nothing except resentment, which is why the controllable subtotal below matters.
Direct costs are the easy half
Anything bought by one centre for its own use assigns itself. A design tool licensed to the design team, a trade subscription for the finance team, materials for one production line — the payee tells you the centre, and the rule can be written once and applied forever.
In most organisations this covers the majority of transactions by count and a substantial share by value. Getting it done is a matter of working through the payee list by value, largest first, and assigning each to a centre. Twenty payees usually settles most of the dataset.
The exception worth watching: a payee that serves several centres. A stationery supplier or a travel agent used by everyone cannot be assigned by payee, and treating it as if it could is how one department ends up owning the whole travel budget. Those payees need to be identified explicitly and pushed into the shared or split-payment treatment below.
The tagging mechanism that carries this through the data is covered on our tagging feature page, and the categorisation layer underneath it on the transaction categorisation page.
Choosing a basis
Once you have decided to allocate, you need a basis. There is no correct answer, and time spent looking for one is time not spent on the report.
| Basis | Suits | Objection you will hear |
|---|---|---|
| Headcount | HR, IT, general admin | Our people are cheaper to support than theirs |
| Floor area | Rent, utilities, cleaning | Our space is a warehouse, not an office |
| Revenue share | Leadership, marketing | It penalises the unit that is growing |
| Transaction volume | Finance, payment processing | Our transactions are simpler than theirs |
| Equal split | Small teams, low-value overheads | It is arbitrary — which it is, and sometimes that is fine |
Every basis has a defensible objection, which is the point: none of them is right, so pick the one people find least unreasonable, write it down, and keep it for the year. The equal split deserves more respect than it gets — for a low-value overhead, the cost of arguing about a sophisticated basis exceeds anything the sophistication buys.
Recalculate the basis annually, not monthly. A headcount-based allocation that shifts every time someone joins produces a report where comparisons against prior periods mean nothing.
Recharges, and how they become unreadable
A recharge is one centre paying and another bearing the cost. They are entirely legitimate, and they are the mechanism by which cost centre reports most often become impossible to follow.
The failure mode is double counting. The paying centre shows the cost, the receiving centre shows the recharge, and the total across all centres exceeds what the organisation actually spent. Anyone who adds up the report notices, loses confidence, and stops using it.
The fix is a rule and a check. The rule: a recharge must show as a credit in the paying centre and a debit in the receiving one, so it nets to zero across the organisation. The check: the sum of all cost centres must equal total spend, run every period, with any difference investigated before publication.
Keep recharges visible rather than netting them into the underlying cost. A receiving manager who sees “IT recharge” as its own line can question it; one who sees it silently blended into their software line cannot, and will eventually discover it in a way that costs you credibility.
One payment, several centres
The most common practical problem in the whole exercise: a single bank line that belongs to more than one centre. A software subscription used by three teams. A delivery containing goods for two sites. An insurance premium covering everything.
It must be split, and the split must follow a written rule rather than a monthly decision. Deciding afresh each month guarantees drift, and drift in an allocation is invisible until someone compares two years.
Where the split is fixed — three teams, equal thirds — record it against the payee once and it applies automatically thereafter. Where it varies with something measurable, such as licence counts, record the driver and update it on the same annual cycle as the rest of the basis.
Where the split is genuinely arbitrary, say so on the report. A footnote reading “insurance allocated by headcount; basis fixed for the year” pre-empts the question and signals that the arbitrariness is known rather than hidden.
How many cost centres to have
Fewer than you think. The instinct is to mirror the organisation chart, which produces a structure that changes whenever the organisation does and destroys comparability every time.
The test is accountability: a cost centre needs one person who can be asked about it and can actually influence it. If no such person exists, the centre is a filing category and will be reported on by nobody.
Most organisations below a few hundred people work well with five to fifteen centres. Beyond that, the report becomes a spreadsheet nobody reads across, and the marginal centre adds allocation work without adding a decision.
Resist restructuring the centres mid-year. When the organisation changes — as it will — map the old centres onto the new for reporting purposes and make the structural change at the year boundary, alongside the budget rebuild.
How it works
1 · Convert every account
Current accounts, cards, each entity — up to 100 files in one pass, each row keeping the account and file it came from.
2 · Check completeness
Statement balances recalculated from the rows and the series checked for gaps, so no centre is understated by a missing month.
3 · Assign direct costs
By payee, worked through by value. Twenty payees usually settle most of the dataset.
4 · Apply allocation rules
Shared costs spread on the recorded basis; split payments divided by their recorded rule.
5 · Net the recharges
Credit the payer, debit the receiver, and check that all centres sum to total spend.
6 · Export per centre
One sheet each, fixed columns, with the underlying transactions attached so every figure can be checked.
What the report should show
One page per centre, and the page has a specific shape: direct costs by category, a controllable subtotal, allocated shared costs, a full total, and a comparative.
The controllable subtotal is the number the manager is judged on, and separating it visibly from allocated overhead is what makes the report acceptable to them. Everything below the subtotal is context.
The comparative should be the same period last year rather than the previous period, wherever seasonality exists. Comparing a department against its own prior year is far more informative than comparing it against another department that does entirely different work — the mechanics are on the period comparison page.
Add a budget column where one exists, and commentary only against material variances — the budget versus actual page covers that layer, and the variance commentary article covers writing it so it gets read.
Owners, and what accountability actually requires
A cost centre without an owner produces no behaviour change whatsoever. This is the single most important design decision in the whole exercise and it is not a technical one.
Accountability needs three things, and most implementations supply one. The owner must be able to see the detail, must be able to influence the costs, and must be asked about them on a predictable rhythm. A report sent to someone who cannot open the detail, cannot change the spending and is never asked will be filed unread, correctly.
The rhythm matters more than the frequency. A cost centre pack that arrives on the fourth working day every month becomes part of how managers run their areas. One arriving somewhere between the fourth and the eighteenth is treated as an occasional document however good it is.
Send each owner their own centre rather than the full pack. People engage with what they are accountable for and skim everything else, and a fifteen-page pack sent to everyone reliably produces less scrutiny than one page sent to each.
Projects and sites
A project is a cost centre with an end date, and the reporting emphasis shifts accordingly: cumulative-to-date against total approved matters more than any individual period.
That makes completeness more important than timeliness. A project overspend discovered a month late is recoverable; a project cost that never got assigned at all distorts the final figure permanently and usually surfaces at the point of closure, when nothing can be done.
Sites behave differently again. They are permanent, comparable to one another, and the interesting question is usually relative performance — which is where allocation policy matters most, because an unfair allocation makes one site look structurally worse than another for reasons that have nothing to do with how it is run.
Where sites belong to separate legal entities, the combination problem comes first: see multi-entity reconciliation and the group finance use case.
Six mistakes
Changing the allocation basis mid-year
Every comparison against prior periods becomes invalid, and the change always looks self-serving whoever proposed it.
Allocating everything, including the uncontrollable
Managers stop engaging with a report where most of the number is outside their influence.
Netting recharges into the underlying cost
The receiving manager cannot see or question a charge that has been blended into their own line.
Mirroring the org chart
The structure changes whenever the organisation does, and comparability dies with each restructure.
Splitting shared payments by monthly judgement
The allocation drifts invisibly, and the drift only surfaces when someone compares two years.
Publishing figures nobody can check
Every dispute becomes unresolvable, and unresolvable disputes turn into disengagement rather than questions.
Who this is for
Finance teams producing departmental packs
Where the allocation currently lives in a spreadsheet that one person understands and nobody else can audit.
Multi-site operators
Comparing sites fairly requires an allocation policy that survives scrutiny from the site that comes off worst.
Project-driven organisations
Agencies, consultancies and construction, where cumulative spend against approval is the number that matters.
Organisations introducing accountability
Moving from one central budget to owned budgets, where the first report sets expectations for every one after it.
What this is not
It is not a costing methodology. Activity-based costing, absorption costing and the rest are accounting frameworks with their own literature; this is about getting transaction data into a shape any of them can be applied to.
It does not decide your allocation policy. It applies the basis you choose, consistently, and records what was applied. Which basis is fair for your organisation is a management judgement and will remain one.
It does not resolve the argument about whether a cost belongs to a centre. It makes the argument fast by showing the payments underneath, which turns out to be most of what people wanted.
And it does not post journals. It produces a dataset and a report; the export feature covers getting the result into the system you already run.