Capitalizing Software Development Costs in Agile

Agile changed how software gets built — continuous delivery, evolving backlogs, work that flows instead of marching through phases. It also broke an assumption baked into cost-capitalization rules: that development happens in tidy, sequential stages you can capitalize at a gate. If you’re capitalizing development costs for a team that works in sprints or on a Kanban flow, the standards don’t map cleanly onto how your engineers actually work. This guide closes that gap — which Agile work is capitalizable, how to map it to U.S. GAAP, and how to hold an audit trail without burying engineers in timesheets.

How software capitalization works, in brief

Capitalizing development costs means recording certain engineering expenses — salaries, contractor fees, tooling — as a long-term asset on the balance sheet rather than expensing them in the period they’re incurred. What qualifies depends on the software’s purpose and the stage of work:

• Internal-use software (most SaaS and in-house tools) follows ASC 350-40: expense the preliminary project stage, capitalize the application development stage once the project is funded and probable to complete, then expense post-implementation.
• Software to be sold follows ASC 985-20, which capitalizes costs only after technological feasibility is established.

For the full breakdown by category, see the software capitalization guide. The hard part in Agile isn’t the rule — it’s mapping it onto work that doesn’t move through phases.

Why Agile breaks the stage model

Three frictions show up every time:

1. No phase gates. Planning, building, and testing happen concurrently inside each iteration, so there’s no moment where a “phase” ends and capitalization cleanly begins. The decision has to be made at a finer grain — closer to the individual ticket. 2. Changing scope. Backlogs are reprioritized, stories get reworked, spikes explore dead ends. “Probable future economic benefit” — the bar for capitalizing — becomes a judgment you re-make as work evolves, not a one-time gate. 3. Shared effort. Cross-functional teams mix capitalizable and non-capitalizable work in the same sprint. Feature development qualifies; backlog refinement, standups, and retrospectives don’t. Attribution gets granular fast.

Map Agile work to capitalization

The cleanest way to make this auditable is to map your workflow — issue types, statuses, and ceremonies — to capitalize/expense rules once, as written policy, then apply it the same way every period. The concepts below hold in any issue tracker — Jira, Azure DevOps, Linear, GitHub Projects.

Work item	Treatment	Why
Feature stories/tasks building new functionality (work underway)	Capitalize	Application-development-stage work that creates the asset
Spikes, discovery, prototypes	Expense	Preliminary-stage research, before the project is probable and funded
Sprint planning, backlog refinement, retrospectives	Expense	Project management and learning, not building the asset
Bug fixes on a capitalized feature, pre-release	Capitalize (prorate)	Part of getting the asset ready for its intended use
Maintenance and bug fixes after release	Expense	Post-implementation stage
Refactoring / technical debt	Case-by-case	Capitalize if it adds functionality; expense if it only maintains

Map costs to epics, not sprints. An epic is closer to a discrete asset: it spans several sprints and gets capitalized once it’s probable to complete and intended for use, which is exactly the ASC 350-40 trigger.

A worked example

An epic to ship a new billing module runs four sprints with three engineers, at a fully-loaded cost of ~$60k per sprint ($240k total). Sprint 1 is discovery-heavy — spikes and prototypes — so most of it is expensed. Sprints 2–4 are feature build, with ~15% of effort going to refinement, standups, and retros that don’t capitalize:

	Capitalized	Expensed
Sprint 1 (discovery)	$20k	$40k
Sprints 2–4 (build)	$51k each	$9k each
Epic total	~$173k	~$67k

The ~$173k becomes the billing-module asset, amortized over its useful life; the ~$67k hits the income statement now. The numbers are illustrative — the point is that the split is defensible because every dollar traces back to specific tickets and statuses.

Track it without manual timesheets

The mapping only works if you can attribute engineering time to the right work items — and asking engineers to fill in timesheets defeats the purpose, producing estimates no auditor trusts. Quantify derives the split from activity already in your issue tracker — issue types, status transitions, sprint membership — and produces capitalizable-vs-expensed numbers per epic, with an audit trail tracing every dollar back to the work behind it. That’s the difference between a capitalization policy on paper and one that holds up under review.