OPEX vs CAPEX in software development: the decision that shapes your EBITDA

When someone tells me they’ve spent a million euros on technology, the first question I ask is always the same: spent, or invested?

FELIPE POLO
CEO Orbitant

At Orbitant, a client’s finances matter to the whole team, not just to whoever holds the CTO title or sits in the finance department: they help anyone in technology make better decisions about what they build, because every line of code ends up reflected somewhere in the company’s accounts.

That’s why I ran an internal session on OPEX vs CAPEX in software development: the same hour of work from a technology team can be recorded in two completely different ways. That decision changes the year’s profit, the EBITDA, and even the company’s valuation.

This goes beyond accounting. When a client decides to capitalise a piece of development instead of booking it as an operating expense, they’re making a decision that affects how the financial health of their business looks from the outside — to an investor, a bank or a potential buyer. And anyone who takes part in deciding what gets built, how it gets prioritised and at what pace, is also taking part in that financial decision, whether they realise it or not.

Balance sheet and P&L: two documents you have to read together to understand a project

Every company closes three financial documents each month: the balance sheet, the profit and loss account (P&L) and the cash flow. We’ll leave cash flow aside here because, to understand OPEX and CAPEX, the other two carry far more weight: the balance sheet tells you what the company has at a given moment, the P&L tells you whether that wealth is producing a return, and depreciation is the point where the two documents meet. Without those three concepts clear, capitalising or expensing a piece of development is a decision made blind — you take it without knowing what you’re actually moving.

The balance sheet: what the company has and who it owes it to

The balance sheet shows, at a specific point in time, what resources the company has (its assets) and who it owes them to (liabilities and equity). The distinction between liabilities and equity matters because it tells you where the funding came from: liabilities are the money the company owes to third parties (banks, suppliers, debt funds), while equity is what it owes to its own shareholders — capital that doesn’t have to be paid back like external debt, because it belongs to the people who founded or invested in the company.

Those two sides always balance out through the same equation: assets = liabilities + equity. A €10,000 bank loan, for example, increases the company’s cash (an asset) and at the same time creates an equivalent debt with the bank (a liability). A €1,000,000 capital increase works similarly: that million lands in cash as an asset, but in this case it shows up under equity as a contribution from shareholders, not as debt.

Within assets it’s worth distinguishing two types, depending on how quickly they can be turned into cash:

• Current assets: cash, liquid investments, invoices waiting to be paid. They convert into money quickly.
• Non-current assets: property, machinery, in-house software. The company can’t liquidate them from one day to the next.

The profit and loss account: whether those resources are producing a return

While the balance sheet is a snapshot of a given moment, the profit and loss account captures everything that happened over a full financial year: it measures whether the resources the company has managed to fund are being put to productive use. You calculate it by subtracting, from top to bottom: sales, direct costs (cost of goods sold), structural costs (overheads), depreciation and amortisation, and tax.

Direct cost is the spend tied to producing what you sell (raw materials, depreciation of the machinery, the salary of whoever operates it); overheads are the structure around that production: sales, marketing, admin, offices. VAT doesn’t belong in any of those lines: it’s never income or an expense for the company, but a liability or an asset depending on whether you’re collecting it or paying it. The company acts as an intermediary: it passes VAT on, but neither gains nor loses from it. The end consumer pays it. That money ends up with the tax authorities, not with the company.

Where the two documents meet: depreciation

The concept that connects the balance sheet with the P&L is depreciation. The international standard that governs when something can be recognised as an asset describes the mechanism: spreading an asset’s wear and tear over time, instead of recording its full cost the day you buy it.

An example makes it clearer. When we buy a €2,000 computer at Orbitant, that spend doesn’t hit the P&L all at once: we swap €2,000 of cash for a computer worth the same amount. From then on, that computer loses book value every year. If it’s depreciated over five years, it loses €400 of value each financial year: those €400 are that year’s depreciation expense. The asset’s value drops on the balance sheet. That same amount shows up as an expense in the P&L. It’s the same logic that connects OPEX, CAPEX, and EBITDA, as we’ll see next.

OPEX vs CAPEX in software development: the call every CTO makes

The decision is this: when a development team spends its hours on a project, that work can be booked as an operating expense or as an investment in an asset, and whoever makes that call (usually the CTO) determines how the company’s P&L looks that year. Before looking at how it plays out in practice, it’s worth pinning down the two terms, because the rest of the reasoning depends on having them clear:

