FASB ASU 2025-06: Internal-Use Software Cost Rules Modernized
The rules for capitalizing internal-use software costs were written in 1998 — back when software was built in rigid, sequential “waterfall” stages. Almost nobody develops that way anymore. FASB ASU 2025-06 rewrites Subtopic 350-40 for the agile era, replacing the stage-based capitalization trigger with a single “probable-to-complete” threshold. This guide covers what changed, what didn’t, and how to prepare.
At SW Accounting & Consulting Corp, we help Los Angeles area companies — especially software, SaaS, and tech-enabled businesses — apply new FASB standards. Below: the old vs. new capitalization trigger, the website-cost change, what stays the same, and the effective date and transition.
Why did the FASB update this? 🕰
The internal-use software guidance dated to 1998 and assumed a “waterfall” development method — discrete, sequential stages (preliminary project, application development, post-implementation/operation), where work moved to the next stage only after finishing the prior one.
Today most software is built using agile (iterative and flexible) methods that don’t fit neatly into those stages. ASU 2025-06 modernizes the model for how software is actually developed — and for many entities it more closely aligns the accounting for software developed on a software-as-a-service (SaaS) basis with software licensed to customers.
The big change: when capitalization begins 🎯
ASU 2025-06 eliminates ALL references to project development stages in Subtopic 350-40. Regardless of method — agile, waterfall, hybrid, or otherwise — entities now rely on a single trigger to start capitalizing.
| Old (1998 model) | New (ASU 2025-06) | |
|---|---|---|
| Trigger to capitalize | Tied to completing the “preliminary project stage” and entering the application development stage | Capitalize when BOTH: (1) management has authorized and committed to funding the project, AND (2) it is “probable” the project will be completed and the software will perform its intended function |
| Development method | Assumed waterfall/sequential stages | Method-agnostic — agile, waterfall, or hybrid all use the same threshold |
This is the “probable-to-complete” threshold. Because it now carries more weight, the ASU enhances the guidance around it and adds new examples in Subtopic 350-40 to illustrate how to apply it.
With the project stages gone, the timing of capitalization hinges on when funding is committed and the project becomes “probable” to complete and function as intended. That’s a judgment call — and for agile projects that pivot or get abandoned, it matters a lot. Document the funding authorization and the basis for the probability conclusion contemporaneously; it’s now the audit focal point.
Website development costs folded in 🌐
ASU 2025-06 eliminates the separate Subtopic 350-50 for website development costs, relocating the remaining relevant guidance into Subtopic 350-40 and adding a new example. Website development costs now follow the same internal-use software framework.
What did NOT change ✅
- External-use software — the accounting for software to be sold or licensed (development costs) is unchanged.
- Which costs can be capitalized — items like data conversion/migration, training, and software maintenance continue to be expensed as incurred.
- When capitalization stops — still when the software is “substantially complete and ready for its intended use.”
In other words, ASU 2025-06 changes WHEN you start capitalizing internal-use software, not WHAT you capitalize or when you stop.
Effective date & transition 📅
- Effective — all entities, annual and interim periods, for fiscal years beginning after December 15, 2027.
- Early adoption — permitted in any interim or annual period for which financial statements have not yet been issued (or made available) as of the beginning of the fiscal year.
- Transition — three options: (1) retrospective, (2) prospective to software costs incurred after the adoption date (on existing in-process projects or new ones), or (3) modified prospective. Transition disclosures under Topic 250 (accounting changes) are required.
Frequently asked questions
When both conditions are met: management has authorized and committed to funding the project, and it’s probable the project will be completed and the software will perform its intended function — the “probable-to-complete” threshold. Project development stages no longer drive the timing.
Yes — it’s the whole point. The standard is method-agnostic, so agile, waterfall, and hybrid projects all use the same probable-to-complete threshold rather than the old stage-based model.
No. ASU 2025-06 addresses internal-use software (Subtopic 350-40). The accounting for external-use software (sold or licensed) development costs is unchanged.
All entities, annual and interim periods, for fiscal years beginning after December 15, 2027. Early adoption is permitted, and entities can transition retrospectively, prospectively, or on a modified prospective basis.
How can SW Accounting help? 💼
At SW Accounting & Consulting Corp, we help LA-area software, SaaS, and tech-enabled companies adopt ASU 2025-06 — reworking capitalization policies around the probable-to-complete threshold, documenting funding authorization and probability judgments for agile projects, folding in website costs, choosing a transition method, and preparing Topic 250 disclosures. If you build software internally, we’ll get your policy and documentation ready before the 2027 effective date.
📩 Schedule an ASU 2025-06 readiness review
Disclaimer: This article is for informational purposes only and is not accounting, tax, or legal advice. Always consult a qualified professional regarding your specific facts. Primary sources: FASB Accounting Standards Update No. 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements; FASB Accounting Standards Codification Subtopic 350-40 (and former Subtopic 350-50); ASC Topic 250 (Accounting Changes and Error Corrections).
