Capital expenditure is money spent to acquire or create an asset used across several periods and written down over time, and operating expenditure is consumed in the period it is incurred. This article covers how the split changes approval, NPV, and payback for technology investments.
Capital expenditure (capex) is money spent to acquire or create an asset the organisation will use across several periods. The asset sits on the balance sheet and is written down over time through depreciation or amortisation, so its cost reaches earnings across the years in which the asset is used. Operating expenditure (opex) is money spent on something consumed in the period it is incurred, and it is 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. The distinction matters to a technology leader because it changes who approves the spend, how demanding the approval is, and what the investment looks like when someone models the return, and each of those changes shapes whether the program is funded at all.
This article is general background and gives no 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 organisation's own capitalisation policy, which sits inside those rules and adds detail. Confirm the treatment of 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 reaches earnings gradually, as an amortisation charge spread across the asset's useful life, so a $3 million build amortised over five years shows up as roughly $600,000 a year.
Operating spend lands in full, in the current year. The owner of the cost centre carries all of it.
Because the two categories carry different consequences, different people approve them through different processes. Finance rations capital centrally. It releases the money once a year and expects a business case for each request. Business units hold operating budgets, and they defend those budgets against everything else the unit wants to do that year. A manager with an operating budget and no capital allocation will structure a purchase to fit the budget they control, and a manager measured on this year's earnings will make the same move in the other direction. That behaviour is rational. It is also the reason the classification belongs in the business case as a stated assumption, agreed with finance before approval, because an assumption that nobody wrote down gets renegotiated after the money has been committed.
Buildings and laptops are easy to classify. Software is harder. The difficulty concentrates in three places, and each has a different accounting answer.
Subscriptions. A cloud service billed monthly or annually is generally treated as operating expenditure. The buyer purchases a right to use something over a period and consumes it as it goes, so the balance sheet carries no asset for it at year end.
Perpetual licences and the implementation around them. A licence bought outright and installed on infrastructure you control looks much more like an asset you own. Treatment follows that ownership. The implementation work around it (configuration, data migration, integration, and testing) may be capitalisable as part of bringing that asset into use, and the line between preparing an asset and running a project differs from one framework to the next.
Software you build yourself. Internally developed software is treated in phases. Exploratory work, such as deciding whether to build, evaluating options, and proving feasibility, is generally expensed as incurred. Later work is treated differently. Work after the organisation commits to completing an identifiable asset it intends to use may be capitalisable. The point where that transition falls, the evidence that shows you crossed it, and the categories of cost that qualify afterwards all vary by standard and by policy. Many organisations also set a value threshold. Nothing below it is capitalised.
Standard-setters have debated the cloud versions of all three for years, particularly the configuration and implementation costs attached to a subscription. Treatment has shifted over that time and still differs between reporting frameworks. If your program involves significant implementation effort on top of a subscription, take the question to finance first, before the cost is entered in a business case as either capital or operating spend.
Two options with the same total cost can produce different financial cases. The cash moves at different times.
Take $1 million of spend. Bought as a capital purchase, most of the cash leaves in year zero. The buyer pays up front. The same capability as a subscription at $200,000 a year for five years takes the cash out in five instalments, one at the end of each year. Discounted at 8%, those five instalments have a present value of about $799,000, which is roughly $201,000 below the capital option before anyone has argued about a single benefit.
Payback moves too, and often in the opposite direction. A subscription defers cost and leaves the benefits on their original dates, so it can pay back sooner. If the subscription runs for seven years, it costs $1.4 million in nominal terms against $1 million for the purchase. Which option wins depends on the discount rate, the horizon you model, and when the benefits arrive. Preference cannot settle it.
Two effects get conflated at this point. The accounting classification leaves the cash where it is, because a capitalised asset is paid for when it is paid for, whatever the amortisation schedule says. Cash follows the commercial structure of the deal, and the deal usually determines the classification as well. The two travel together. Buying outright and subscribing are different deals with different cash profiles, and each brings its own accounting treatment along with it.
Projects reclassify spend regularly. A program approved as an on-premise build switches to a managed service in month four. A phase is re-scoped and stops meeting the capitalisation criteria it was assumed to meet. Someone finds that the implementation costs everyone budgeted as capital will be expensed.
Each of these changes the capital budget, the earnings impact, and the cashflow profile, so each one changes the numbers the investment was approved on. A team that moves spend between capex and opex mid-flight has made a financial choice. The trigger may have been technical, and the consequence is still financial.
The change is often the right call. It usually gets made inside a delivery conversation, among people reasoning about architecture, and the decision never reaches the record of what the investment was supposed to return, because nobody in that conversation owns the record. Six months later the forecast has moved and the original case says something else. Nobody can point to the moment the two diverged, or say who agreed to the change, or on what basis they agreed.
Handle it the way you would handle a scope change. Someone with financial authority sees the revised profile and agrees it. The reasoning is written down beside the case it revises, where the next reviewer of the investment will find it without asking anyone. Recording it takes about five minutes on the day.
Tollgate holds the business case and the financial model inside Jira, in a Forge app. The model takes year-by-year cashflows over a 3, 5, or 7 year horizon and computes NPV at a discount rate you set. It also computes IRR and payback, discounted and undiscounted, from those cashflows. An append-only decision log records the moments the case changes. Your finance team classifies the spend, working from your capitalisation policy, and Tollgate keeps the numbers behind those decisions visible and versioned.
Tollgate keeps the business case, the gate decisions and the payoff in one record, next to the delivery they pay for.