• OPEX (operational expenditure): the cost of keeping the business running day-to-day. It’s subtracted directly from the P&L in the year it occurs.
• CAPEX (capital expenditure): the cost of building an asset that the company will still own in the future. It goes on the balance sheet and is depreciated over several years, like the computer in the example above.

Everything a development team spends can be booked either way, depending on its nature. That choice carries the weight of a strategic decision that goes well beyond pure accounting. If a CTO decides their team’s work keeps the business running, that spend is declared as OPEX and reduces the year’s EBITDA. If they decide that work builds an asset (a piece of software, a platform, a brand), they can capitalise it as CAPEX and depreciate it over several years. Depreciation is subtracted after EBITDA, not before: capitalising a piece of development doesn’t reduce this year’s operating profit; it spreads it across the years that follow.

This also applies to brand building, for example. In our case, when we started out, we hired an agency for our branding and our website. Everything we’ve paid them, we’ve capitalised as a brand asset, because it builds something the company still has five years from now. Monthly WordPress maintenance, on the other hand, is OPEX, even though the same agency invoices us for it. The difference isn’t who’s charging, but what you’re paying for: a new asset, or the upkeep of one that already exists.

The same thing happens inside a technology team:

• The part building a new product can be capitalised as CAPEX.
• The part maintaining infrastructure or handling support is operating the business; that cost goes to OPEX.

A CTO can make this call project by project, as long as they can justify it if the tax authorities come asking.

Why EBITDA ignores depreciation (and what that has to do with your technology team)

EBITDA is the metric the market uses as its standard for comparing companies against each other, as Banco Santander’s financial glossary sets out. It excludes interest, tax, depreciation, and amortisation for a specific reason: those three lines depend on the country each company operates in and on how much it has invested in assets, not on whether the business is well run. A company paying 50% corporation tax isn’t necessarily worse than one paying 25% in Spain: it simply operates in a different tax environment.

This is where everything above comes together. If a technology team costs €700,000 a year and that spend is declared as OPEX, EBITDA drops by €700,000 that same year. If the same work is capitalised as CAPEX and depreciated over three years, EBITDA doesn’t move, because depreciation appears further down the account, outside the calculation. The real cost is identical in both cases; what changes is when and where it shows up, as José A. Dorado explains in his post on how the economics of a software consultancy work.

That explains something you’ve probably already seen in companies with recent funding: they don’t mind spending fast on technology because they’re investing cash they already have. Capitalising that development doesn’t touch the year’s EBITDA. Before you capitalise a piece of development, it’s worth asking three questions:

1. Does what the team is building still exist as an asset in three or five years, or is it recurring maintenance?
2. Under an audit, does that spend create an asset or does it just keep the business running?
3. Does the expected return (more sales, lower costs, a faster go-to-market) justify capitalising rather than expensing?

Building instead of renting: when CAPEX becomes strategy

The same criterion applies when a company stops renting technology and starts building its own. On one of our data projects, the platform we built for Afianza is an asset; the cost of the Azure infrastructure that runs it is OPEX, because that infrastructure isn’t ours.

Something similar happened with an e-commerce client and the licence for a payment platform: while they were paying for it, that cost went straight to OPEX and dragged on EBITDA every month. When a third-party platform gets expensive because the business has grown, building your own starts to pay off: you swap a recurring expense for an investment that depreciates, which is far gentler on EBITDA.

One of our software engineers, Iván Esteban, raised something that connects with this: how you account for technology also depends on the company’s exit strategy. If it wants to sell in five years, carrying on with licence payments might suit it better — or exactly the opposite, if it has just raised a round meant to fund a platform of its own: each company’s financial strategy decides which rule applies.

The same debate has played out on a much larger scale. David Yusta, another of our software engineers, pointed out that several big tech companies had extended the depreciation periods of their servers. He wondered whether that wasn’t a way of smoothing profits in the middle of an AI investment race.

Without offering any investment advice, the mechanism is the one we’ve seen here, applied at a different scale: Google extended the useful life of its servers from three to four years in 2021, which cut its depreciation expense by several hundred million dollars in a single quarter. Amazon, on the other hand, has recently shortened its own, citing the refresh pace that AI demands. Both are accounting decisions before they are technical ones, and both move reported EBITDA without moving a single euro of real spend.

Next time someone brings you a technology project, before you look at the architecture, ask how it’s going to be accounted for. The answer tells you more about the project’s financial strategy than any diagram. You can watch the full session here ⤵️