Applying ASU 2025-06: Mapping Capitalization to Your Backlog

ASU 2025-06 replaced the old stage gates with a probable-to-complete threshold: you capitalize once a project is funded and probable to complete, with no significant development uncertainty left. That’s a better fit for agile — but it moves the capitalization decision out of the accounting calendar and into your delivery process. The events that gate capitalization happen in your backlog. The hard part is reading them.

The three signals that gate capitalization

The standard’s test maps to three things that happen in any delivery process:

1. Funding committed — management has authorized and committed to funding. In your tools, that’s a funded epic, an approved budget line, or a signed vendor contract — a discrete, dated event. 2. Requirements stabilized — the significant performance requirements are identified and not being substantially revised. That’s an epic whose scope has settled: defined stories, set acceptance criteria, churn dropping sprint to sprint. 3. Novelty resolved — any significant development uncertainty from novel or unproven technology has been resolved through coding and testing. That’s a spike or proof-of-concept closed, the risky approach validated in working code.

Capitalization begins at the latest of these — the point where funding is committed and the project is genuinely probable to complete. Everything before it is expensed.

Mapping the standard to your backlog

The same logic tells you when to stop: capitalization ceases when the software is substantially complete and ready for its intended use — a release, or the epic closing.

A worked timeline

Take an epic to build a new billing feature with a novel tax-calculation approach:

• Jan 15 — the epic is funded. (Funding ✓)
• Jan–Feb — discovery sprints reshape the scope as the team learns what’s needed. (Requirements still moving — expense)
• Mar 1 — a spike proving the tax-calculation approach closes; the technical risk is burned down. (Novelty resolved ✓)
• Mar 10 — scope settles; the significant stories are defined and stable. (Requirements stabilized ✓)

Capitalization begins March 10, when all three are met. The January-to-early-March discovery and spike work is expensed; the build from March 10 to release is capitalized. Under the old three-stage model you’d have argued about when the “application development stage” began — here, the backlog tells you. (For the broader picture, see capitalizing costs in Agile.)

Keeping it auditable

The new standard raises the documentation bar: you need a contemporaneous record of when funding was committed, when requirements stabilized, and when novelty was resolved. Reconstructing those dates a year later, from memory, is exactly what an auditor will challenge. The good news is your delivery tooling already records them — if you capture the funding event, the spike resolution, and the scope-stabilization point as they happen.

Doing it without manual timesheets

Asking engineers to log hours against capitalization categories defeats the purpose — it produces estimates, late, that no auditor trusts. Quantify reads the signals already in your issue tracker — epic funding, status transitions, sprint membership, spike resolution — and produces the capitalizable-vs-expensed split per epic, with an audit trail tracing each dollar back to the work and the date. The backlog becomes the evidence, and nobody fills a timesheet.