IT Capex: A Practical Guide for Teams Deciding What to Own and What to Rent

TL;DR

• IT capex is capital spending on technology you own: machines, infrastructure, anything held on the balance sheet and written down over time.
• You do not need to think about this while hardware spend is small enough that nobody asks which budget it came from.
• The choice between owning and renting is a cash flow and accounting decision first. It is a cost decision second, and often not a cost saving at all.
• Past roughly three years of ownership, buying almost always wins on total cost. Under two, renting frequently does.
• The thing that goes wrong is not the arithmetic. It is that nobody wrote down which budget triggers at which threshold, so every purchase gets escalated.
• Vendors in this space rarely publish rates, so the comparison is between quotes you have to construct yourself.

The Approval Nobody Could Give

A company of about a hundred and twenty people needs to replace forty laptops that are coming up to four years old. The IT lead builds a sensible case: the machines are slowing, warranty has expired, and support time on them is rising.

He sends it to his manager, who agrees and sends it to Finance. Finance asks whether this is capex or opex. He does not know, because nobody has ever asked him that before and the previous replacements were bought in ones and twos on a card.

It turns out forty machines at once crosses a threshold that three machines at a time never did. That threshold triggers a different approval route, which requires a forecast he has not built, in a format he has not seen, for a committee that meets monthly.

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 committee meets in eleven days. He misses it by two days because the template needs a three-year total cost projection and he has to work out what that means. The next meeting is a month later. The machines get replaced in the following quarter, five months after the case was first written, and during those five months three of them fail and get replaced individually at retail prices on a card, which nobody questions because each one is below the threshold.

Nothing here was unreasonable. The threshold exists for good reasons and the committee is doing its job.

The real issue is not the approval process. It is that nobody told the person spending the money what the rules were until he tried to spend it.

When You Do Not Need to Think About This

While hardware spend is genuinely small. At thirty people buying three or four machines a year, the accounting treatment is noise. Buy them, expense them, move on.

When it is visible but not yet structural. Somewhere around sixty to a hundred people, hardware starts appearing in budget conversations. Somebody asks what the annual number is and nobody can answer immediately. Worth fixing, not yet urgent.

When it becomes a planning problem rather than a purchasing one. Past roughly a hundred and fifty people, or any size with a refresh cycle approaching, the spend becomes lumpy. Lumpy spend is what forces the capex conversation, because a flat annual number is easy to approve and a sudden large one is not.

The edge case that overrides all of this is a funding round or an acquisition process. Both bring scrutiny of the balance sheet, and both are poor moments to discover that nobody can produce a list of what the company owns and what it is worth.

What Teams Actually Need

"Which budget does this come from?"

An answer in one sentence, known before somebody needs to spend. Capital or operating, and what the threshold is between routine purchase and something requiring a case.

It matters because an undefined threshold does not mean no approvals. It means everything escalates to whoever is most cautious, which is slower than any policy would have been.

"What do we actually own?"

A list with values and ages. Most companies cannot produce this quickly, and it is the foundation of every other decision here.

It matters because you cannot plan a refresh, model a lease or answer a due diligence question without it.

"When do these machines need replacing?"

Not the accounting life, which is a policy choice. The useful life, which is when support burden and failure rate start to climb.

It matters because those two numbers are often different, and planning against the wrong one either wastes machines or keeps bad ones in service.

"Would renting actually be cheaper?"

Almost always no over a long horizon, and sometimes yes over a short one. The honest answer requires your own numbers rather than a vendor's comparison.

It matters because the pitch is usually framed as a saving when the real benefit is cash flow and service.

"What happens at the end?"

For owned machines, resale or disposal. For rented, return condition and what you keep. Both have a cost that is routinely left out of the comparison.

It matters because the end-of-life treatment is where the gap between two models is widest and least examined.

Build the Register Before You Model Anything

Every option below assumes you know what you own. Most companies do not, and any IT capex plan built on an estimate inherits that estimate's error for its whole life.

The register you need is smaller than an asset management project. Six fields per machine, which you can assemble for a few hundred devices in a couple of days.

Two of those rows cause all the difficulty. Current holder is usually stale, because reassignments happen without anybody updating a record. Written-down value frequently disagrees with reality, because machines disposed of years ago can sit on a depreciation schedule indefinitely if nobody tells Finance they went.

Build it once properly rather than perfectly. A register covering 95 per cent of machines, assembled in two days and then corrected as errors surface, is worth far more than a complete one that never gets finished because somebody is chasing the last handful of serial numbers. The common failure here is treating the first build as an audit rather than as a starting position.

