CapEx vs OpEx for software teams: what's capitalizable and how to allocate it
Capital expenditure (CapEx) and operating expenditure (OpEx) are two ways the cost of building software shows up in your financial statements. The distinction matters because it changes how and when costs hit your income statement, how your margins look, and how investors read your spending. For engineering leaders, the practical challenge is less about the theory and more about a deceptively hard question: of all the work my team did last quarter, how much was capitalizable, and how do I allocate the cost?
The basic distinction
OpEx is cost consumed in the period it is incurred — it hits the income statement now. OpEx is the default treatment for most software activity: planning, research, bug fixing, maintenance, and keeping the lights on.
CapEx is spending that creates an asset with lasting value. Instead of expensing it all at once, the cost is recorded on the balance sheet and amortized over the asset's useful life. For software, this typically covers the development of new functionality and significant enhancements during the application development stage of a project.
Same dollar, different timing. Treating a cost as CapEx spreads its impact on the income statement over future periods and increases current-period reported profit relative to expensing it. That is precisely why the classification needs to be principled and consistent — not a lever you pull to flatter a quarter.
What is typically capitalizable
The exact rules depend on your accounting standard and policy, but the recurring patterns are:
- Usually CapEx: building new product features, designing and coding new functionality, significant enhancements that add capability.
- Usually OpEx: bug fixes, maintenance, incident response, refactoring that does not add functionality, research and feasibility work, training, and administrative overhead.
Notice that this maps almost perfectly onto how engineers already think about their work. A ticket is either "we are building something new" or "we are keeping things running." That alignment is what makes Jira a viable basis for allocation.
The allocation problem
Knowing the rules is the easy part. The hard part is splitting a real cost pool — your fully loaded team cost — between CapEx and OpEx without forcing engineers to log hours. Three common approaches:
- Time tracking. Precise in theory, unreliable in practice, and a real productivity cost. Engineers backfill timesheets and the data quality suffers.
- Project-level estimates. Finance estimates a percentage per project. Fast, but coarse and hard to defend when it does not trace to anything observable.
- Ticket-share allocation. Use the share of delivered work that is capitalizable as the allocation key against a known cost pool.
How ticket-share allocation works
If you know what a team cost over a period, and you know what fraction of the tickets they completed were capitalizable, you can estimate the capitalized portion directly:
CapEx estimate = period cost × (capitalizable tickets delivered ÷ all tickets delivered). Everything else is OpEx.
This is the model behind the Delimetrics capitalization dashboard. You set a per-team cost, flag capitalizable work in Jira with a custom field, and the tool scales the cost to the period you are viewing and splits it by the team's capitalizable ticket share. No timesheets, and every number traces back to a specific set of tickets. For the full methodology, see ticket-share allocation explained.
Why this holds up
Accounting standards generally ask for a rational, systematic method applied consistently. Ticket-share allocation satisfies that: it is objective (based on completed, classified work), repeatable (the same formula every period), and transparent (you can list the tickets behind any figure). It is more honest than a timesheet estimate, because nobody is reconstructing their week from memory.
The trade-off is that ticket count is a proxy for effort, and tickets are not all the same size. Over a quarter and across a team this tends to average out, but you should be clear that the output is an estimate.
The CapEx/OpEx split Delimetrics produces is a modeled estimate for planning and finance conversations. It is not an accounting record and is not audit-grade. Confirm your capitalization policy and the resulting numbers with your auditors before using them in financial reporting.
Getting started
- Agree the capitalizable rules with finance and write them down.
- Add one capitalizable flag in Jira; default bugs and support to OpEx.
- Set a fully loaded per-team cost.
- Reconcile one quarter against what finance booked, then standardize the method.
Done well, the CapEx/OpEx split stops being a quarterly scramble and becomes a number you can trust and explain. That is the difference between defending a spreadsheet and pointing to your actual work.