In September 2025, the Financial Accounting Standards Board (FASB) issued Accounting Standards Update (ASU) 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software.
The amendments remove all references to software development project stages in Subtopic 350-40, Intangibles—Goodwill and Other—Internal-Use Software and clarify the capitalization threshold for internal-use software costs.
The amended guidance applies to all entities subject to the internal-use software guidance in Subtopic 350-40 and to entities that account for website development costs in accordance with Subtopic 350-50, Intangibles—Goodwill and Other—Website Development Costs.
The amendments do not impact the accounting for external-use software in the scope of Subtopic 985-20, Software—Costs of Software to Be Sold, Leased, or Marketed.
Key provisions
Under current U.S. GAAP, entities are required to capitalize development costs incurred for internal-use software depending on the nature of the costs and the project stage during which they occur.
Feedback received during the 2021 FASB Invitation to Comment noted that the current guidance is outdated and lacks relevance given the evolution of software development—in particular, the transition from using a prescriptive and sequential method, such as the waterfall method, to using an incremental and iterative method, such as the agile method, to develop software.
The amendments are intended to better align the accounting for internal-use software costs with how software is developed, as well as improve operability of the recognition guidance and reduce diversity in practice.
Internal-use software costs
The amendments remove all references to project stages in Subtopic 350-40 and require entities to capitalize internal-use software costs when both of the following occur:
- Management has authorized and committed to funding the software project.
- It is probable that the project will be completed, and the software will be used to perform the function intended—referred to as the “probable-to-complete recognition threshold”.
If there is significant uncertainty associated with the development activities of the software, the probable-to-complete recognition threshold would not be met. Significant development uncertainty exists if either of the following two factors are present:
- The software being developed has technological innovations or novel, unique, unproven functions or features and the uncertainty related to those technological innovations, functions or features has not been resolved through coding and testing.
- The significant performance requirements—for example, functions or features—of the software have not been identified or the identified significant performance requirements continue to be substantially revised.
Once the significant development uncertainty has been resolved, entities would begin capitalizing internal-use software costs if the other criterion has been met.
Disclosure
The amendments clarify that the disclosure requirements in Subtopic 360-10, Property, Plant, and Equipment—Overall, apply to all software costs that are capitalized and amortized in accordance with Subtopic 350-40.
Website development costs
Subtopic 350-50 currently provides accounting guidance for website development costs and whether such costs should be expensed or capitalized.
As certain areas of Subtopic 350-50 directly reference guidance in Subtopic 350-40, the amendments supersede Subtopic 350-50 and incorporate the recognition requirements for website-specific development costs into Subtopic 350-40.
Business implications
ASU 2025-06 is expected to simplify the analysis for internal-use software cost capitalization, as entities no longer will be required to align capitalization to project stages that are not applicable to an agile development environment. Further, the new ASU does not change 1) the types of costs that qualify for capitalization, 2) when internal-use software cost capitalization ceases and 3) cost capitalization guidance for external-use software pursuant to Subtopic 985-20. Therefore, there are opportunities for companies to leverage existing procedures and controls to apply ASU 2025-06.
ASU 2025-06 does introduce new concepts, including the probable-to-complete recognition threshold, which will require judgment and potential changes to processes and controls to evidence key assertions. Notably, entities will need to develop policies and procedures to support the following:
- Identification (and potential grouping) of development efforts into one or more software projects (i.e., unit of account for applying ASU 2025-06)
- Evidence of appropriate approvals from management and commitment to funding each identified software project
- Identification and contemporaneous documentation of performance requirements and how management will evaluate which performance requirements are significant
- Factors to consider for determining whether features are novel, unproven, or unique, which may vary by software project
- Evaluation of expected revisions to performance requirements and how management will consider whether revisions are expected to be substantial
- Level of coding and testing that is required to resolve significant development uncertainty and supporting evidence
- Identification and gathering of incremental data points to support enhanced disclosure requirements
In the Basis for Conclusions to ASU 2025-06, the FASB notes that for certain software development projects (e.g., ERP implementation of an established solution), an entity’s evaluation of significant development uncertainty may be straightforward. However, entities often undertake numerous software development projects in parallel, all of which have specific development fact patterns that could result in different conclusions when applying ASU 2025-06. As a result, developing a framework that is flexible to apply to any software development project is recommended to support consistency in conclusions.
The FASB expects that the probable-to-complete assessment may result in more development costs being expensed by internal-use software platform developers, which will better align the accounting and cost capitalization for software provided in cloud computing arrangements (e.g., software-as-a-service or “SaaS” arrangements) with licensing delivery models (i.e., on-premise software). Cost capitalization for a licensing delivery model considers external-use software capitalization guidance within Subtopic 985-20, which requires establishing technological feasibility to initiate the capitalization of development costs. As described in ASC 985-20-25-2, technological feasibility is established when an entity “has completed all planning, designing, coding, and testing activities that are necessary to establish that the product can be produced to its design specifications including functions, features, and technical performance requirements.” In practice, entities often expense the majority of (if not all) costs for external-use software development, as technological feasibility is generally established near the end of the development cycle and costs required to be capitalized are deemed immaterial to the financial statements.
As software provided as part of a cloud computing or SaaS arrangement is considered internal-use software, SaaS providers would apply the concepts within ASU 2025-06 for cost capitalization. To the extent there is significant development uncertainty associated with the underlying software, this may result in expensing a significant portion of the development costs until the uncertainty is resolved through coding or testing. This could result in similar conclusions if the same software development activities were evaluated pursuant to Subtopic 985-20’s definition of technological feasibility.
While the FASB intentionally omitted the terms “technological feasibility” and “high-risk development issues” from ASU 2025-06, they did borrow “novel, unique, unproven functions and features or technological innovations” language directly from Subtopic 985-20 to describe the first factor under ASU 2025-06 that would indicate a significant development uncertainty exists. As a result, although ASU 2025-06 does not fully align internal-use software development guidance with that of Subtopic 985-20 external-use software guidance, it is expected that software with similar development risks could reach similar capitalization conclusions (i.e., costs associated with newly developed SaaS software could be expensed or capitalized same or similar as costs associated with newly developed software to be externally licensed as on-premise software under Subtopic 985-20).
Effective dates
The amendments are effective for all entities for annual reporting periods, including interim reporting periods within those annual reporting periods, beginning after Dec. 15, 2027.
Early adoption is permitted as of the beginning of an annual reporting period.
Transition requirements
The amendments permit entities to apply the new guidance using a prospective, modified or retrospective transition approach.
- Prospective transition approach: entities should apply the amendments to new software costs incurred as of the beginning of the period of adoption for all projects, including in-process projects.
- Modified transition approach: entities should apply the amendments on a prospective basis to new software costs incurred, except for in-process projects that meet the capitalization requirements under the current guidance but don’t meet the capitalization requirements under the amended guidance as of the date of adoption. For those in-process projects, entities should derecognize any capitalized costs through a cumulative-effect adjustment to the opening balance of retained earnings as of the date of adoption.
- Retrospective transition approach: entities should recast comparative periods and recognize a cumulative-effect adjustment to the opening balance of retained earnings as of the beginning of the first period presented.