Reconcile against something independent rather than against your own purchase history, since both derive from the same orders and comparing them proves nothing. The two checks that work are matching holders against the current payroll list, which finds machines assigned to leavers, and physically sampling thirty devices, which finds everything else.

The output is the foundation of the IT capex conversation. Without it you cannot say what a refresh will cost, cannot model a transition to a service, and cannot answer a diligence question with anything but an estimate.

Modelling the Comparison Honestly

Vendor comparisons in this area are built to favour whoever produced them, so build your own. It is arithmetic rather than analysis and it takes an afternoon.

Pick a realistic cohort, say 40 machines, and model each option over the same period, typically 48 months, including everything.

Three rows decide most comparisons and they are the three most often omitted. Retrieval, because collecting machines from people who left is genuinely difficult and expensive if you are doing it yourself. Replacement on failure, because at 48 months a meaningful share of a cohort will need intervention. And residual value, because an owned fleet at the end of four years is still worth something and a rented one is worth nothing to you.

Run it with your own numbers and the answer is usually clear rather than marginal. What the exercise really produces is not a decision but a defensible case, which is what gets an IT capex request through a committee without the five-month delay described above.

The Four Ways to Fund Hardware

Outright purchase, capitalised

You buy the machines, they sit on the balance sheet, and you write them down over an agreed life.

When it is right: steady headcount, available cash, machines kept three years or more. Cheapest total cost by a clear margin.

When it fails: when cash is the constraint rather than cost, or when headcount is volatile enough that you keep buying machines for people who do not stay.

Outright purchase, expensed

Same transaction, treated as an operating expense because the individual values fall below your capitalisation threshold.

When it is right: small volumes, low unit values, simple administration. Most companies under a hundred people are doing this whether or not they have decided to.

When it fails: at scale, where a large expensed purchase distorts a single period and invites the scrutiny that a planned capital item would have avoided.

Leasing

A finance arrangement over a fixed term, with the machines returning or being purchased at the end.

When it is right: when preserving cash matters, when the spend needs smoothing across periods, or when a predictable annual figure is worth more than the lowest total.

When it fails: on flexibility. Leases assume you still need the same number of machines in year three, and early exit is usually expensive. Headcount reductions make this painful.

Device as a service

A per-device monthly fee covering hardware plus some combination of management, support, replacement and retrieval.

When it is right: short horizons, distributed teams with no IT function, or situations where the operational work is the real constraint rather than the money.

When it fails: past about three years, where the arithmetic stops working and you have paid more than the machines cost while owning nothing. Vendors presenting this as a saving are usually describing the first year.

The Refresh Cycle Is the Real Planning Problem

Funding models get the attention. The refresh cycle is what actually determines whether IT capex is a steady line or a crisis every few years, and most companies never set one deliberately.

What happens by default is that machines get replaced when they fail or when somebody complains loudly enough. That produces two bad outcomes at once: a long tail of old hardware generating support work, and unpredictable spending that lands in whichever quarter the complaints peaked.

A deliberate cycle fixes both, and the cycle length is a judgement rather than a rule. Three years is common and generous. Four is defensible for most office work and increasingly normal. Five is possible for light use and starts to cost you in support time and employee patience well before the machines actually stop working.

Two refinements make a cycle work in practice.

Band by role rather than applying one number. Machines doing heavy work genuinely wear out faster in usefulness terms, while a laptop used for mail and documents stays adequate considerably longer. One cycle length across the whole fleet either retires good machines early or keeps bad ones in service, and usually does both simultaneously.

Stagger the cohort. If you bought 40 machines in one quarter, you will replace 40 in one quarter, and that lump is exactly what triggers the approval problems described earlier. Deliberately splitting a replacement across two or three periods smooths the IT capex line and makes each tranche small enough to approve routinely.

The second point does the most work and is the least obvious. A company that staggers its purchases never has a crisis year, and a company that buys in bulk for the discount creates one every refresh cycle. The discount is usually smaller than the disruption.

What Changes Under Diligence

Worth a short section because it is when the quality of all this becomes externally visible, and because it arrives with very little notice.

A funding round, an acquisition or an insurance renewal all produce the same request: show us what you own. Specifically, a list of assets with values, evidence that the values are current, and an explanation of any difference between the depreciation schedule and reality.

Three findings are common and all three are avoidable.

