Software capitalization without timesheets: ticket-share allocation explained
The standard objection to software capitalization is that doing it properly requires time tracking, and time tracking is something most engineering teams have rightly resisted. This article explains an alternative: allocating cost by the share of delivered work that is capitalizable. It is the method Delimetrics uses, and the goal here is to explain exactly how it works and why it is a defensible basis for an estimate.
The problem with timesheets
Time tracking looks precise because it produces numbers down to the hour. But for software development that precision is largely an illusion. Engineers do not log time as they work; they reconstruct it later, round it, and slot it into categories that rarely match how the work actually felt. The data is expensive to collect, it erodes goodwill, and it is not as accurate as it appears. Building a capitalization estimate on top of it inherits all of those weaknesses.
Capitalization does not actually require per-hour effort data. It requires a rational, consistent way to divide a known cost between qualifying and non-qualifying work. Ticket-share allocation provides exactly that.
The method in one formula
CapEx estimate = period cost × (capitalizable tickets delivered ÷ all tickets delivered). The remainder is treated as OpEx.
Read it plainly: take the fully loaded cost of a team over a period, and split it in proportion to how much of the work they completed in that period was capitalizable. If a team cost a known amount and 60% of the tickets they finished were flagged capitalizable, the estimate capitalizes 60% of the cost.
The three inputs
- Period cost. A fully loaded per-team cost — salaries, benefits, allocated overhead — for the window in question. This comes from finance, not from Jira. Delimetrics stores a per-team cost and scales it to whatever period you view.
- Capitalizable classification. A flag on each Jira issue indicating whether the work qualifies under your policy. Read directly from a Jira Cloud custom field.
- Delivered work. The tickets actually completed in the period, so you allocate against work that happened rather than work that was merely planned.
Why count tickets and not story points?
Ticket count is the most robust signal you have. Story points are estimates made before the work, they are inconsistent across teams, and they drift over time as teams recalibrate. Raw ticket count is observable, hard to game in aggregate, and stable. You are not trying to measure effort precisely — you are estimating a ratio. A simple, transparent denominator beats a sophisticated one that nobody trusts.
The key assumption is that, across a team and a quarter, the average size of capitalizable tickets is roughly comparable to the average size of non-capitalizable tickets. For most teams this holds well enough. Where it does not — for example, if maintenance work is systematically tiny and feature work is large — you should know that and discuss it with finance.
Why this is defensible
Accounting guidance generally calls for a rational and systematic allocation method applied consistently. Ticket-share allocation checks every box:
- Objective. It is based on completed work classified against a written policy, not on memory or judgment after the fact.
- Consistent. The same formula runs every period, so trends are comparable.
- Transparent. Every figure decomposes into a specific list of tickets you can inspect and reconcile.
- Low-overhead. Engineers do nothing beyond their normal workflow except occasionally setting a flag.
Compared with reconstructing timesheets, this is the more honest of the two estimates, and it produces a clearer audit trail.
The number this method produces is a modeled estimate intended for planning and for the conversation with finance. It is not an accounting record and not audit-grade. Confirm your capitalization policy, your classification rules, and the resulting figures with your auditors before relying on them for financial statements.
Making it work in practice
Start with the classification, because that is where accuracy lives. Add a single capitalizable field in Jira, default bugs and support tickets to non-capitalizable, and have teams flag only the exceptions. Agree the rules with finance up front. Then pick one team and one closed quarter and reconcile the estimate against what was actually booked — that builds confidence in the ratio before you scale it.
For the wider context, see how this fits into the CapEx versus OpEx picture and the full Jira capitalization workflow.
Key takeaway: you do not need timesheets to capitalize software. A consistent, transparent ticket-share allocation against a known cost pool is a defensible basis for an estimate — and it traces back to real work, not reconstructed hours.