IT Cost Allocation: A Practical Guide for Teams Arguing Over Laptops

By [Author Name] · [Date] · [X] min read · [Table of Contents]

TL;DR

• IT cost allocation splits hardware spend across the teams that caused it, instead of parking it all in one central budget.
• Under about 100 people, don't bother. The arithmetic tells nobody anything they didn't already know.
• It does three jobs: makes consumption visible, puts a cost against hiring, and stops one team quietly subsidising another.
• Four models exist: central, per head, actual cost, and a standard rate per role.
• Pick based on whether the manager being charged has a lever they can actually pull.
• Done right, a department head can reproduce their own number in under a minute without ringing finance.

A department head sees 43,000 against her team and asks what it is. It's laptops, monitors and docks issued to her people over three years, apportioned by a finance model she's never been shown, in a year when she hired 11 people and lost 4. She can't verify it. She can't influence it. And she's been told to cut it by ten per cent.

So she does the only thing available. She pushes back on the next hiring request's kit and asks whether the new starter really needs a new machine at all or whether one of the refurbished ones in the cupboard would do. The saving is about 400. The cost is a new employee on a slow laptop forming a view of the company in week one.

Recommended Tools

Best tools for HR Operations

B BambooHR HR management system R Rippling HR & IT automation W Workday Enterprise HRIS

View all recommended tools

The real issue isn't how the cost gets split. It's that the person being charged has no way to change it except by degrading something, so that's exactly what they degrade.

When You Don't Actually Need Cost Allocation

Stage one: central is genuinely correct. Under 100 people, the numbers are small enough that splitting them is a reporting exercise dressed up as financial control. It costs more in finance time than it ever surfaces in savings, and the differences between teams at that size usually sit inside the margin of error anyway. Leave it alone.

Stage two: friction appears. One team is consistently on high-specification machines and another is on the standard build, and somebody has noticed. That's the moment allocation starts earning its place, because an invisible subsidy has become a visible one and the conversation is already happening without any numbers in it.

Stage three: it becomes a liability. Nobody can say what a team costs, a budget round arrives, and hardware gets cut across the board because no one can defend any particular part of it. Blunt cuts are what you get when nobody has the numbers. The team that was already frugal takes the same ten per cent as the team that wasn't.

Stage four: the edge case. You run client-billable work and somebody needs to recover hardware cost against a project. That's a different requirement with different rules, and it usually needs actual cost per asset rather than any of the simpler models, because an invoice has to name the thing it is charging for.

What Finance and HR Actually Need from Allocation

> "Can I change this number?" > If the answer is no, stop charging. > A charge with no lever attached is just a tax, and it generates complaints and precisely zero decisions.

> "Why is my team dearer than theirs?" > Role mix, nine times out of ten. > The answer has to be available without a finance request, because if it isn't, people invent a worse explanation and then believe it.

> "What happens when somebody leaves?" > The charge should stop. Immediately. > Models that keep billing until an asset is fully depreciated teach managers that leavers cost money, and managers act on what they are taught.

> "Does hiring cost me extra?" > Yes, and the figure belongs in the headcount request. > Finding out two quarters later is exactly how allocation gets a reputation for ambushing people, and that reputation outlives any model you build.

> "Am I paying for things in a cupboard?" > You shouldn't be. Unissued stock is central. > This is the single most common cause of arguments about the model rather than the amount, and those are much harder to settle.

There's a sixth question that only comes up once you employ contractors, and nobody writes down the answer. Their hardware cost usually lands on whichever cost centre raised the engagement, and nobody checks. Contractor engagements end without a leaver process. Which means the kit stays issued in the system long after the person has gone, and a team ends up carrying a charge for a device belonging to somebody who stopped working there eight months ago.

The Four Types of Allocation Model

Central cost. What it is: IT holds the whole budget and nobody gets charged. When it's right: small teams, standardised builds, no real variation between groups. When it fails: slowly, which is the thing that makes it dangerous. Consumption drifts up because nothing anywhere creates pressure in the other direction, and by the time anybody looks closely it is a third higher than it was two years ago.

Per head. What it is: total divided by headcount, charged to each team on that basis. When it's right: a first attempt, because you can build it from data you already have in an afternoon. When it fails: it rewards having fewer people, which is not the behaviour anybody wants from a hiring manager, and it flattens the real differences. Designers cost more than the finance team. Per head says they don't.