Assets on the schedule that no longer exist. Machines disposed of or lost, never written off, still depreciating quietly. This looks like poor control rather than fraud, and it undermines confidence in every other number.

Assets that exist and are not on the schedule. Usually equipment bought on cards below a threshold, or inherited through an acquisition and never recorded. Less damaging, still untidy.

No evidence of custody. A list of machines with no record of who holds them, which makes recovery and valuation both theoretical.

None of this is hard to fix in advance and all of it is hard to fix in a fortnight under pressure. The register described earlier, reconciled quarterly, answers all three. That is the unglamorous argument for doing the IT capex groundwork before anybody asks for it, and it is the argument that tends to persuade a finance team faster than any efficiency case.

Getting the Case Through

Having built the register and the model, the remaining obstacle is usually organisational rather than analytical, and the opening story is mostly about that.

Four things make an IT capex case land, and none is about the quality of the arithmetic.

Lead with the consequence of waiting, not the benefit of acting. A case that opens with improved performance competes against every other improvement request. A case that opens with the number of machines out of warranty, the support hours they consumed last quarter and what happens if the pattern continues is a risk statement, and risk statements get decided faster.

Bring the comparison, not the conclusion. Finance committees are suspicious of a single recommended option and comfortable with three modelled options and a reasoned preference. The second framing is also more honest, because it exposes the assumptions.

Pre-agree the format. The five-month delay in the opening story was caused by discovering the required template two days before a deadline. Ask what the committee needs before you need it, which is a ten-minute conversation that saves a cycle.

Show what happens to the old machines. A case that ends at purchase ignores half the asset life. One that covers disposal or resale, with an expected residual, demonstrates that the whole cycle has been thought about and usually improves the numbers.

One more thing worth saying because it is rarely said. If your organisation's approval cadence is monthly and your refresh is predictable, the deadline you are working to is knowable a year in advance. Most IT capex emergencies are scheduling failures rather than funding failures, and the fix is a calendar entry rather than a better argument.

How to Choose: Five Questions

How long do you actually keep a machine?

Measure it rather than assuming. If the real answer is four years, most rental models lose on total cost before you start.

Is cash or cost the binding constraint?

These point in opposite directions and only one of them is usually true at a time. Answer it honestly and the rest of the decision follows.

How predictable is your headcount?

Volatile headcount punishes fixed-term commitments. If you might be twenty per cent smaller in eighteen months, that belongs in the model.

Who carries the operational work today?

If nobody does, and machines arrive late and never return, a service model may be worth paying for on those grounds alone regardless of the cost comparison.

What is the exit?

For every option, write down what happens at the end and what it costs. This is the part most comparisons omit and it is frequently where the difference lives.

What Distributed Teams Change About All of This

Everything above assumes machines can be delivered and recovered without much difficulty. For a distributed team neither assumption holds, and that changes the IT capex calculation in three specific ways rather than in general.

The cost of a machine is not its price. A laptop shipped across a border is a commercial import with a declared value, a commodity code and duty treatment, and the landed cost in some markets runs meaningfully above the purchase price. Budgeting from a quoted machine price understates what you will actually spend, and the gap varies by destination, so a single uplift percentage across a fleet is wrong in both directions.

Residual value becomes conditional. An owned fleet is worth something at the end only if you can get it back. For a company whose leavers are spread across eight countries with no entity in most of them, recovery rates below fifty per cent are entirely possible, and a residual value calculated on the assumption of full recovery is fiction. This is the single largest adjustment distributed teams need to make to a standard buy-versus-rent model.

The operational work has a real cost that nobody budgets. Somebody arranges each shipment, tracks it, chases customs queries and organises returns. In an office that work was invisible because it was five minutes at a desk. Distributed, it is a part-time job, and it is usually being done by somebody whose actual role is something else.

The practical consequence is that service models look better for distributed teams than the raw arithmetic suggests, not because the financing is cheaper but because they absorb the second and third items. That is a legitimate reason to pay more per device, and it is a different argument from the cost saving usually offered. Make the argument you actually mean.

The Options

Hardware funding splits between the manufacturers and finance providers on one side, and equipment lifecycle vendors on the other. The second group bundles the funding with the operational work, which is the actual pitch.

Manufacturer financing programmes. Apple, Dell and Lenovo all offer leasing or instalment arrangements alongside direct purchase. Best for single-manufacturer fleets in one country. Where they struggle: they fund the machine and do nothing about getting it to a person in another market or back again.

