How to capitalize software development costs in Jira without time tracking

Most engineering organizations already track their work in Jira. Far fewer track time. That gap is the single biggest reason software capitalization feels painful: finance asks "how much of last quarter's engineering spend was capitalizable?" and the honest answer is a shrug, a spreadsheet, and a round of guessing. You do not need timesheets to answer that question. You need a defensible way to allocate cost to the work your team already records in tickets.

This guide walks through how to estimate capitalized software development costs directly from Jira, why a ticket-share approach holds up to scrutiny, and where the boundaries of the method are.

Why timesheets are the wrong tool for the job

Time tracking promises precision but rarely delivers it for software teams. Engineers fill in timesheets retroactively, round to the nearest half day, and miscategorize work because the categories never quite fit. The result is data that looks granular but is built on guesses. Worse, mandatory time tracking is a tax on the exact people you most want focused on building.

Capitalization does not actually require knowing how many minutes went into a feature. It requires a reasonable, consistently applied basis for splitting a known cost pool between work that qualifies for capitalization and work that does not. Jira tickets, when classified properly, give you that basis without the overhead.

The ingredients you need

To estimate capitalizable cost from Jira, you need three things:

• A cost pool. The fully loaded cost of the team over a period — salaries, benefits, and the overhead your finance team already allocates to engineering. This lives outside Jira.
• A classification of work. Which tickets represent capitalizable activity (typically development of new functionality and significant enhancements during the application development stage) versus work that is expensed as incurred (maintenance, bug fixing, planning, research).
• A delivered-work signal. Which tickets were actually completed in the period, so you are allocating against work that happened rather than work that was merely planned.

The ticket-share method

The core idea is simple. If a team cost a known amount in a period, and a known share of the work they delivered was capitalizable, then a defensible estimate of the capitalized portion is:

This is exactly how the Delimetrics software capitalization dashboard models it. Each team's per-period cost is scaled to the window you are viewing, then split by that team's capitalizable ticket share. You get a per-team CapEx and OpEx figure that moves as your actual work mix moves, with no one filling in a timesheet.

Setting up the classification in Jira

The quality of the estimate depends entirely on the quality of your classification. The good news is that you can do this with a single custom field.

1. Add a capitalizable flag. A custom field (a checkbox or a single-select) on issues that indicates whether the work qualifies. Delimetrics reads this field directly from Jira Cloud.
2. Agree on the rules with finance. Decide which issue types and which stages of work are capitalizable under your accounting policy, and write it down. New feature development is usually in scope; bug fixes and maintenance usually are not.
3. Default the obvious cases. Bugs and support tickets can be defaulted to not capitalizable. Teams then only flag the exceptions, which keeps the overhead near zero.
4. Review at the team level, not the ticket level. You are estimating a ratio, not auditing individual line items. A handful of misclassified tickets barely moves a quarterly percentage.

Why ticket-share is defensible

Accounting standards generally require that capitalized amounts be based on a rational and systematic method, consistently applied. A ticket-share allocation meets that bar: it uses an objective, observable signal (completed work, classified against a written policy) and applies the same formula every period. It is far more transparent than after-the-fact timesheet estimates, because every number traces back to a specific set of tickets you can inspect.

It is, however, an estimate. Tickets are not all the same size, and ticket count is a proxy for effort. For most teams this averages out across a quarter, but you should understand the assumption.

From estimate to conversation

The practical value of this approach is speed. Instead of a quarterly fire drill, you have a number that updates continuously and a clear audit trail of which tickets drove it. That changes the finance conversation from "trust this spreadsheet" to "here is the work, here is the policy, here is the math." For more on the underlying distinction, see our overview of CapEx vs OpEx in software development.

Start by getting the classification field clean for one team and one quarter. Once the ratio looks right and finance agrees with the rules, rolling it out across the org is just configuration.