IT chargeback is usually introduced to make consumption visible. What it also does is turn an infrastructure team into a billing function, and the administrative cost of that’s almost never estimated before the decision is made.
TL;DR
- Chargeback only changes behaviour where the person being charged has a lever. Everything else is accounting with extra steps.
- Charge few things, charge them simply, and absorb the rest centrally.
- Per-device charging generates the most queries and the least useful behaviour change.
- The admin cost is real: expect queries, disputes and a monthly reconciliation nobody budgeted for.
- Automate the data or do not do it. Manual chargeback decays within two quarters.
- Review what changed after a year. If no decision moved, switch to reporting and keep the budget central.
What chargeback is for
There are three reasons organisations introduce it and they want different designs.
Visibility. Somebody senior wants to know what each team consumes. This needs reporting rather than charging, and the two get conflated so constantly that most chargeback projects are really visibility projects wearing the wrong clothes.
Behaviour. You want teams to consume less or choose differently. This needs charging, and it only works where the team being charged has a genuine choice it could make differently next month.
Recovery. Costs need to land on a project or a client. This needs actual cost per item and it is by some distance the most administratively expensive of the three to run.
Being clear which one you’re doing settles most of the design arguments before they start.
Charge few things
The common failure is charging for everything on the theory that it is fairer. It isn’t fairer in any way that matters, and it multiplies the query volume by the number of line items.
Pick two or three. The largest and most variable costs are the only ones worth itemising, because everything smaller costs more to apportion than it ever reveals. For most teams that’s per-person software licences, device cost, and whatever your largest cloud or platform spend is. Everything else, including support time, small peripherals and shared infrastructure, is better absorbed centrally than itemised.
Support time in particular should almost never be charged. Billing a team for raising tickets teaches them not to raise tickets, which is the opposite of what any service desk wants, and the resulting silence is read as improved efficiency for about six months.
The admin cost nobody models
Chargeback produces three recurring workloads and all three land on the team running it.
The first is the monthly reconciliation. Whatever system produces the numbers will disagree with finance, and someone has to resolve it before anything is posted.
The second is queries. Expect one per cost centre in the first month and a steady trickle thereafter, each taking twenty minutes to answer properly. A published page explaining the method removes most of them, which is why it is worth more than it looks.
The third is disputes, which differ from queries in that somebody wants the number changed. These need a decision route that isn’t the person who produced the number, or the IT team ends up adjudicating its own billing.
What to do:
- Estimate the monthly admin hours before committing, not after.
- Publish the method on one page and link it on every report.
- Name someone outside IT to settle disputes.
- Automate the data extract or restrict the scope until you can.
- Agree a cut-off date each month and hold it.
A team that halved the work
A company of about two hundred charged back eleven line items, assembled monthly from four systems by one person over roughly two days.
Reviewing a year of queries showed that 9 of the 11 lines had generated no questions and no behaviour change. They were small, stable and identical across teams, which meant they were being itemised for no reason other than completeness.
Collapsing those nine into a single per-head platform charge cut the assembly to half a day and removed nothing anybody used. The two lines that stayed itemised were the two with genuine variation between teams, which were also the only two where anyone had ever changed a decision.
Devices are the awkward line
Hardware is the item most likely to be charged per device and the item where that works least well.
The reason is that device cost arrives in lumps. A machine is bought once, used for three or four years, and depreciated, so a per-device charge either tracks depreciation, which nobody outside finance understands, or tracks purchase, which makes one month look catastrophic for whichever team happened to trigger an order.
A flat monthly rate per person by role avoids both. It’s predictable, it can be forecast against headcount, and it decouples the specification decision from the budget decision, which stops managers requesting cheaper machines to protect their own numbers.
Whatever you choose, charge from issue and stop at return. Charging until an asset is fully depreciated means a team keeps paying for somebody who left, which is both unfair and a poor incentive.
Where the data comes from
Chargeback is only as good as the record of who has what, and that record is the thing most teams find is weaker than they assumed.
RemoAsset is our own product, and its relevance here is narrow: because it handles procurement and retrieval across 80+ countries and records each device through issue and return, it supplies the holder-and-date data a device charge depends on. Pricing is published, with the Subscription tier from $1,499 a year for companies with 50 to 5,000+ employees, including a 60 per cent reduction on retrieval charges.
Its limits matter. It has no network discovery, so it won’t find hardware you forgot you owned. It has no software licence management, which is the other half of most chargeback models. And only the Subscription tier publishes a figure, with the pay-as-you-go tier quoted. It isn’t a billing system and it posts nothing to a ledger, so the export still has to reach finance by some other route.
Workwize, Firstbase, GroWrk, allwhere and Deel IT occupy the same space and none publishes a rate card. The live Workwize domain is goworkwize.com.
What to charge and what to absorb
| Cost | Charge? | Why |
|---|---|---|
| Per-person software licences | Yes | Varies by team, team can influence it |
| Devices | Yes, flat rate by role | Predictable per head, lumpy per asset |
| Large cloud or platform spend | Yes, if attributable | Real variation, real levers |
| Support and service desk time | No | Charging it suppresses tickets |
| Shared infrastructure | No | Nobody can influence their share |
| Small peripherals | No | Admin exceeds the amount |
The checklist worth keeping
Checklist:
- Three or fewer charged lines.
- A published method page, linked from every report.
- Device charge is a flat rate per role, from issue to return.
- Support time is absorbed, not billed.
- Disputes are settled by somebody outside IT.
- The data extract is automated.
- An annual review asks what decision actually changed.
Final Thoughts
Chargeback is worth doing where teams have genuine choices and real differences in what they consume. Everywhere else it produces administration, queries and resentment while changing nothing, and the team that pays for that’s the one running it.
Charge three things, publish the method, automate the data, and check after a year whether anybody made a different decision because of it. If nobody did, switch to reporting and give the hours back.
Frequently asked questions
What is IT chargeback?
Teams get billed internally. It’s the practice of charging them for the technology they consume rather than holding the whole cost in one central budget. It differs from showback, which reports the same numbers without moving any money. Chargeback is intended to change behaviour and only does so where the teams being charged have a genuine decision they can make differently.
Should we charge for support tickets?
Almost never. Billing a team for contacting the service desk teaches people to avoid contacting it, and the resulting drop in ticket volume looks like an improvement for several months before the consequences surface as unreported problems and workarounds. Absorb support centrally and charge for things where reduced consumption is genuinely the goal.
How many line items should we charge?
Two or three. Each additional line multiplies the monthly assembly work and the query volume while rarely adding useful information, because small costs that are identical across teams carry no signal. Collapse everything stable and uniform into a single per-head charge and itemise only what genuinely varies.
Why is charging per device a problem?
Because hardware cost arrives in lumps rather than evenly. Charging at purchase makes one month look terrible for whichever team triggered an order, and charging depreciation produces numbers that are accurate and that nobody outside finance can interpret. A flat monthly rate per role is predictable, forecastable and avoids both failures.
How much administration should we expect?
More than estimated, and concentrated in three places: a monthly reconciliation against finance, queries from cost centre owners, and disputes where somebody wants a number changed. A published method page removes most queries. Automating the data extract is what decides whether the model survives, because manual assembly reliably decays within two quarters.
How do we know if it is working?
Wait a year. Then ask whether any decision actually changed as a result. Not whether the reports were produced or the numbers were accurate, but whether a team chose differently because of what it was charged. If nothing changed, you’re running reporting with extra steps, and moving to showback keeps the visibility while returning the administrative time.