Actual cost. What it is: each team pays what was really spent on its people. When it's right: client recovery, where somebody is being invoiced and wants the specific asset named on the specific bill. When it fails: everywhere else. It turns specification into a budget decision for a manager with a target to hit, and the predictable answer is cheaper machines bought a little more reluctantly each year.

Standard rate per role. What it is: a published monthly rate per role, charged per person, regardless of what was actually bought. When it's right: almost always, once you're past 100 people. When it fails: when nobody maintains the rate. It drifts from reality in about eighteen months and loses credibility the first time a manager sits down and does the arithmetic independently.

I've watched three companies try actual cost and move off it within two years. Every time for the same reason.

How to Choose: Five Questions Before You Build Anything

What does a team cost today? If you can't produce this per team for the last twelve months, that is job one and it might well end the discussion before it starts. The spread between teams is frequently far narrower than everybody assumes, and the whole argument turns out to be about 6,000 a year.

Who can actually change the number? List every decision that affects device cost and name who makes it. If most of them sit centrally, central cost is the honest answer no matter what anybody would prefer, and building a chargeback model on top of decisions nobody local controls just moves the complaints around.

How often does the rate need reviewing? Annually, against real actuals. If nobody will own that piece of work, your standard rate drifts quietly and the model loses its credibility the first time somebody checks it against what their team's machines actually cost.

What happens to spares and stock? Decide before launch rather than after. Unallocated hardware sitting on a team's line is the most common cause of disputes about the model itself, and a dispute about the method is far worse than a dispute about an amount.

Is this for fairness or for recovery? Decide that first. Internal fairness tolerates a standard rate perfectly well, because nobody is being billed externally and an approximation everybody understands beats an exact figure nobody can reproduce. Client recovery usually doesn't, because somebody is being invoiced and wants the actual asset on the actual invoice. Knowing which of the two you are doing settles most of the remaining design decisions on its own.

Six Platforms Worth Knowing

RemoAsset Best for: distributed teams that need a reliable record of who holds what, across borders. Why companies choose it: procurement and retrieval in 80+ countries with the device tracked through issue and return, which is the exact data every allocation model depends on and the exact data most companies discover they don't have. Pricing is published, from $1,499 a year on the Subscription tier for 50 to 5,000+ employees, with a 60 per cent cut on retrieval charges. It's our own product, so weigh that accordingly. Where it struggles: there's no network discovery, so it won't find hardware you forgot you owned, and a model built on an incomplete register allocates an incomplete cost. No software licence management either, which is the other half of most IT chargeback. And only the Subscription tier publishes a figure, with pay-as-you-go quoted instead. It isn't a finance system and it won't post a journal.

Workwize Best for: teams where unallocated stock is part of the dispute. Why companies choose it: own warehouses, so visibility covers kit in storage as well as kit in use. Where it struggles: no published rate card. The numbers on its pricing page are savings claims rather than prices, so you can't model it without a conversation first. Live domain is goworkwize.com now.

Firstbase Best for: fleets built from scratch rather than inherited. Why companies choose it: clean subscription shape, strong supply side. Where it struggles: publishes nothing on price. Supply-led model, which makes it a weaker system of record for equipment you already owned before you met them.

GroWrk Best for: companies wanting the service scoped around them. Why companies choose it: flexible arrangement, shaped to what you actually need rather than a fixed package. Where it struggles: no rate card. Its pricing page runs a competitor cost estimator and those figures are its own estimates rather than anybody's published prices, so don't carry one into a budget paper.

allwhere Best for: handing the whole thing over. Why companies choose it: managed service, minimal internal lift. Where it struggles: publishes nothing, so there's no way to compare before a conversation.

Deel IT Best for: companies already running employment through Deel. Why companies choose it: hardware and employment cost in one relationship, which genuinely does simplify allocation. Where it struggles: weaker standalone, no published pricing.

The Decision Table: Where Each Model Actually Fits

Most teams sit in two of these rows at once. Start with whichever one is currently generating meetings.

Allocate on Issue, Not on Purchase

This is the mechanical bit that causes more reconciliation grief than the choice of model does, and it is trivial to get right if you decide it at the start.

Batches are the problem. Hardware gets bought in bulk and issued one at a time. Allocate at purchase and whichever team happened to trigger a bulk order carries the entire batch, so the numbers never line up with headcount because what they are actually tracking is procurement events rather than people. The month a company buys 50 laptops, one department looks catastrophic and nobody can explain why.