Traditional asset finance. Your bank or a specialist lessor. Best when the decision is purely financial and you already have the operational side covered. Where they struggle: no operational involvement at all, and the machines remain your problem to move and recover.

Workwize. Lifecycle platform offering purchase and rental alongside warehousing, shipping and retrieval. Publishes no rate; the figures on its pricing page are savings claims rather than prices. Best for distributed teams needing in-region stock.

allwhere. Lifecycle platform covering procurement, deployment and retrieval. Publishes no rate, quote and demo only.

GroWrk. Lifecycle platform with wide country coverage. Publishes no rate of its own, and its pricing page carries estimated costs for competitors rather than its own figures, which is worth knowing before quoting anything from it.

Firstbase. Provisioning and retrieval for distributed teams, quote only. Use the firstbase.com domain; the older address returns a 200 and redirects to a homepage.

RemoAsset. Buying, renting and leasing in one place, with shipping, retrieval, storage and wiping, and a register of what it handled. Disclosure: RemoAsset is our own product. We build it, which is why its limits appear here as plainly as its strengths. Best when the funding decision and the logistics decision are the same decision, which for distributed teams they usually are. Its Subscription tier is the only tier that publishes a figure, from $1,499 per year, with everything else quoted like the rest of this category. Where it struggles: no network discovery, so it cannot tell you about machines nobody enrolled through it, which matters here because an accurate owned-asset list is the starting point for any capex plan. And no software licence management, so the software side of your technology spend sits entirely outside it.

The Thresholds Worth Writing Down

The opening story is a story about an undefined threshold, so here is the fix, and it is a single page rather than a policy project.

Four numbers and four sentences settle almost every case that currently escalates.

The capitalisation threshold. The value above which a purchase is treated as an asset rather than an expense. Finance sets this and most IT people have never been told it, which is why the same purchase gets handled differently depending on who processes it.

The manager approval limit. What somebody can authorise without asking anybody. Setting this too low is a false economy, because the cost of the approval round trip routinely exceeds the value of the scrutiny.

The case threshold. The point above which a written justification is required rather than an approval. This is the one that caused the five-month delay, and the fix is not changing the threshold but publishing it along with the template that will be required.

The emergency route. What happens when a machine fails and somebody needs a replacement this week. Without a defined route, people use a card and the purchase escapes every control you built, which is precisely what happened with the three retail replacements in the story.

Write them for the person who will use them rather than for the person who approves them. A threshold expressed as a policy clause gets ignored; the same threshold written as "under this figure, just buy it; over it, use this form" gets followed, because it answers the question somebody actually has at the moment they have it.

The emergency route is the one most often missing and it is the one that quietly undermines the rest. A control framework with no fast path does not prevent unplanned IT capex, it just relocates it somewhere nobody is looking.

Write all four down, put them where the people spending money will see them, and review them annually. The whole document is shorter than this section.

Where the Software Side Sits

Hardware dominates this conversation and software is the larger number in many companies, so it is worth being explicit about why it mostly sits outside an IT capex discussion.

Subscription software is an operating cost by its nature. There is no asset, nothing to depreciate, and nothing to recover at the end. It does not appear in a capital plan, which is convenient and is also why it grows without the scrutiny hardware receives.

That creates an odd asymmetry. A single purchase of 40 machines triggers a committee. An equivalent annual spend accumulating across dozens of per-seat subscriptions, bought a few seats at a time by different teams, frequently triggers nothing at all until a renewal lands on somebody's desk.

Two practical consequences follow. First, if you are building a technology spending picture for a board or a diligence process, hardware and software need to be presented together or the picture is misleading. Second, the discipline that applies to hardware, which is knowing what you own and reviewing it on a cycle, applies at least as strongly to software and is far less often applied.

The tools differ. Asset and spend platforms handle the software side, and the equipment vendors discussed here mostly do not, which is a boundary worth knowing before buying either and expecting it to cover both.

The Decision Table

What Happens to Machines at the End

The comparison table lists residual value as a row and then moves on, which understates how much of the IT capex argument sits in that single line.

An owned machine at the end of four years is worth something. How much depends on model, condition, specification and how quickly you act, and the last of those is the one you control. A device that comes off a desk and goes straight through a resale channel is worth meaningfully more than an identical device that sat in a cupboard for eleven months while somebody decided.

Four routes exist and they trade return against effort almost perfectly. Manufacturer trade-in pays least and costs nothing. Independent buyback firms pay more and handle collection and data destruction for you. Marketplace selling pays most per unit and costs real hours per unit, which stops working at any volume. And selling to your own staff is frequently the best net outcome and the one companies forget.

