Capital expenditure is money spent to acquire or create an asset used across several periods, written down over time. Operating expenditure is consumed in the period it is incurred.
Capital expenditure (capex) is money spent to acquire or create an asset the organisation will use across several periods, which sits on the balance sheet and is written down over time through depreciation or amortisation. Operating expenditure (opex) is money spent on something consumed in the period it is incurred, and charged straight to that period's profit and loss. The same dollar, spent on the same project, can land in either column depending on what it bought and how the purchase was structured.
That is the accounting. What makes the distinction worth a technology leader's attention is that it changes who approves the spend, how hard the approval is, and what the investment looks like when someone models the return.
Nothing here is accounting advice. Whether a given cost can be capitalised depends on the jurisdiction you report in, the standard that applies to you (IFRS, or your local GAAP), and your own organisation's capitalisation policy, which usually sits inside those rules rather than restating them. Confirm the treatment for your specific spend with your finance team before you build a case on it.
Capitalised spend leaves the cash account and arrives on the balance sheet as an asset. It does not hit this year's earnings. It reappears as an amortisation charge spread across the asset's useful life, so a 3 million dollar build might show up as roughly 600,000 a year for five years rather than 3 million now.
Operating spend has nowhere to hide. It lands in full, this year, against the budget of whoever owns the cost centre.
So the two categories get approved by different people through different processes. Finance rations capital centrally, releases it once a year, and expects a business case for it. Operating budgets are held closer to the business unit and defended against everything else that unit wants to do this year. A manager with an operating budget and no capital allocation will structure a purchase to fit what they control, and a manager measured on earnings this year will do the same in the other direction.
None of that is dishonest. It is what happens when the classification carries real consequences for the people making the decision. It is also why the classification deserves to be a stated assumption in the business case rather than something finance sorts out afterwards.
Nobody gets confused about buildings and laptops. The trouble concentrates in software, in three places.
Subscriptions. A cloud service billed monthly or annually is generally treated as operating expenditure. You are buying a right to use something, over a period, and consuming it as you go. There is no asset on your balance sheet at the end of the year.
Perpetual licences and the implementation around them. A licence bought outright, installed on infrastructure you control, looks much more like an asset you own. The implementation work around it — configuration, data migration, integration, testing — may be capitalisable as part of bringing that asset into use, or may not, and the line between preparing an asset and running a project is not drawn identically everywhere.
Software you build yourself. Internally developed software is treated in phases. Broadly, exploratory work — deciding whether to build, evaluating options, proving something is possible — is expensed as incurred. Work after the organisation has committed to completing an identifiable asset it intends to use may be capitalisable. Where exactly that transition falls, what evidence demonstrates you crossed it, and which categories of cost qualify once you have, all vary by standard and by policy. Many organisations also set a value threshold below which nothing gets capitalised regardless.
Standard-setters have argued about the cloud versions of all three for years, particularly the configuration and implementation costs attached to a subscription arrangement. Treatment has shifted, and it still differs between reporting frameworks. If your program involves significant implementation effort on top of a subscription, that is the first question to take to finance, not the last.
Two options that cost the same in total do not produce the same financial case, because the money moves at different times.
Take 1 million dollars of spend. Buy it as a capital purchase and most of the cash leaves in year zero. Take the same capability as a subscription at 200,000 a year for five years and the cash leaves in five instalments. Discount those five instalments at 8 per cent and their present value is a little under 800,000. Same nominal spend, roughly 201,000 of difference in present value, before anyone has argued about a single benefit.
Payback moves too, and often in the other direction. The subscription defers cost without deferring the benefits, so it can pay back sooner while costing more in nominal terms across a seven-year horizon. Which option wins depends on the discount rate you use, the horizon you model, and when the benefits actually arrive. It cannot be settled by preference.
Two things get conflated at this point and are worth pulling apart. The accounting classification does not itself move cash — a capitalised asset is paid for when it is paid for, whatever the amortisation schedule says. What moves cash is the commercial structure, and the deal you sign is usually what decides the classification. The reason the two travel together is that buying outright and subscribing are genuinely different deals.
Projects reclassify spend all the time. A program approved as an on-premise build switches to a managed service in month four. A phase of work gets re-scoped and no longer meets the capitalisation criteria it was assumed to meet. Someone discovers the implementation costs everyone budgeted as capital are going to be expensed.
Each of those changes the capital budget, the earnings impact, the cashflow profile, and therefore the numbers the investment was approved on. A team that shifts spend between capex and opex mid-flight has not made a technical choice, it has made a financial one.
The change itself is usually the right call. The problem is that it gets made inside a delivery conversation, by people reasoning about architecture, and never reaches the record that says what this investment was supposed to return. Six months later the forecast has moved, the original case says something else, and nobody can point to the moment the two diverged or explain why.
Treat it the way you would treat a scope change. Someone with financial authority sees the revised profile, agrees it, and the reasoning is written down next to the case it revises. Recording it costs five minutes on the day. Not recording it costs someone an unanswerable question two years later.
Tollgate holds the business case and the financial model inside Jira — year-by-year cashflows over a 3, 5 or 7 year horizon, NPV at a discount rate you set, IRR and payback computed from those figures, and an append-only decision log for the moments the case changes. It does not classify your spend; that is a conversation with your finance team, working from your capitalisation policy. What it does is make sure the numbers those decisions rest on are visible, versioned, and still there when someone asks.
Tollgate keeps the business case, the gate decisions and the payoff in one record, next to the delivery they pay for.