Allocating at issue fixes it. Cost attaches when a device is given to a person, which is how managers already think about it anyway, and it reconciles against headcount without anybody having to do anything clever. Stock sitting in a box stays central, which is also correct, because nobody should be charged for a machine nobody is using.

The same logic runs in reverse. Somebody leaves, the device comes back, the charge stops. Models that keep billing until the asset is fully depreciated are the ones that quietly make leavers expensive, and managers work that out faster than anybody expects them to.

Internal moves need identical treatment. They almost never get it. A person transfers teams and takes their laptop with them, so the cost should follow them across. Where it doesn't, you accumulate a slow drift between where people actually are and where their kit is charged, and after two years of that the model is genuinely unexplainable to anybody who asks.

Setting the Rate Without Guessing

If a standard rate per role is where you land, the quality of that rate decides whether the model survives its first year. Set it badly and the first manager who checks will find it indefensible. Once is enough. That ends the conversation permanently, and you do not get a second attempt in the same financial year.

Use your own actuals. Not a vendor price list. Take the machines actually issued for each role group over the last two or three years, add the peripherals that genuinely go with them, and divide by the refresh period in months. A machine at 1,430 on a three-year cycle with 290 of peripherals works out at about 48 a month. That's a number somebody can check for themselves, which matters considerably more than whether it is exactly right.

Those are illustrative shapes rather than numbers to copy. The point is that the arithmetic is visible, and anybody can substitute their own figures and reach their own answer in about four minutes.

Decide explicitly what the rate covers, because every argument happens at the edges rather than in the middle. Monitor? Dock? Replacement when somebody drops it? Shipping to a new starter in another country? Retrieval when they leave? Each thing you exclude has to live somewhere else, so excluding items to make the headline rate look smaller just relocates the fight rather than ending it.

Most companies include hardware, peripherals, shipping and retrieval, and exclude accidental damage along with anything genuinely exceptional. That split works for a specific reason: the first group is predictable per head and the second isn't, and a standard rate is only useful for the predictable part.

Then sanity-check it. Rate times headcount should land near what you actually spent last year. Out by twenty per cent? Your role groups are wrong, or something significant is going uncounted somewhere in the process. Much cheaper to find that out now than when a department head does the same sum in front of an audience.

One refinement worth building in from the start: set rates by role group, never by seniority. A senior engineer and a junior engineer use the same machine. Grade is not a specification. Tying hardware to grade is how a laptop quietly becomes a perk, and that is a different conversation with a different set of problems attached to it.

Running the First Cycle in Parallel

Nobody should launch an allocation model straight into live budgets. Run it alongside for a quarter first, with the numbers produced and circulated and nothing at all hitting anybody's budget line.

The reason is specific. The first run always surfaces data problems rather than cost problems, and you want those surfaced while the stakes are still zero. Expect to find people holding kit nobody knew about, assets charged to teams whose holder left months ago, machines issued twice because a replacement was logged as a new issue, and at least one department whose number is wrong by enough to make somebody angry.

A parallel quarter costs almost nothing. Produce the report, send it to each department head with a short note saying this is not a bill, and ask one question: does this look roughly right to you? That question is worth more than any amount of internal reconciliation, because the manager knows who sits in their team and you do not.

What comes back is usually a mixture. Some corrections are real and fix the register. Some are managers pushing back on a number that happens to be correct, which is useful too, because it tells you where the explanation needs to be better before anything goes live.

Then publish the method before the first real charge. Not a finance document. One page saying what the rate is, what it covers, when the charge starts and stops, and who to ask if it looks wrong. Teams that skip this step spend their entire first year defending the method instead of discussing the spend, which is the worst possible use of the attention they have just acquired.

Who Sees the Number, and in What Form

A model nobody can read is a model nobody trusts, and most allocation work fails on presentation rather than on arithmetic.

Department heads need three things and no more: their total, the headcount it is based on, and the rate applied. That's it. If those three numbers are present, a manager can reproduce the figure in their head and will stop asking finance to explain it, which is the entire point of the exercise.

Skip the serial numbers. What they emphatically do not need is an asset-level breakdown. Hand somebody a 200-line list of serial numbers and you have guaranteed a week of queries about individual machines, none of which changes any decision anybody is going to make. Keep the asset detail available on request and out of the default report.

Finance needs the reconciliation: rate times headcount against actual spend, with the variance explained. That is where a drifting rate shows up first, usually a full year before anybody outside finance notices it.

