ASU 2025-06: The New Internal-Use Software Capitalization Rules

In September 2025, FASB issued ASU 2025-06, the biggest change to internal-use software accounting in decades. It scraps the three-stage model — preliminary, application-development, post-implementation — that decided when you could capitalize software costs, and replaces it with a principles-based threshold. It takes effect for annual periods beginning after December 15, 2027 (fiscal year 2028 for calendar-year companies), with early adoption permitted now.

It matters because the old model never fit how software actually gets built. FASB said so directly: teams moved from waterfall to agile, and the stage gates stopped lining up with iterative development. ASU 2025-06 is the fix — and if you capitalize software costs, it changes how, when, and how much.

The three-stage model is gone

Under the old rules (ASC 350-40), capitalization keyed off which of three sequential stages a cost fell in: expense the preliminary stage, capitalize the application-development stage, expense post-implementation. ASU 2025-06 removes those stages entirely — the terms “preliminary project stage” and “application development stage” are deleted from the standard.

The new test: funding plus probable-to-complete

Capitalization now begins when both of these are true:

1. Management has authorized and committed to funding the project. 2. It is probable the project will be completed and the software used for its intended function — the “probable-to-complete” threshold.

The first is a concrete event: a budget approval, a funded epic, a signed vendor contract. The second is a judgment about whether the project will actually ship and work.

Significant development uncertainty

The probable-to-complete prong has a gate. If significant development uncertainty exists, the threshold isn’t met until that uncertainty is resolved. It exists if either:

• The technology is novel or unproven, and that uncertainty hasn’t been resolved through coding and testing; or
• The significant performance requirements aren’t identified yet, or keep getting substantially revised.

In plain terms: you can’t capitalize while you’re still proving out risky technology, or still discovering what the software needs to do. Capitalization starts once the risky unknowns are resolved and the requirements stabilize.

Before and after

	Old (three-stage model)	ASU 2025-06
Trigger	Which project stage the cost falls in	Funding committed + probable-to-complete
Key terms	Preliminary / application-development / post-implementation	Probable-to-complete; significant development uncertainty
Website costs	Separate rules (ASC 350-50)	Folded into ASC 350-40
Fit with agile	Poor — stages don’t match iterative work	Designed for it

What it means for software teams

This is where the change gets practical, because the new test maps onto how software actually gets built:

• Funding committed — a real, documentable event: the budget approval or the epic funding decision.
• Requirements stabilized — the significant features are defined and not churning. While you’re still iterating on what to build, you expense; once scope settles, you capitalize.
• Novelty resolved — the spike or proof-of-concept has burned down the technical risk through coding and testing.

So the early, exploratory work — discovery, prototyping, de-risking — is expensed; the build that follows a funded, scoped, de-risked project is capitalized. The catch is evidence: the standard demands a defensible, contemporaneous record of when each of those happened. That record lives in your delivery tooling — roadmaps, epics, sprint and backlog state — which finance has historically not been able to read. Capitalizing costs in Agile covers the mapping; Quantify produces the record straight from your issue tracker.

Website costs, SaaS, and what isn’t changing

• Website development costs — the old ASC 350-50 rules are superseded and folded into the same internal-use model.
• SaaS and cloud platforms — FASB expects less capitalization for SaaS and cloud development under the new threshold, bringing it closer to how licensed software is treated.
• Software you build to sell — unchanged. ASC 985-20 is outside ASU 2025-06’s scope; technological feasibility still governs there.

Timing and transition

It’s effective for annual reporting periods beginning after December 15, 2027 — fiscal year 2028 for calendar-year companies — with early adoption permitted now. Three transition methods are available (prospective, modified, and retrospective); the modified approach derecognizes in-process costs that met the old rules but not the new ones, through an adjustment to opening retained earnings. Capitalized internal-use software also picks up PP&E-style disclosures under ASC 360-10. Companies weighing early adoption are already working through these.