ASU 2025-06 Worked Examples: When Does Capitalization Start?

ASU 2025-06‘s probable-to-complete threshold sounds abstract until you see it applied. FASB published three illustrative examples; here they are in plain product and engineering terms, each showing exactly when capitalization starts — and why.

Example 1 — Configuring proven software

A company implements an established third-party ERP, choosing among its pre-built features and configuring them. Nothing here is novel or unproven — you’re assembling software that already works, not inventing new capability. So there’s no significant development uncertainty, and funding is committed when the contract is signed.

Capitalization starts at contract signing. The configuration and implementation work is capitalized from the outset.

Takeaway — configuring proven software means little or no uncertainty, so you capitalize early.

Example 2 — A new product with shifting scope

A company funds a new mobile app on February 1. But the team is still discovering what the app needs to do, iterating on user feedback — the significant performance requirements aren’t settled. Because the requirements are still being substantially revised, the probable-to-complete threshold isn’t met. The team keeps iterating through November 30; on December 1, the requirements stabilize.

Capitalization starts December 1. The February-to-November discovery and iteration is expensed; the build that follows is capitalized.

Takeaway — funded, but scope still moving, so expense until the significant requirements settle.

Example 3 — Novel, unproven technology

A company funds a project on February 1, 20X1 to build something genuinely novel — but whether the technology can be made to work isn’t yet known. That novelty is significant development uncertainty, and it can only be resolved through coding and testing. The team doesn’t crack it until March 1, 20X3 — more than two years later.

Capitalization starts March 1, 20X3. Over two years of R&D-like spend is expensed first; only once the technology is proven does the build become capitalizable.

Takeaway — novel or unproven technology means you expense until it’s proven in working code.

How this differs from the old model

Under the old three-stage model, the question was “has the application development stage begun?” — and in Examples 2 and 3 you’d likely have capitalized earlier. The new threshold defers capitalization until funding is committed, completion is probable, and significant development uncertainty is resolved:

The routine case (Example 1) barely moves; the novel and uncertain cases shift more cost to expense, earlier.

The common thread

Every example turns on the same three signals — funding committed, requirements stabilized, novelty resolved — and capitalization begins at the latest of them. Applying ASU 2025-06 shows how to read those signals from your backlog, and Quantify produces the dated capitalizable-vs-expensed split automatically.