TL;DR
- The device budget usually sits wherever it landed when the company was small, and almost nobody has revisited it since.
- If one person approves all hardware spend and nothing stalls, you do not have this problem. Leave it alone.
- IT optimises for fleet consistency, security and support load. HR optimises for the employee experience and the hiring commitment. Both are right and they pull apart.
- The argument almost never happens over the standard laptop. It happens over the exception, the leaver's machine and the new market.
- The split that works is IT owning the specification and the spend, HR owning the entitlement and the trigger.
- Whoever owns the budget must also own the recovery rate, or the money and the consequences sit in different places.
The Laptop Nobody Would Pay For
A 300-person company hired a designer in a market where it had two other people. The role needed a considerably more capable machine than the standard issue, which the hiring manager had agreed during the offer process because it was obviously necessary.
The order stalled for three weeks. IT's hardware budget was set annually from a headcount forecast at the standard specification, and an exception of that size needed approval it had not been given. HR's budget covered recruitment and onboarding and had never included equipment, because equipment had always been IT's. The hiring manager's own budget had no line for hardware at all. Everybody agreed the machine was needed. Nobody could buy it.
It was eventually resolved by a director approving it as a one-off, which is how all of these are resolved, and the designer started two weeks late with a borrowed machine. The disagreement was not about money, since the sum was small and everybody agreed it was justified. It was that the commitment had been made by one function and the budget sat in another, and no process connected them. The same company repeated the pattern four more times that year.
Best tools for Device Management
So the question is less about who should hold the money than about which decisions the holder has to be able to make.
When You Don't Need to Decide This
When the manual way is genuinely fine
Under about a hundred people, with one approver who sees everything and says yes quickly. Formalising ownership at this scale adds a process and removes the speed that makes it work. The signal to revisit is the first time somebody waits more than a few days for an obvious decision.
When friction starts appearing
An exception takes longer to approve than the device takes to arrive. That is the clearest early indicator, and it usually shows up around a senior hire or a specialist role rather than in the ordinary flow.
When it becomes a liability
When the ownership gap starts shaping outcomes rather than just slowing them. A hiring manager who quietly recruits for the role that fits the standard machine, or a team that stops asking for what it needs, is a budget structure making product and hiring decisions.
The edge case that forces it
A new market, where every assumption about standard cost breaks at once. Local purchase, shipping, import charges and a different support arrangement all arrive together, and none of them is in anybody's annual plan.
Five Questions People Ask First
"Does it actually matter where it sits?" Less than the arguments suggest, and what matters a great deal is whether the owner can decide quickly and whether they carry the consequences. A budget held by somebody who cannot approve an exception is worse than either alternative, because it creates the appearance of ownership without the substance.
"Is this not obviously IT?" IT is the common answer and a reasonable default, because IT holds the specification, the support load and the register. The complication is that the commitment is frequently made by somebody else, in an offer conversation, before IT has any visibility.
"Why would HR own hardware?" Because in a distributed company a laptop is part of what you promised somebody when they joined, and HR owns the joining process end to end. Where companies have moved it, this is usually why. It tends to work less well on the specification side, which is a genuinely technical question.
"What about the manager's budget?" Devolving hardware to team budgets is intuitive and produces a fragmented fleet, inconsistent entitlements between teams doing the same work, and a support function with no visibility of what is coming. It is the arrangement most likely to be regretted.
"Who owns the recovery rate?" Almost always nobody, and this is the question worth asking loudest. If the budget sits with IT and the offboarding conversation sits with HR, then the money is in one place and the ability to influence returns is in another, which is how a write-off becomes everybody's problem and nobody's metric.
What Each Owner Optimises For
IT optimising
Fleet consistency, because eleven configurations cost more to support than three. Security posture, because an unmanaged or ageing device is exposure. Predictable support load. And the register, since IT carries the consequence of not knowing what exists.
These are real and they produce a bias towards standardisation and towards saying no to exceptions, which is correct in aggregate and occasionally wrong in the specific case that matters.
HR optimising
The employee experience, especially the first week, which is the most visible and most repeated moment in the relationship. Keeping commitments made during hiring. Equity between people doing similar work in different places. And the hiring outcome itself, since equipment is part of the offer in practice if not on paper.
Also real, and they produce a bias towards saying yes to the individual case and towards treating hardware as an employment cost rather than an infrastructure one.
Finance optimising
Predictability above almost everything, and a preference for the structure that makes the annual number forecastable. Finance rarely wants to own this and frequently determines where it sits, by deciding which cost centre the spend lands in.
The useful observation is that none of these three is wrong. The arrangement fails when one of them holds the money and another holds the decision.
The Four Ownership Models
| Model | Who holds the budget | Works when | Fails when |
|---|---|---|---|
| IT owns everything | IT, by headcount forecast | Standard fleet, few exceptions, IT can approve quickly | A commitment is made elsewhere, which IT then has to fund or refuse |
| HR owns everything | HR, as an employment cost | Distributed company where equipment is part of the offer | Specification decisions need technical judgement HR does not hold |
| Split: IT specifies, HR triggers | IT, with HR authorising the headcount | Most companies above about 150 people | Nobody owns the exception, unless it is named explicitly |
| Devolved to teams | Each manager | Small, uniform, co-located | Almost immediately at any scale. Fragmented fleet, inconsistent entitlement |
The third is where most companies end up and it is the right destination. The failure mode within it is specific and avoidable: the exception has no owner, which is the opening example.
Where the Money Actually Sits Today
Before deciding where it should sit, find out where it is, which is less obvious than it sounds and takes an afternoon.
Pull last year's actual hardware spend by cost centre. Not the budget, the spend. Most companies discover it is in three or four places: an IT capital line, an operations line holding the shipping, something in a regional cost centre, and a handful of expense claims from people who bought their own.
Find the expense claims specifically. They are the signal that the process failed, and the count matters more than the value. Eleven claims in a year means eleven occasions when the proper route did not work.
Check who approved the exceptions. If the answer is a director each time, the delegated authority is set too low, and that is a five-minute fix with a disproportionate effect.
Identify where shipping is booked. Almost always separate from hardware, frequently in general postage, and it is a material cost for a distributed company. A budget owner who does not see the shipping is not seeing the real cost of their decisions.
And find out who, if anybody, is accountable for the write-offs. Usually the answer is that unrecovered devices are absorbed somewhere without anybody owning the number.
The Decisions That Expose the Gap
Ownership only matters at the points where somebody must decide. There are six, and a workable arrangement names an owner for each.
The standard specification. What a normal person gets. Technical, and it belongs with IT. Write it as a specification rather than a model list, so it survives a supplier substitution in a market you buy in rarely.
The entitlement by role. Who gets more than standard, and on what basis. This is a people decision dressed as a technical one, and it belongs with HR in consultation with IT. The consultation matters, because an entitlement set without technical input tends to describe outcomes rather than hardware and becomes unbuyable.
The individual exception. This specific person needs this specific thing. The one that stalls, and it needs a named approver with a stated limit below which they do not escalate. Every company has these and the number is smaller than anybody fears, usually a handful a quarter.
The refresh trigger. When a working machine gets replaced. Mostly IT, because it depends on support data, and it has an equity dimension that benefits from HR's view.
The new market. What people get in a country where the standard does not exist. Needs somebody who can make a decision without an annual plan to refer to. Decide who that is before the first hire rather than during it, since the decision is easy in advance and contested under time pressure.
The write-off. What happens when a device does not come back. Must sit with whoever can influence the return, which means it should sit with whoever owns offboarding. Reported in money rather than as a rate, because a percentage in a report has never changed anybody behaviour.
The Split That Works
For most companies above roughly 150 people, the arrangement that holds up is straightforward.
IT owns the specification, the supplier relationship and the spend. They hold the budget, they buy, and they are accountable for fleet consistency and for the register. This keeps the technical decision with the technical team and keeps purchasing in one place.
HR owns the entitlement and the trigger. What each role is due, and the signal that a device is needed, which comes from the hiring process they already run. They do not choose the model and they do determine who qualifies for what.
The exception has a named approver with a standing limit. Somebody, usually the IT lead, can approve up to a stated amount without escalation. This single provision resolves the opening example entirely, and it is the part most often missing.
The write-off sits with whoever owns offboarding, reported monthly in money rather than in percentage, so the cost of a poor recovery rate lands where the recovery behaviour is.
Finance sees the total. One view across hardware, shipping and write-offs, regardless of how many cost centres they sit in, because the aggregate is the only number that describes the real cost.
Setting the Standing Limit
The named approver with a standing limit is the single highest-return change in this article, and the limit itself is usually set badly or not at all. Four considerations.
Set it above the ordinary exception, not at it. Look at the last twelve months of approved exceptions and find the value that covers around nine in ten of them. A limit that catches half the cases still routes half to escalation, which means the delay persists for a coin flip of requests and the arrangement feels unchanged.
Set it per device, not per month. A monthly cap turns into a queue at the end of each period and creates a reason to defer a request into next month, which is the opposite of the intended effect.
Give it to somebody who is reliably available. Authority held by a person in back-to-back meetings is authority that still produces delay. The deputy matters as much as the principal, and both should be named in the same sentence.
Review the exception rate quarterly rather than each case. The reason finance resists a standing limit is loss of visibility, and the answer is reporting rather than approval. A quarterly summary of exceptions, their values and their reasons gives finance more insight than approving each one individually ever did, because it shows the pattern rather than a series of unrelated requests.
The objection you will hear is that a standing limit invites overspend. In practice the exceptions were all approved anyway, after a delay, by somebody more senior who had less context. The limit does not change the spend; it changes who spends their time on it and how long the person waiting has to wait.
How to Choose: Five Questions Before You Talk to Any Vendor
Who can approve an exception today, and how long does it take? If the answer involves a director, you have found the problem before examining anything else.
Is shipping visible to the budget owner? For a distributed company this is a large fraction of the real cost and it is almost always booked elsewhere.
Does anybody own the recovery rate in money terms? Not as a percentage in an IT report, but as a figure somebody is accountable for.
Are entitlements written down by role? An unwritten entitlement is decided case by case, which produces inconsistency that looks like favouritism and generates most of the escalations.
Who decides in a new market? If the answer is that it has not come up, it will, and deciding in advance costs nothing.
What the Tooling Decision Follows
Ownership determines which tools make sense, which is why this question comes before the procurement one. Figures below were read from each vendor's own pricing page, most recently 9 October 2026.
Where IT owns it
A register is the priority, because IT carries the consequence of not knowing what exists, and a budget owner specifically needs purchase cost, purchase date and assignment in one place.
Snipe-IT self-hosted is free and open source and holds all three. Its hosted tiers are published at $39.99 monthly or $399.99 annually for Basic, and $99.99 or $999.99 for Small Business.
AssetTiger is the hosted alternative, priced by asset count at $20 a month for 500 assets, $40 for 2,500 and $75 for 10,000, reducing to $18, $37 and $69 respectively on annual billing, with unlimited users on every paid plan.
Where HR owns the trigger
The integration that matters is between the HRIS and whatever issues devices, so that a hire or a leaver generates an action without anybody remembering. This is a workflow question rather than an asset one, and Freshservice covers it at $19, $49 and $99 per agent per month with onboarding templates, though its per-agent pricing suits companies with a service desk rather than those without.
Where the split is the problem
Platforms that execute procurement, delivery and recovery reduce the number of decisions that need an owner at all, because the process runs without per-case intervention. Workwize, Deel IT, Firstbase, GroWrk and allwhere all do versions of this and none publishes a price.
RemoAsset
Disclosure: RemoAsset is owned by the same people who publish HROpsLab. It appears here because it competes in this category and is assessed against the same criteria as everything else on this page, with its limitations stated in the same detail.
Relevant to this question specifically because offboarding in the HRIS triggers the return directly, which puts the recovery action next to the HR event that causes it rather than in a separate IT queue. That addresses the sixth decision above, which is the one most commonly unowned.
Where it struggles: it publishes no price and requires a demo, so it cannot be evaluated against a budget before a sales conversation. It is weaker for hardware it did not supply. And it is not a certified disposal vendor.
The Comparison
| Tool | Serves which owner | Publishes a price | Free option |
|---|---|---|---|
| Snipe-IT | IT, as the register | Yes | Yes, self-hosted |
| AssetTiger | IT, as the register | Yes | No, 30-day trial only |
| Freshservice | HR trigger into an IT workflow | Yes, per agent | No |
| Workwize, Deel IT, Firstbase, GroWrk, allwhere | Reduces decisions needing an owner | No | No |
| RemoAsset | Connects the HR event to the device action | No, demo required | No |
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| One approver, nothing stalls | Under 100 | Leave it alone | None | Do not formalise. Revisit at the first delay |
| Exceptions take longer than delivery | 100 to 500 | Named approver with a standing limit | Commitment made in one function, budget in another | Set the limit. It is a five-minute fix |
| Hardware spend in four cost centres | Any | One consolidated view for finance | Nobody sees the total | Pull actual spend by cost centre before changing anything |
| Expense claims for self-bought laptops | Any | Fix the route, not the policy | The proper process did not work | Count the claims. Each one is a process failure |
| Write-offs absorbed by nobody | Any | Assign them to offboarding owner | Money and influence in different places | Report write-offs monthly in money |
| Entitlements decided case by case | Any | Written entitlement by role | Inconsistency reads as favouritism | Write them down, even roughly |
| Opening a new market | Any | Named decision-maker, no annual plan | Every standard assumption breaks at once | Decide who decides, before it comes up |
Writing Entitlements Down
An unwritten entitlement is decided case by case, and case-by-case decisions made by different people over two years produce inconsistency that looks, to the people affected, like favouritism. Writing them down takes an afternoon and removes most of the escalations.
Keep it to three or four tiers, not a matrix by job title. Standard, a higher tier for roles with a genuine technical requirement, and perhaps one more for a small number of specialist cases. A document with nineteen role-specific entitlements is one nobody maintains and everybody argues with.
Define the tiers by what the work needs, not by seniority. This is the choice that determines whether the document reads as fair. A specification tied to what a role actually does is defensible to anybody; one tied to grade invites a conversation about status that has nothing to do with hardware.
Say what is included beyond the machine. Monitor, keyboard, headset, desk allowance if there is one. Most disputes are about the peripherals rather than the laptop, because the laptop entitlement is usually obvious and the rest has never been stated.
State the exception route in the same document. Who to ask, what information to provide, and what the expected turnaround is. An entitlement document that only describes the standard case pushes every edge case into an ad hoc conversation.
And review it annually against what people actually received. If a third of orders in a year were exceptions, the standard is wrong rather than the requests being unreasonable, and the document should move rather than the approvals tightening.
One thing to resist: publishing entitlements by individual rather than by role. The intent is transparency and the effect is a comparison exercise, since people will read the list for who has more rather than for what they themselves are due.
Making the Handover Work
If you are moving ownership, three things determine whether it sticks.
Move the money and the authority together. A budget transferred without the authority to approve exceptions recreates the original problem under a new name, and the new owner will be blamed for delays they cannot prevent. This is the most common way a well-intentioned reorganisation of this leaves everybody worse off.
Give the new owner the data. Fleet age distribution, spend by category including shipping, recovery rate, and the exception history. Without these they are making decisions on instinct for at least two quarters. The exception history is the most useful of the four and the one least likely to exist in any retrievable form, so reconstruct it from approvals before the handover rather than afterwards.
Agree the escalation path in advance. There will be cases above the standing limit and they should have a known route rather than becoming an improvisation each time. Name the escalation approver and a response expectation, since an escalation route with no timescale is the delay you were trying to remove, relocated.
And announce it. Hiring managers need to know who to ask. A change of ownership that is not communicated means requests continue arriving at the old owner, who no longer has budget, which is strictly worse than before.
Expect a transition period of about a quarter in which both routes are used, and plan for it rather than treating it as non-compliance. The old owner should forward rather than refuse, and should say where the request has gone, because a request bounced back to a hiring manager with no onward direction is how people conclude the new arrangement is worse and start buying laptops on cards. After a quarter, review what still arrives at the old address and fix the documentation that sent it there.
The Conversation to Have With Finance
Ownership changes need finance to agree, and the case lands better when it is framed as visibility rather than as a request for autonomy.
Lead with the total, not the structure. Show last year's actual hardware spend consolidated across every cost centre it touched, including shipping and write-offs. For most companies this is the first time anybody has seen the number in one place, and it reframes the discussion from a departmental boundary dispute into a question about a cost nobody was tracking.
Show the delay cost alongside it. Days of new starters unable to work, and the count of exceptions that escalated. Finance responds to the second number more than people expect, because escalations consume senior time that is more expensive than the devices.
Propose the standing limit as a control, not a relaxation. It replaces ad hoc director approvals, which leave no record, with a delegated authority that produces a quarterly report. That is genuinely more control than the status quo, and presenting it that way is both accurate and more persuasive.
Offer the quarterly exception review as the trade. Finance gives up case-by-case approval and receives a pattern they can act on. This is the exchange that makes the arrangement acceptable, and omitting it is why these proposals usually fail.
And ask for one consolidated view rather than a cost centre move. Moving budget between departments is politically expensive and frequently unnecessary. A reporting view that aggregates hardware, shipping and write-offs across wherever they sit achieves most of the benefit without anybody losing a line.
Measuring It
Four numbers that tell you whether the arrangement is working, none of which is the budget variance.
Days from request to approval, separated from days to delivery. Approval delay is the ownership problem; delivery delay is a logistics problem, and conflating them hides which one you have. Most companies report only the combined figure, which is why ownership problems get mistaken for supplier problems and solved by changing supplier.
Exceptions as a proportion of orders. A rising rate means the standard specification no longer matches what people need, which is a specification problem rather than a discipline problem. Treating it as a discipline problem, by tightening approvals, produces more escalations and the same hardware at the end of a longer process.
Self-purchased devices claimed on expenses. Each one is a route failure. The count matters more than the value. Ask the three most recent claimants why they went around the process, since the answer is usually specific and fixable rather than cultural.
Write-off value, monthly. In money, reported to whoever owns offboarding. A percentage in an IT report changes nobody's behaviour.
Forecasting the Number
Whoever owns the budget has to forecast it, and hardware is forecast badly almost everywhere because it is treated as a function of headcount alone. Five inputs produce a figure that survives the year.
New joiners, by market. Not a total. A joiner in your home market and a joiner in a country you ship to cost materially different amounts once delivery and any import charges are counted, and a single blended figure will be wrong in both directions.
Refresh volume from the age distribution. The machines crossing your threshold during the year, which you can count exactly today. This is the most forecastable line in the whole budget and the one most often estimated.
Failure replacements from last year's rate. Historic failures as a proportion of the fleet, applied forward. Stable enough to rely on, and it rises as the fleet ages, so use the rate from a fleet of similar age rather than from three years ago.
Exceptions at the observed rate. If one order in eight was an exception last year, budget for one in eight. Forecasting zero exceptions guarantees the overspend conversation.
Write-offs at the current recovery rate. The uncomfortable line, and it belongs in the forecast rather than being absorbed as a surprise. Including it is also the most effective way to get the recovery work funded, because it makes the cost of not doing it explicit in a document finance reads.
What ruins these forecasts is almost never the hardware price. It is headcount landing in different markets than planned, which changes the shipping and import components far more than the device component. So forecast by market and keep the per-market figures separate, which costs nothing and means a change in hiring geography produces an adjustment rather than a variance.
What Getting This Wrong Costs
The direct cost is delay, and it is measured in the days a new starter cannot work and the weeks an exception waits. Across a year of hiring this is a real number and it is rarely attributed to the budget structure.
The second cost is the shadow process. When the proper route is slow, people route around it: a manager buys a laptop on a card, somebody expenses one, a team keeps its own small stock. Each is individually reasonable and collectively produces a fleet nobody can account for, which is the same fragmentation the devolved model produces, arrived at accidentally.
The third is the decisions that quietly change. A hiring manager who has waited three weeks twice begins to scope roles around the standard machine, or to hire where equipment is easy rather than where the candidate is. That is a procurement structure shaping who the company employs, and it appears in no report at all.
The fourth cost is the one that falls on the people doing the asking. A hiring manager who has had two requests stall learns to pre-negotiate, to ask for more than is needed in case it is cut, or to stop asking and let somebody work on an inadequate machine. None of those behaviours is unreasonable given the evidence available to them, and all three make the next budget cycle harder to forecast, because the requests stop reflecting what is actually needed. A process that teaches people to game it loses the information it was supposed to collect.
So the question worth asking is not whether IT or HR should hold the budget. It is who can approve an exception this afternoon, and whether anybody is accountable for the devices that never come back.
When You're Ready to Move Beyond Whoever Has Budget Left
Most companies did not decide this. The device budget sits where it sat when there were forty people and one person bought everything, and it has been inherited twice since without anybody asking whether the arrangement still fits.
What makes it stop fitting is distance, in two senses. Geographic distance, which makes every assumption about standard cost unreliable and introduces shipping and import charges nobody budgeted. And organisational distance, which separates the person making the commitment from the person holding the money, so that an obviously correct decision needs three conversations.
The sequence is short and mostly administrative. Pull last year's actual hardware spend by cost centre and find the expense claims, because they mark where the process failed. Name an approver for exceptions with a standing limit high enough to cover the ordinary case. Write the entitlements down by role, even roughly. Assign the write-off number to whoever owns offboarding and report it in money monthly. Then give finance one view of the total across hardware, shipping and write-offs. None of that moves a budget anywhere, and in most companies it resolves the problem that moving the budget was supposed to solve.
Frequently Asked Questions
Should IT or HR own the device budget?
For most companies above roughly 150 people the arrangement that works is a split: IT owns the specification, the supplier relationship and the spend, while HR owns the entitlement by role and the trigger that says a device is needed. The location of the money matters less than two other things, which are whether the owner can approve an exception quickly and whether they carry the consequences of their decisions. A budget held by somebody who cannot approve an exception is worse than either alternative.
Why do device purchases stall even when everybody agrees?
Because the commitment is usually made in one function and the budget sits in another, with no process connecting them. A hiring manager agrees during an offer conversation that a role needs a more capable machine, IT's budget was set from a headcount forecast at standard specification, and HR's budget has never included equipment. Everybody agrees the machine is needed and nobody has the authority to buy it, which is resolved by escalation every time.
What is the single fix that resolves most of these delays?
Naming an approver with a standing limit they can authorise without escalation. Most stalled device decisions involve sums small enough that a director's time is worth more than the difference, and the delay exists purely because delegated authority was set too low or never set at all. Pull your exception history, see who approved each one, and if the answer is a director every time, the limit is wrong.
Should team managers hold their own hardware budgets?
Generally no, and it is the arrangement most likely to be regretted. Devolving to teams produces a fragmented fleet that costs more to support, inconsistent entitlements between people doing the same work in different teams, and a support function with no visibility of what is arriving. It is intuitive because it puts the money near the decision, and it trades away the two things that make a fleet manageable.
Who should be accountable for devices that are never returned?
Whoever owns offboarding, because the money needs to sit with the person who can influence the behaviour. The common arrangement puts the budget with IT and the leaving conversation with HR, so the cost lands in one place and the ability to affect it in another, which is why unrecovered devices tend to be absorbed by nobody. Report the figure monthly in money rather than as a percentage in an IT report, since percentages change nobody's behaviour.
How do we find out where hardware money is actually being spent?
Pull last year's actual spend rather than the budget, broken down by cost centre, and expect to find it in three or four places including an IT line, an operations line holding shipping, something regional and a handful of expense claims. The expense claims are the most informative item, since each one marks an occasion when the proper route did not work, and the count matters more than the value. Check where shipping is booked too, because it is frequently in general postage and invisible to whoever owns the hardware decisions.
What changes when we open a new market?
Every assumption behind a standard cost breaks at once: local purchase prices differ, shipping and any import charges appear, warranty and support arrangements change, and none of it is in the annual plan. The practical requirement is somebody with the authority to decide without a plan to refer to, agreed before the first hire rather than during it. Deciding who that is costs nothing in advance and is the difference between a two-day decision and a three-week one.
HROpsLab takes no vendor money and publishes no paid placements, which is why the owner's own product appears here against the one decision it genuinely addresses rather than as a general recommendation.