Internal Use Software Capitalization: ASU 2025-06 Explained
If you’ve ever tried to apply the 1998 internal-use software rules to a modern agile sprint, you know the pain. Your engineers ship in two-week cycles, but Subtopic 350-40 asks you to identify “preliminary project,” “application development,” and “post-implementation” stages that no longer exist. That mismatch is finally fixed. The FASB’s ASU 2025-06, issued September 18, 2025 and updated February 17, 2026, modernizes internal use software capitalization for every entity that develops software for its own use — from Fortune 500 SaaS providers to mid-market companies building internal portals.
At SW Accounting & Consulting Corp, we’ve been helping clients stress-test their software cost policies ahead of adoption. The biggest shift isn’t the threshold itself — it’s the judgment framework around it. This guide breaks down what’s actually different, what hasn’t changed, and what your controllership needs to do now.
What is ASU 2025-06 and why did the FASB issue it? 📋
ASU 2025-06 amends ASC Subtopic 350-40 to eliminate the waterfall-era project stages and codify agile-compatible cost capitalization rules.
The original Subtopic 350-40 was written when software development meant a linear waterfall: requirements, design, build, test, deploy. Each stage gated the next. But today, the vast majority of teams use agile — overlapping sprints, continuous integration, scope that evolves sprint by sprint. Preparers and practitioners told the Board the old model no longer fit reality, and investors wanted more transparency around capitalized software costs. ASU 2025-06 is the Board’s answer.
The ASU also retires Subtopic 350-50 (website development costs), folding the remaining relevant guidance into 350-40 with new examples. One unified location, one framework.
In our practice, we’ve seen capitalization policies where teams manually “assign” each sprint to a legacy stage just to satisfy the old guidance — creating documentation overhead without economic meaning. ASU 2025-06 removes that performative step entirely. You’re now free to focus on the actual decision: is the project likely to complete, and is funding committed?
When does internal use software capitalization begin under the new rules? ⏱
Capitalization begins when (1) management has authorized and committed to funding the project, and (2) it is probable the project will be completed and used for its intended function.
These two criteria already existed in paragraph 350-40-25-12, but they were buried behind the project-stage gates. Now they’re the sole trigger. Until both are met, all software development costs are expensed as incurred — same as before.
The Board explicitly anchored the word “probable” to the ASC Master Glossary definition: “the future event or events are likely to occur.” This matters because prior guidance (SOP 98-1, since superseded) had pointed to the old CON 6 definition — which was closer to “can be reasonably expected.” The new, higher bar is narrower. If your documentation template still uses “reasonably expected” language, update it.
What is “significant development uncertainty” under ASU 2025-06? ⚠
Significant development uncertainty is a new concept: if it exists, the probable-to-complete threshold cannot be met, and costs stay in expense.
The ASU says development uncertainty is significant if either of two factors is present:
| Factor | What to assess |
|---|---|
| Novel or unproven functions/features | Does the software rely on functions, features, or technological innovations not yet proven through coding and testing? |
| Unsettled performance requirements | Have the software’s significant “performance requirements” — what the software needs to do — been determined and no longer subject to substantial revision? |
Practically, greenfield AI features, novel ML pipelines, and anything that depends on breakthrough research will likely flunk factor one. Straightforward configuration of a mature third-party platform usually won’t. The ASU explicitly notes that “limited effort” may be enough for some projects — not every analysis has to be a novel.
What did NOT change about internal use software capitalization? 🔒
The ASU is deliberately narrow. It does not alter external-use software accounting, what costs can be capitalized, or when capitalization ceases.
- External-use software (software to be sold or licensed to customers) — Subtopic 985-20 stays exactly as it was.
- Eligible cost types — data conversion, training, and software maintenance continue to be expensed as incurred. Direct payroll, direct materials, and external direct costs of services to develop the software continue to be capitalizable.
- End of capitalization — still when the software is “substantially complete and ready for its intended use.”
- Enhancements and upgrades — same rules, capitalize if they add functionality, expense routine maintenance.
Many expected larger disclosure changes — like an annual rollforward of capitalized software. The FASB considered them and declined. The final ASU only clarifies that entities must provide the Subtopic 360-10 disclosures for all capitalized internal-use software. If you weren’t consistent on those before, this is your cue.
How does ASU 2025-06 affect SaaS and cloud arrangements? ☁
The amendments indirectly tighten the alignment between software licensed to customers and software sold only via SaaS — reducing divergent accounting outcomes for economically similar products.
Historically, a company that licensed its software followed Subtopic 985-20, while the same company offering the same capabilities purely as SaaS followed Subtopic 350-40. The cost-capitalization mechanics differed meaningfully. By modernizing 350-40 and removing the stage gates that created most of the divergence, the FASB narrowed the gap. This is not a unified model — 985-20 and 350-40 remain separate — but the day-to-day decisions will feel more consistent across delivery modes.
What should controllers and CFOs do now? ✅
Start with three practical steps: refresh your capitalization policy document, retrain project managers on the new threshold, and identify in-flight projects that may cross the probable-to-complete line under the new criteria.
- Policy refresh. Replace all references to “preliminary project / application development / post-implementation” stages. Add language defining “probable” by Master Glossary and “significant development uncertainty” using the two ASU factors.
- PM training. Your software PMs are the ones producing the evidence of funding commitment and completion probability. Make sure they know what specific artifacts (approved business cases, steering committee minutes, architectural readiness reviews) will support capitalization.
- In-flight review. Projects that failed prior project-stage logic may now meet probable-to-complete, and vice versa. Run a one-time review of every active software project and confirm its capitalization status against the new criteria.
- Disclosures. Confirm your Subtopic 360-10 disclosures capture all capitalized internal-use software correctly. If you previously excluded items or aggregated inconsistently, fix it before adoption.
Frequently Asked Questions 🗂
For the authoritative ASU text and the FASB’s basis for conclusions, start with the FASB Accounting Standards Updates page. The KPMG handbook Software and website costs — sections 3.2.60, 3A.2.10, and 3A.2.20 — provides practical interpretive guidance on agile projects and defining a software project.
Questions on how ASU 2025-06 affects your capitalization policy, in-flight projects, or SOX documentation? Reach out to SW Accounting & Consulting Corp — our technical accounting team helps clients align GAAP, audit readiness, and engineering reality.
