CapEx vs OpEx for Software: The Question Finance Asks

TL;DR: Sooner or later, finance asks engineering the question: "How much of this is CapEx?" The answer decides whether an engineer-month hits this quarter's P&L or gets spread over the years the software earns its keep. The rules recently changed in engineering's favor. US GAAP dropped its waterfall-shaped stage test (ASU 2025-06), and IFRS's IAS 38 was never stage-based to begin with. Below: the split in plain engineering terms, what qualifies under each framework, and how to answer finance without inventing a spreadsheet every April. (This is an engineering leader's guide; accounting decisions belong with your controller and auditor.)

CapEx vs OpEx, in engineering terms

Operating expense (OpEx) is the cost of running the shop. It hits the profit-and-loss statement in the period the money is spent. Capital expenditure (CapEx) is the cost of building an asset: it lands on the balance sheet and gets amortized, meaning expensed gradually over the asset's useful life.

For software built in-house, the "asset" is the capability your team creates, and the raw material is engineering time. So the same payroll month can be classified either way depending on what the work was. Building a genuinely new capability that will deliver value for years looks like constructing a machine. Fixing bugs and keeping services alive looks like maintaining one. Finance cannot see the difference from the invoices.

Only engineering's records can say which was which. That is why the question keeps landing on your desk.

Why finance cares (and why you should)

Three reasons, none of them cosmetic.

• Timing. Expensing a year of platform build-out all at once depresses this year's reported profit even if the platform pays off for five. Capitalizing qualifying work matches the cost to the years of benefit, which is the entire accounting logic.
• Optics and metrics. Reported profitability, EBITDA-flavored metrics, and investor narratives all shift with the split. A company that capitalizes nothing can look less profitable than an identical one that classifies honestly.
• The strategic reframe. This is the one engineering leaders underrate. A defensible CapEx share is documentary evidence that engineering is investment, not overhead. Cost centers get cut in downturns; investments get defended. The classification you help produce is also the story told about your budget.

To be clear about what the split does not do: it does not change cash. The salaries leave the bank either way, at fully loaded cost, which is the rate the capitalized asset should be valued at. CapEx vs OpEx moves when and where the cost is recognized. That is exactly why the classification has to be honest. It is presentation, and misleading presentation is the thing auditors exist to catch.

What US GAAP says now: ASU 2025-06

For internal-use software, US GAAP (ASC 350-40) historically defined capitalization by project stages: preliminary (expense), application development (capitalize), post-implementation (expense). Agile teams spent two decades pretending their sprints mapped onto those phases. That test is gone. FASB's ASU 2025-06 removes the project-stage references entirely and starts capitalization when management has authorized and committed funding and it is probable the project will be completed and perform its intended function. It becomes mandatory for annual periods beginning after December 15, 2027, with early adoption permitted (Grant Thornton's snapshot).

Translated for engineers: the test moved from "what phase is this?" to "is this committed and likely to ship?" Your roadmap and delivery data can actually answer that.

What IFRS says: IAS 38

Under IFRS, IAS 38 never had stages; it splits work into a research phase, always expensed, and a development phase that must be capitalized once all six criteria are demonstrated: technical feasibility, intention to complete, ability to use or sell, probable future economic benefits, adequate resources to finish, and reliable measurement of the development expenditure (IAS 38, IFRS Foundation).

That sixth criterion is the engineering-relevant one: "reliable measurement" means you can attribute engineering effort to the specific asset, consistently, under questioning. It is an evidence requirement wearing an accounting costume.

One practical difference worth knowing: once the six criteria are demonstrably met, IAS 38 gives you no choice. Capitalization is mandatory. That cuts both ways: it stops selective classification, and it means your evidence quality effectively decides your accounting.

What never qualifies under either framework

The boundary both regimes agree on, in delivery terms:

• Exploration before commitment. Spikes, prototypes, research: all expensed. IAS 38 says so explicitly, and ASU 2025-06's "probable and committed" threshold excludes it by construction.
• Bug fixing and maintenance. Keeping existing software working is upkeep, and upkeep creates no asset. That includes the debt-interest hours quantified in The Real Cost of Technical Debt.
• Waste. Idle queue time, rework, process drag - all pure OpEx by definition. Nothing turns a reworked sprint into an asset, which is one more reason those numbers deserve their own line of attention.

Note the uncomfortable implication: the OpEx-only bucket is precisely the waste-and-upkeep share of engineering. A shrinking capitalizable share is finance-visible evidence that your roadmap is becoming maintenance.

Answering the question without an annual archaeology dig

The classification is finance's call; the evidence is engineering's product. What holds up is a record derived from delivery data rather than memory: which initiatives were committed (and when), which work attached to them, and how time was allocated - reproducibly, so the same inputs always regenerate the same split. The full playbook for doing this under continuous delivery, including what auditors actually probe, is in Capitalizing Software Development Costs in Agile; the wider context of pricing engineering honestly is the engineering economics hub.

The door: before finance asks next time, run the split yourself on last quarter. Committed new capabilities vs everything else, hours attributed from your actual tickets and PRs, loaded cost applied. If your delivery data can produce that in an afternoon, you've turned an annual fire drill into a report. And you'll walk into the CFO's office holding the one thing that reframes every budget conversation: proof of what the payroll built.