ASU 2025-06 - Modernizing the Accounting for Software Costs

Background and Purpose

‍
ASU 2025-06 was issued to modernize the accounting guidance for internal-use software – ASC 350-40.¹ The previous rules relied on a strict stage-based development model that divided projects into preliminary, application development, and post-implementation phases.² While this structure worked for older development methods, it became increasingly difficult to apply as companies shifted from a traditional waterfall approach to agile and iterative development. As a result, the guidance often failed to reflect how software is developed today. The purpose of the update is to create a more principles-based and flexible framework that aligns with modern development practices while improving consistency and comparability across entities. ASU 2025-06 does not affect software developed for sale, lease, or marketing, which remains subject to ASC 985-20.⁵

Removal of the Stage-Based Development Model

In software development, two primary development approaches have traditionally been used: waterfall and agile. The waterfall methodology follows a linear and sequential process in which each stage must be completed before the next stage begins. Projects move through clearly defined phases, such as planning, design, development, and testing, that progress in an explicit order. In contrast, agile development is iterative and flexible. Work is divided into smaller development cycles, often called sprints, where development and testing occur continuously and adjustments can be made as requirements evolve. Because agile allows for ongoing changes and collaboration throughout the project, it does not align well with rigid, sequential development stages, which contributed to the challenges companies faced when applying the prior stage-based accounting guidance.

One of the most significant changes in ASU 2025-06 is the removal of the formal stage-based development model.¹ Under prior GAAP, capitalization depended heavily on identifying which stage costs were incurred in.² The updated guidance removes all references to specific and sequential development stages and is neutral to different development methods, including agile, waterfall, and future approaches.¹

Source: ProjectManagement.ie, “Waterfall vs. Agile.”

Probable-to-Complete Recognition Threshold

‍
Instead of relying on development stages, ASU 2025-06 introduces a new capitalization trigger based on probability. Capitalization begins only when management has authorized and committed to funding the project and it is probable (a likelihood greater than 75%) that the software will be completed and used to perform its intended function. ¹

Development Uncertainty Constraints

‍
The update also introduces an important limitation related to uncertainty. Even if a project has been approved and funded, costs cannot be capitalized if significant uncertainty exists. The guidance identifies two primary sources of uncertainty: whether the software involves novel, unique, or unproven technology that has not yet been validated through coding and testing, and whether the entity has clearly defined and stabilized the software’s significant performance requirements. ¹

Capitalization

Once the probable-to-complete threshold is met, capitalization applies only to costs incurred from that point forward. Costs incurred before the threshold cannot be retroactively capitalized. From that point on, qualifying costs, including direct labor and external development costs, are capitalized as they are incurred. If management later determines that completion is no longer probable, capitalization must stop immediately. Previously capitalized costs are then evaluated for impairment, and if the project is abandoned, the remaining balance is written off in the period the decision occurs.⁷

Under the new guidance, this process relies more heavily on management judgment than the prior stage-based model. Companies must continually assess whether the project remains probable to complete and whether significant development uncertainties have emerged. If substantial uncertainty arises, such as unresolved technical challenges or unstable performance requirements, entities may need to pause capitalization until those uncertainties are resolved.⁷

Practical Implications and Capitalization Outcomes

From a practical standpoint, most companies are not expected to experience a significant change in the total amount of internal-use software costs they capitalize. Companies developing software for cloud computing or SaaS arrangements, however, may see a modest decrease in capitalization. Under the prior stage-based model, some costs for these projects may have been capitalized once development entered the application development stage, even though SaaS platforms are often developed through ongoing enhancements, testing, and iterative changes rather than through one clearly defined project. By contrast, on-premises software is more often associated with a defined implementation project and a clearer point at which the software is expected to be completed and placed into use. Under ASU 2025-06, capitalization begins only once management concludes the software is probable to be completed and used as intended, which may cause capitalization to begin later for many SaaS-related projects than for more traditional on-premises software.

For example, consider a company developing a new feature for its internal cloud-based customer management system. Unlike a traditional on-premises implementation, which often has a more defined project scope and completion point, this type of SaaS-related development may involve months of experimenting with architecture, testing integrations, and refining system requirements. Under the previous stage-based model, the company may have begun capitalizing some of these costs once development formally entered the application development stage. Under ASU 2025-06, however, those early costs would likely be expensed until management concludes that the feature is probable to be completed and used as intended. As a result, capitalization may begin later in the development process, which can slightly reduce the total amount of costs capitalized for projects that evolve through continuous updates and experimentation.

