Recharged by headcount, paid for by the wrong unit.
Shared services (IT, HR, finance, procurement) are recharged to business units by blunt keys like headcount or revenue. So a lean unit that barely uses the service subsidises a heavy one, the chargeback feels arbitrary, and the service centre gets no signal to be efficient. We cost shared services by activity and transaction with TDABC, so each unit pays for what it actually consumes and the recharge becomes something both sides can defend.
Cost and Profitability Consulting · 150+ models since 2010 · TDABC
A blunt key spreads, it does not allocate.
A shared service exists because it is cheaper to run once for everyone than many times over. The catch is the recharge. Split the cost by headcount, revenue or a flat percentage and you are assuming every unit consumes the service in proportion to its size, which almost never holds. One unit logs three thousand tickets a year; another logs ten. They get the same bill.
So the light user quietly subsidises the heavy one, the recharge looks like a tax rather than a price, and finance spends the budget cycle defending a number nobody believes. Worse, the service centre sees no link between what it does and what it charges, so it has no reason to get leaner.
CHARGED VS CONSUMED, BY UNIT
Illustrative. Every unit is recharged the same flat amount. True cost by consumption shows two units overpaying and subsidising two that use far more than they are charged.
Same headcount, opposite usage.
Charged the same
Two business units have the same headcount, so the IT shared service recharges them the same amount. On the cost report they look like equal consumers of central support.
Consume very differently
Unit A is stable and self-sufficient, with few tickets and no custom systems. Unit B runs three bespoke applications, raises three times the tickets and drives most of the integration work.
True cost separates them
Cost the activity each one consumes and Unit A is paying well above its real cost while Unit B is paying well below, funded by everyone else.
It is a pricing fix
Recharge by activity, publish the unit rates, and let units see the transactions behind the bill. The cost does not move; who pays for it finally matches who causes it.
Same bill on the report, one funds the other.
| Unit A | Unit B | |
|---|---|---|
| Headcount | 200 | 200 |
| Recharge (headcount key) | €420,000 | €420,000 |
| Tickets & requests / year | 3,100 | 9,400 |
| Custom apps supported | 0 | 3 |
| True cost (TDABC) | €248,000 | €712,000 |
| Over / under recovery | +€172,000 overpaid | −€292,000 underpaid |
On the headcount key the two units are identical line items. By consumption, one is paying a third more than it should and the other little more than half its real cost. Only an activity view makes the subsidy visible, and arguable.
FROM SPEND TO WHAT EACH UNIT RECEIVES
Illustrative. A shared-services budget re-expressed from what it buys, to the services it runs, to the value delivered to each part of the business, so the recharge traces all the way back to spend.
Cost lands on the activity, then the unit.
Map the service catalogue
The activities the shared service actually performs: tickets, onboarding, payroll runs, purchase orders, application support, the work the budget pays for.
Cost each activity per unit of work
TDABC sets a cost per ticket, per run, per support hour from practical capacity, so idle and excess capacity is visible instead of buried in the recharge.
Attribute to the consuming unit
Each business unit carries the cost of what it actually consumed, transaction by transaction, not a share of the total by size.
Publish the rates
Unit rates and a clear bill turn the recharge into an internal price, which both units and the service centre can plan and improve against.
A recharge that holds up in the room.
When the recharge reflects consumption, the budget conversation stops being about fairness and starts being about demand. Heavy users have a reason to consume smarter, light users stop subsidising them, and the service centre can benchmark its unit rates and justify its headcount with a number rather than a story.
The model is built on your data and handed over, so the chargeback stays current as demand shifts.
Frequently asked questions
- Why is recharging shared services by headcount a problem?
- Headcount, revenue or a flat split assume every unit consumes the service in proportion to its size, which is rarely true. A lean unit that barely uses the service ends up subsidising a heavy one, the recharge feels arbitrary, and the service centre gets no signal about what actually drives its cost.
- What is activity-based chargeback?
- It is recharging a shared service by what each unit actually consumes: tickets, transactions, projects, support hours, costed per activity with TDABC. Each unit pays for its real usage, so the recharge is transparent and can be challenged line by line.
- Won't this just create internal arguments?
- It usually ends them. Arguments come from recharges nobody can explain. When a unit can see the transactions behind its bill, the conversation moves from whether the charge is fair to how to consume the service more efficiently.
- Does this apply beyond IT?
- Yes. The same approach works for any shared function: HR, finance, procurement, facilities and legal. Anywhere a central cost is split across business units by a blunt key, activity-based costing makes the split defensible.
See who really uses the shared service.
The Profit Check needs no data upload. It points to where your internal recharges are most likely out of line with consumption, and what it is worth to put them right.
- Duration
- 12 to 15 minutes
- You receive
- Score, 7 dimensions, sector benchmark
- Price
- Free, no email needed
In shared services and GBS, the cost of serving one business unit can run two to three times another of the same size, because invoice volume, ticket complexity, exceptions and service mix land unevenly. Allocating cost by headcount or revenue makes heavy consumers look cheap and light ones look expensive, so the chargeback feels unfair and gets disputed. TDABC assigns each activity, an invoice processed, a hire onboarded, a ticket resolved, to the unit that consumed it, so every business unit pays for what it actually uses.
When bots clear the transactions, the chargeback has to follow.
AI and automation are moving straight into the work a shared services centre charges for: RPA clears high-volume transactions, AI agents absorb tier-1 tickets, and intelligent capture cuts the touch time on an invoice. That lowers the cost per activity and shifts the mix toward exceptions and judgement, which changes what a fair chargeback looks like. None of it can be valued without a cost-per-activity baseline first. The centres that win are the ones that already know their cost per transaction before automation rewrites it.
Proof
A distributor in New Zealand. €1.335M of cost-to-serve made visible, then halved, and 830 loss-making customers brought down to 295.
Read the case study →Who you would be talking to
Miguel Guimarães, Founding Partner
Cost and profitability practitioner for 25+ years. Lectured alongside Professor Robert S. Kaplan at the CFO conference in Amsterdam (2009).
Call +351 910 313 731