And somebody senior needs the trend, which is the only view that answers the question the exercise was commissioned to answer. Is total device spend per head going up, down or sideways? One line, three years. Three years of that one line is worth more than any amount of departmental detail, because it is the number that tells you whether the model changed any behaviour at all.

Where Multi-Country Makes This Harder

Everything above assumes one currency and one set of prices. Across borders, three things break, and not one of them is obvious until the first report lands on somebody's desk.

Hardware costs differ by market, sometimes by thirty per cent for the identical specification, driven by local pricing, import duty and whatever the regional supplier had available that month. Charge actual cost and a team hiring in an expensive market looks worse than an identical team hiring somewhere cheaper. The manager controls neither. So the sensible answer is one global standard rate per role with the variance absorbed centrally, which is also far simpler to explain.

Shipping and retrieval are where the real variance sits, and they are frequently larger than the hardware difference. Getting a laptop to one country can cost a tenth of what it costs to reach another. Building that into a per-country rate produces a model where hiring in certain markets carries a visible penalty, and that is a strategy decision rather than a finance one. Keep it central and report it separately.

Ask locally. Then there is the question of what the entity structure demands, which is not a question anybody should answer from a template. Cross-border recharges between legal entities have requirements that vary by jurisdiction and by circumstance, so that part needs local advice every time rather than a policy written centrally and applied everywhere. The internal management view and whatever the entities require of each other are two different exercises, and conflating them is how a sensible internal model ends up producing numbers nobody can use for either purpose.

The Cost of Choosing the Wrong Model

The visible cost of a bad model is finance time, and honestly it is modest. Rebuilding one takes a few weeks of somebody's attention.

What's expensive is the behaviour it produces. Charge actual cost to a manager with a budget target and that manager learns to specify cheaper machines. Quickly, quietly, and permanently. The saving shows up as a line item somebody can point at. The cost shows up as slower work, more support tickets and new starters forming an opinion of the company in week one, and not one of those ever gets traced back to the model that caused it.

The second failure is that disputed numbers eat senior attention out of all proportion to the amount involved. A 43,000 line a department head cannot verify generates more meetings than a 400,000 line she can. Trustworthy beats accurate. Those two are not the same thing, and a model that is slightly wrong but reproducible survives far longer than one that is exactly right and completely opaque. A standard rate everybody understands wins comfortably against an exact figure nobody can reproduce.

Third is the slow one. Central cost with no visibility produces drift, because nothing in the system creates pressure in the other direction. Specifications creep, refresh cycles shorten, and the total grows at a rate nobody ever has to defend, right up until a bad year arrives and the whole thing gets cut at once.

So the diagnostic question is this. Are you solving a visibility problem, a behaviour problem, or a recovery problem? The answer changes which model you build, and most teams assume the second when what they have actually got is the first.

When Allocation Is the Wrong Fix Entirely

Worth saying plainly: a lot of allocation projects are solving something allocation doesn't touch. The tell is that somebody senior is unhappy about a total rather than about a distribution.

If the complaint is that device spend is too high, splitting it across teams doesn't reduce it by a penny. It makes it visible, which sometimes creates pressure, and that pressure lands on the people least able to act on it. The levers that genuinely move the total are the refresh cycle, the standard specification, the mix of new versus redeployed kit, and how much walks out of the business and never comes back. All four sit centrally. All four can be pulled without any allocation model at all.

If the complaint is that nobody knows what anything costs, the fix is reporting rather than charging. Publish, don't bill. Publish cost per team quarterly without putting it in anybody's budget and you get most of the visibility with none of the distortion. Plenty of companies run exactly this arrangement and call it allocation, which causes some confusion in conversations and produces perfectly decent outcomes anyway.

If the complaint is that one team is extravagant, deal with that team. Redesigning a model across the whole company to correct one department's behaviour is an expensive way to avoid a single conversation.

Allocation is genuinely right when three things are true at once: real and persistent differences between teams, managers with levers they can pull, and a genuine desire for them to pull those levers. Miss any one of the three and the honest answer is to publish the numbers and keep the budget central.

Knowing When to Retire the Model

Models get built and then nobody ever asks whether they are still earning their place. Put a review in the calendar at twelve months and actually hold it.

Three questions settle it. Did any decision change because of what a team was charged? Does anybody still dispute the numbers? And is the admin time it consumes smaller than whatever value the model is actually producing for the people who read its output every month?

If no decision changed in a year, you are running reporting with extra steps, and you can hand the admin time back and switch to publishing the numbers instead. That isn't a failure. It's a finding, and it is a considerably cheaper finding than carrying on for another year.