Two things have to happen before any of them. The machine must be released from device management, or it reappears as a managed device for its new owner. And any account or activation lock has to be cleared while you still have access, because afterwards it is close to impossible and a locked machine is worth nothing to anybody.

The planning consequence is that residual value is not a number you receive, it is a number you either protect or waste. Companies that set a default decision at the moment a machine comes back, with a review date attached, recover a reasonable share. Companies that decide case by case recover very little, because the decision keeps getting deferred and the asset keeps shrinking while it waits.

This also changes the funding comparison in a direction most vendor models ignore. If your organisation reliably lets returned machines sit for a year, the residual value in your purchase model is largely theoretical, and a service model that includes retrieval looks better than the arithmetic alone suggests.

The Cost of Getting This Wrong

Three layers, and only the first appears in a budget. The other two are larger and neither has a line item, which is the ordinary reason they go unaddressed for years.

The visible cost is the difference between funding models over a term, and it is smaller than most vendor comparisons suggest. It is also the only layer that appears in a proposal, which is why proposals make a poor basis for this decision taken on their own. Across a realistic range of terms and volumes, the gap between a sensible lease and a sensible purchase is modest, and the gap between either and a service model depends almost entirely on how long you keep the machines.

The second layer is the cost of indecision, which is what the opening story describes. Five months of deferral produced three emergency replacements at retail, a team working on slow machines, and a senior person spending days on a template. None of that appears as a cost of the funding model, and all of it was caused by the absence of a written rule.

The third layer is the register. Every option here assumes you know what you own, what it is worth and how old it is. Companies that cannot produce that list discover it at the worst moment: during diligence, during an insurance renewal, or when somebody asks why the depreciation schedule contains machines that were disposed of two years ago.

So the question is not which funding model is cheapest. It is this: if Finance asked you today for a list of every machine the company owns, with its age and written-down value, how long would it take and how much of it would be an estimate?

Three Arguments That Do Not Survive Contact With Numbers

Three claims come up constantly in this area and all three are weaker than they sound. Worth knowing before somebody makes them at you, or before you make one yourself.

"Renting means we always have current machines." True in principle and frequently not in practice, because refresh at the end of a term is a contractual event that still needs somebody to organise it. Companies that let owned machines run to five years are usually the same companies that extend a rental term rather than going through a replacement cycle. The model does not supply the discipline; the discipline has to exist either way.

"Moving to a service model removes the asset from our balance sheet." Accounting treatment of these arrangements is genuinely technical and depends on the specific terms, the standard you report under and the substance of the contract rather than its label. Anybody asserting a balance sheet outcome before your accountant has read the actual agreement is describing a hope. Ask the question, get the answer in writing from somebody qualified to give it, and do not let it be a headline reason for the decision.

"Bulk buying gets us a better price." It does, and the discount is usually smaller than the cost of the lumpiness it creates. A single large purchase triggers the approval scrutiny that a staggered one avoids, concentrates your refresh into one bad year, and commits you to a machine count before you know whether you will need it. A few per cent is rarely worth that, and the companies with the smoothest IT capex lines are generally the ones buying steadily rather than opportunistically.

The common thread is that each argument is true as a statement and misleading as a reason. Test all three against your own numbers and your own track record rather than against the version in a proposal.

When You Are Ready to Move Beyond Buying Ad Hoc

Buying machines as you need them is not a failure state. It is the correct approach for a long time, and plenty of well-run companies at a hundred and fifty people still do it because somebody keeps a decent list and the cash is there.

What changes the answer is lumpiness and visibility. When replacements cluster into a single year, the spend stops being absorbed quietly and starts requiring a case. When somebody outside the team starts asking what the company owns, estimates stop being sufficient.

There is a third trigger that catches people out, which is a change of finance leadership. A new finance director arriving at a company of this size will, reasonably, want to understand what the technology estate consists of and what it is worth. Teams who have never been asked discover in that first week how much of their picture was held informally. It is a poor moment to start building a register, and a good argument for having one that is boring and current.

At that point the useful work is not choosing a funding model. It is building the register and writing down the thresholds, because both are prerequisites for any model and neither requires a vendor. A list of machines with ages and values, plus two sentences about which budget applies above which figure, removes most of the friction described on this page.

The funding decision after that is comparatively easy, and it is mostly a conversation with Finance about cash rather than a procurement exercise.

Frequently Asked Questions