Consolidation of Website Development Guidance

‍
Another notable change in ASU 2025-06 is the consolidation of website development guidance into the internal-use software standard. Previously, website costs were addressed separately, which led to inconsistency in practice. Under the updated guidance, website development costs follow the same capitalization framework as other internal-use software costs.¹

Clarification of Specific Cost Types

‍
Under prior guidance, ASC 350-40 did address certain categories of costs such as enhancements, maintenance, training, and data conversion. However, the rules were tied closely to the stage-based development model, which sometimes made it difficult to apply consistently in modern development environments. ASU 2025-06 clarifies that enhancements should be capitalized only when they add significant new functionality, while routine maintenance, training, and most data conversion activities continue to be expensed as incurred. In this respect, the treatment is conceptually similar to property, plant, and equipment, where expenditures that extend functionality or capability are capitalized while routine maintenance is expensed.¹

Disclosure Requirements

‍
The amendments require entities to apply the disclosure requirements in Subtopic 360-10, Property, Plant, and Equipment, to all capitalized internal-use software costs. This change affects only the disclosure framework and does not reclassify internal-use software as PPE. Instead, the guidance requires companies to provide disclosures similar to those used for long-lived assets, regardless of how the software is presented on the balance sheet. At the same time, the intangible asset disclosure requirements in Subtopic 350-30 no longer apply to internal-use software.¹

Effective Date and Transition Approaches

‍
ASU 2025-06 is effective for annual periods beginning after December 15, 2027, with early adoption permitted. No significant differences exist between public and private companies. Entities may choose among three transition approaches: a prospective approach, a modified transition approach that includes a cumulative-effect adjustment for certain projects, or a retrospective approach.¹

Conclusion

‍
Overall, ASU 2025-06 represents a meaningful modernization of internal-use software accounting.¹ Operationally, companies may need to revisit the processes they currently use to account for software costs. Since capitalization now depends on management’s judgement, entities may need stronger documentation and coordination to support management’s judgement decisions. By removing rigid development stages and introducing a probability-based capitalization threshold, the guidance better aligns accounting outcomes with the economics of modern software development practices.

¹ Financial Accounting Standards Board. (2025).
Accounting Standards Update No. 2025-06: Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40).
https://www.fasb.org/page/document?pdf=ASU+2025-06.pdf&title=Accounting+Standards+Update+2025-06—Intangibles—Goodwill+and+Other—Internal-Use+Software  

² Grant Thornton LLP. (2025).
Improvements to accounting for internal-use software.
https://www.grantthornton.com/insights/articles/audit/2025/snapshot/december/improvements-to-accounting-for-internal-use-software

³ Crowe LLP. (2025).
FASB revises internal-use software cost guidance (ASU 2025-06).
https://www.crowe.com/insights/take-into-account/fasb-revises-internal-use-software-cost-guidance

⁴ SingerLewak LLP. (2025).
ASU 2025-06: Modernizing internal-use software accounting and disclosures.
https://www.singerlewak.com/asu-2025-06-modernizing-internal-use-software-accounting-and-disclosures/

⁵ Grant Thornton LLP. (2025).
Improvements to accounting for internal-use software (ASC 985-20 scope discussion).
https://www.grantthornton.com/insights/articles/audit/2025/snapshot/december/improvements-to-accounting-for-internal-use-software

⁶ KPMG LLP. (2026).
FASB issues final ASU on software cost accounting.
https://kpmg.com/us/en/frv/reference-library/2026/fasb-issues-final-asu-software-cost-accounting.html  

⁷ Deloitte & Touche LLP. (2025).
FASB Amends Guidance on the Accounting for and Disclosure of Software Costs.
https://dart.deloitte.com/USDART/home/publications/deloitte/heads-up/2025/fasb-asu-amends-software-costs-guidance  

Image Source

ProjectManagement.ie. (n.d.).
Waterfall vs. agile.
https://projectmanagement.ie/blog/waterfall-vs-agile/