If disputes are still arriving in month eleven, the problem is the method rather than the amount, and a model nobody accepts after a year is not going to be accepted in year two. Rebuild it or retire it.

And if the company changed shape, the model has to change too. Shapes change quietly. A standard rate built for 200 people in two countries does not survive 600 people in nine. Nobody notices that, because the model keeps producing numbers either way, and those numbers keep looking entirely plausible right up until somebody checks one of them.

Three Things That Go Wrong in Year Two

Year one problems are data problems and everybody expects them. Year two is where the design errors surface, and they are quieter.

The rate stops matching anything. Nobody reviews it, hardware prices move, the standard build changes, and the published figure drifts away from what machines actually cost. It keeps producing numbers the whole time. That is what makes it dangerous: a rate that is forty per cent wrong looks exactly like a rate that is right, until a manager prices up their own team's laptops and discovers the gap. By then the model has lost the one thing it needed, which was the willingness of people to accept its output without arguing.

The fix is a diary entry and an owner. One person, once a year, comparing rate times headcount against actual spend and publishing the revision with a line explaining what moved. Fifteen minutes of work. The reason it does not happen is that nobody was ever named, and an unowned annual task is a task that happens twice and then stops.

Exceptions become the model. Somebody needs a machine outside the standard build, so it gets handled as a one-off. Then somebody else does. Within eighteen months a third of the fleet sits outside the role groups the rate was built on, the model covers the easy two thirds, and the interesting spend is all in the exceptions nobody is tracking.

I have seen this one more often than any other failure here, and it is always invisible while it happens. The signal to watch is the proportion of spend that falls outside a role group. Track that single percentage from the start. When it passes about fifteen per cent, the role groups are wrong and need rebuilding rather than patching, and rebuilding them is a day's work while patching them is permanent.

The model outlives its question. Allocation gets built because somebody senior asked what teams cost. That person leaves, or the question gets answered, and the machinery carries on producing reports nobody reads and charges nobody examines. The admin cost continues. The value stopped some time ago and nobody noticed, because reports arriving on time look like reports being used.

So hold the review. That is why the twelve-month check matters more than the build itself. A model that nobody has questioned in two years is not a stable model. It is an unexamined one, and those are the ones that produce a number somebody acts on without knowing it has been wrong since the second year.

What to Do If You Inherit Somebody Else's Model

Most people reading this will not be building from scratch. They will have walked into something, and the honest first step is to work out what they have got rather than replacing it on instinct.

Four questions, and they take about half a day between them.

What model is this actually? Not what the documentation claims. Take one team's charge and reproduce it from first principles. If you can't, that tells you something important before you change anything, and it is usually that two models were layered on top of each other during a reorganisation and neither was retired.

When was the rate last reviewed? Find the date. No date means no review, and no review means the figure is historical rather than current. Work out how far off it is before deciding whether the model is broken or just stale, because a stale model with a good design is a cheap fix and a broken design is not.

Who disputes it? Ask three department heads whether they believe their number. Their answers will be more useful than any amount of reconciliation work, because they know who sits in their teams and whether the kit on their line matches the people in front of them.

What decisions has it changed? If the answer is none, you are looking at reporting with a billing layer bolted on, and the cheapest improvement available is to remove the billing layer and keep the reporting. That is a smaller, better change than redesigning the model, and it will be unpopular with whoever built it.

Only after those four would I touch anything. An inherited model usually has one real defect rather than many, and finding which one it is costs considerably less than a rebuild.

When You're Ready to Move Beyond the Spreadsheet

You'll know. The signal isn't headcount, it's that three people maintain three different views of what the company owns and none of them reconciles with the others. Add a budget round on top and the gap between those views is the only thing standing between you and a number you can defend in the room.

Fleet size is not the signal. The thing that usually tips a company over is not how many machines it owns. It is the first time somebody asks a question about hardware cost that takes three days to answer, and the three days are spent reconciling spreadsheets rather than thinking about the answer. That is the point at which the register stops being an administrative detail and starts being the thing every number downstream depends on.

RemoAsset sits where the record matters more than the arithmetic: kit going out, coming back, crossing borders, with one place that knows who holds what and since when. That's the maturity curve it fits, and it's our own product so weigh it accordingly.

If that's roughly where you've ended up, it's worth a closer look.

Frequently Asked Questions

Know what every team actually costs in hardware, without anybody having to ask finance.