What ASU 2025-06 Means for SaaS Companies

SaaS companies are the group ASU 2025-06 affects most. Because hosted software you build to deliver a service is internal-use software under ASC 350-40, the standard applies squarely to your core product development — and it changes when, and how much, you capitalize.

Expect more early expensing

The new probable-to-complete threshold is gated by significant development uncertainty: you can’t capitalize while a feature’s technology is unproven or its requirements are still churning. New SaaS features live in exactly that zone early on. FASB expects capitalization to decrease for cloud and SaaS development, bringing it closer to how externally-sold software is treated. Exploratory work you might have capitalized under the old “application development stage” may now be expensed until the feature is funded, scoped, and de-risked.

Define your unit of account

The standard deliberately doesn’t define the “software project” — it could be a product, a module, or a major feature. That judgment is yours, and it shapes everything: too broad a unit hides uncertain sub-projects inside a probable one; too narrow creates overhead. Pick a level — often the epic or initiative — and apply it consistently.

The documentation bar rises

Trading rigid stages for judgment means you need a contemporaneous record of three things: when funding was committed, when the significant performance requirements stabilized, and when novel technology was resolved through coding and testing. That evidence lives in your product and engineering tooling, not your ledger — see applying ASU 2025-06 for the backlog mapping.

Finance and engineering have to talk

None of this works if finance writes the policy in a vacuum. Engineering knows when a spike resolved the risk and when scope settled; finance owns the schedule. The teams that adopt smoothly build one repeatable, evidence-based process — and Quantify supplies the evidence from the issue tracker, with no manual timesheets.