The balance sheet used to tell a story about a company's technology, and you could read it. A line for the servers in the data center, a line for the perpetual software licenses, both sitting in the asset column, both depreciating on a schedule an auditor could trace. Technology was something you bought, owned, and wore out. The accounting followed the ownership.
Open the same balance sheet today and the technology is almost gone. Not the technology itself — a modern company runs on more software than it ever has — but the asset that used to represent it. The servers moved to someone else's data center and became a monthly invoice. The perpetual licenses became subscriptions. The capitalize-and-depreciate story that used to explain a company's tech investment quietly ended, and most of the spend relocated to a single line in operating expenses that nobody depreciates, nobody amortizes, and nobody puts on the balance sheet at all.
I run security and DevOps in a fintech that serves 1,500-plus financial institutions, so I am not the person who signs the financial statements, and I want to be careful about the seat I am reasoning from. But I own the systems that generate the spend, and I have watched its accounting drift out from under the people who report on it. The shift from capex to opex got treated as a procurement change. It was an accounting change, and it reopened a question most technology leaders are happy to duck.
Where the software asset went
Start with the mechanic, because the rest follows from it. In the on-premise world, standing up a capability meant capital. You bought servers and you bought a license, both large, both up front, both landing in the asset column as property or intangibles. The cost did not hit earnings that year. It hit earnings a slice at a time, over the useful life, as depreciation and amortization. The balance sheet held the asset; the income statement felt it slowly.
The cloud and SaaS model inverts every piece of that. You do not buy the server; you rent a fraction of one by the second, and the invoice is an operating expense the month you incur it. You do not buy the license; you subscribe, and the subscription is an operating expense too. Nothing lands in the asset column, because you own nothing — the provider does. The provider capitalizes the data center and depreciates the hardware. You pay the rent, and the rent is opex, all of it, every month, forever.
This is the part that gets waved through as obviously good. No big up-front outlay, no stranded hardware, pay for what you use. All true. But "we moved it to opex" is not a discount. It is a relocation. The same economic activity — running the software the business depends on — used to be spread across years as a slowly amortizing asset, and now it hits the current period in full. The cash timing changed, which everyone noticed. Where the cost lands in the financial statements also changed, which fewer people did.
The EBITDA line moved, and nobody told the board
Here is where the relocation stops being cosmetic. Depreciation and amortization sit below the EBITDA line — that is what the D and the A stand for, and both get added back. Operating expenses sit above it. So a cost moving from capex to opex does not just change category — it crosses the EBITDA line, from the part of the income statement that gets added back to the part that does not.
Run that forward. A company that used to buy servers and capitalize software carried much of its technology cost below EBITDA, invisible to the metric. The same company on cloud and SaaS carries that cost above EBITDA, in full, every period. Same business, same technology footprint, lower reported EBITDA — not because anything got worse, but because the accounting geography changed underneath it. For a company valued on an EBITDA multiple, and in the mid-market most are, that is not a rounding difference. That is the number the multiple gets applied to.
I am not arguing anyone should chase capex to flatter a metric; the cloud economics are usually the right call on their own terms. I am arguing the shift had a reported-earnings consequence that mostly went unspoken, and the people who read the income statement — the board, the lenders, an eventual buyer — deserve to read it as an accounting effect, not a performance one. Which brings us to the one lever that still moves technology cost back below the line, and the standard that governs it.
ASC 350-40 is the question most tech leaders duck
Under US GAAP, the rule that governs capitalizing software you build for your own use is ASC 350-40, internal-use software. I am not your controller and none of this is accounting advice, but the shape of it matters to anyone who runs an engineering organization. The standard splits a software project into stages. The preliminary stage — deciding what to build, evaluating alternatives — is expensed. The application-development stage — the design, coding, configuration, and testing — is capitalized. The post-implementation stage — training, maintenance, keeping it running — is expensed again.
So even in an all-opex world, a slice of technology spend is still capitalizable: the development labor that builds internal software. And it is not only software you host yourself. ASU 2018-15 extended the same logic to the cloud, letting a customer capitalize qualifying implementation costs on a hosted arrangement that is otherwise a service contract — the subscription stays opex, but the work of configuring and implementing it can be capitalized and amortized over the term. The rule survived the shift to SaaS. What did not survive was most organizations' ability to answer it.
Because this is the question tech leaders duck. Ask a CIO or a VP of engineering how much of last quarter's development effort was application-development-stage work under ASC 350-40, and the honest answer is usually a shrug, or a number finance built from a spreadsheet of loose estimates. Capitalizing is not free money. Over-capitalize and you have flattered both earnings and operating cash flow — the outflow shifts from operating to investing activities — in a way a quality-of-earnings review will find and unwind. But expensing everything for the sake of simplicity leaves real, defensible cost below the line unclaimed. Both errors trace to the same root: nobody could attribute the engineering work.
The answer lives in engineering telemetry, not the ledger
This is the part I actually have standing to talk about, because it is not an accounting problem dressed up as an engineering one. It is an engineering problem the accountants inherited. The largest input to the capitalization decision is developer time — whose, on what, in which stage — and developer time is exactly the thing most organizations cannot attribute cleanly. Finance cannot capitalize what engineering cannot describe.
It got harder, not easier, with modern delivery. ASC 350-40 was written around a waterfall project with tidy stages you could draw a line between. Continuous deployment does not have stages. A team ships to production dozens of times a day, mixing new development, enhancement, and maintenance in the same afternoon, and the neat preliminary-development-post model has nothing to grip. The standard-setters noticed: the FASB has been working to modernize ASC 350-40, moving away from the project-stage framework toward a threshold that turns on whether management has committed to funding the work and it is probable the software will be completed and used. That is a real improvement, and it still requires someone to produce the underlying record of what was built and when.
What finance actually needs from engineering to answer the question defensibly is not exotic. It is telemetry the platform organization can generate as a byproduct of how work already flows:
- Work attributed to the project, not the person. Which epics and stories were net-new development versus maintenance, tied to engineers and hours, sourced from the system that runs the work rather than a quarter-end survey.
- A stage marker on the work item. Whether a body of work was preliminary evaluation, application development, or post-launch operation — a field on the ticket, not a reconstruction six months later.
- Cloud implementation cost carved out from run cost. The one-time configuration and integration of a new SaaS platform, separated from the recurring subscription, so the ASU 2018-15 question can even be asked.
- An evidence trail that ties the number to reality. The commit history, the deployment record, the project plan — the same artifacts that answer an auditor also answer the capitalization question, if you keep them.
None of that is new tooling. It is the same attribution discipline that FinOps demands for cloud spend, pointed at labor instead of infrastructure. If you can tell finance what a workload cost to run, you are most of the way to telling them what a project cost to build — and which stage it was in when the cost landed.
And now an agent wrote half of it
There is a wrinkle coming that the standard never contemplated, and I sit close enough to watch it arrive. We built AgentOS, a governed internal platform where AI agents do real work, and a growing share of that work is software development. Which raises a question I have not seen the accounting profession answer cleanly: when an agent writes the code, whose development labor was it?
ASC 350-40's capitalizable bucket is built around direct costs, and the largest historically has been employee compensation for time spent in the development stage. An agent has no salary. Its cost is inference — tokens metered by the second, closer in shape to a cloud bill than a payroll line. If a capitalizable software asset is increasingly built by compute rather than by people, the labor-cost inputs the standard leans on start to thin out, and the cost that replaces them looks like exactly the opex we started this piece worrying about. That is not settled, and it is one more reason the attribution has to be real: when the examiner or the diligence team asks how a capitalized number was built, "an agent did it" is not an answer, and the metering that proves what the agent actually did is the same control plane you should be running for every other reason.
What to actually do about it
The capex-to-opex shift rewrote where technology shows up in the financial statements — it emptied the asset column, moved cost above the EBITDA line, and left a capitalization question the standards still answer but most organizations can no longer feed. You do not fix that in the ledger. You fix it upstream, in how engineering work is recorded. Four things worth doing:
- Get the shape in front of the board. Make sure whoever reports EBITDA can explain how much of its trend is the cloud shift moving cost above the line, not performance falling off.
- Instrument development the way you instrument cloud spend. Attribute engineering work to projects and stages as a byproduct of the workflow, not a quarter-end reconstruction.
- Give finance the record, not the estimate. Capitalize on evidence a quality-of-earnings review would accept, or expense honestly — never split the difference with a guess.
- Start metering agent-built development now. The labor-cost question is going to get asked, and the answer is telemetry you must be collecting before anyone asks.
I will admit the edge of this I am least sure about: where the line actually falls on agent-generated development effort under ASC 350-40. If you have a controller or an auditor who has taken a real position on it, I would genuinely like to hear how they drew it — because the number of us building software with agents is only going one direction, and the accounting will have to catch up. Tell me where you have landed.
