On September 18, 2025, the Financial Accounting Standards Board (FASB) issued ASU 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software.   This update revises when and how companies capitalize development costs for internal-use software and the required disclosures under ASC 350-40 to better reflect the realities of modern software development.

Why the Change?

Under the prior rules, ASC 350-40 defined three distinct project stages:

• Preliminary
• Application development
• Post-implementation/operation

As development is not always linear, these didn’t easily mirror how software is built today, especially with agile or iterative development.
The prior stage framework often created unnecessary complexity and judgment calls. The FASB issued this ASU to move toward a more principles-based approach.

Key Changes

1 – No More Prescriptive Project Stages

The ASU removes all references to “development stages” in ASC 350-40. Instead, capitalization depends on two criteria:

● Authorization and commitment to funding — management must explicitly authorize and commit to the project.

● Probable-to-complete recognition threshold — it must be probable that the project will finish and that the software will be used for its intended purpose.

2 – Assessing Development Uncertainty

Entities need to evaluate whether there is “significant development uncertainty” (for example, new or unproven functions) before capitalizing. If uncertainty exists, it must be resolved (through coding and testing) before capitalization can begin.

3 – Website Development Brought Into Scope

Guidance for internal-use website development (previously in ASC 350-50) is now moved to ASC 350-40.  This centralizes the treatment of all internal-use software development.

4 – Disclosure Alignment

The ASU aligns the disclosure requirements for capitalized internal-use software with those for property, plant, and equipment.  Some prior detailed intangible-asset disclosures are no longer required for internal-use software.

Effective Date and Transition

Effective Date:

Annual periods beginning after December 15, 2027, including interim periods within those annual reporting periods.  Early adoption is permitted as of the beginning of an interim or annual period, as long as the financial statements have not been issued or made available for issuance.

Transition Methods:

Entities can apply the following transition approaches:

1 – Prospective

● Apply to new software costs incurred as of the beginning of the period of adoption for all projects, including in-process projects

2 – Modified

● Apply on a prospective basis to new software costs, including in-process project, expect for in-process projects that no longer meet capitalization requirements

● Derecognize capitalized costs for these in-process projects through a cumulative-effect adjustment to the opening balance

3 – Retrospective method

● Recast comparative periods and recognize a cumulative-effect adjustment to the opening balance

Strategic Insights

• For companies with ongoing software projects (especially those using agile), ASU 2025-06 is likely to simplify decision-making.
• The model simplification may reduce the administrative burden and subjectivity of companies when deciding what to capitalize.
• Accounting teams should update their capitalization policies, including how they document management’s commitment and assess uncertainty.
• More costs are expected to be expensed for software related to cloud computing arrangements because judgement is required as to whether the probable-to-complete recognition threshold is met.
• Strong documentation of management intent, funding commitment, and development risk will be more important than ever.
• Management will need to work closely with IT/project managers to understand development timelines, deliverables, and risk.

As companies prepare for ASU 2025-06, the real opportunity lies in using this change to strengthen alignment between finance, IT, and project leadership. By updating policies, sharpening documentation, and rethinking capitalization decisions through a clearer, principles-based lens, organizations can improve transparency and reduce ambiguity. Early preparation will not only support a smoother transition but also help teams make more confident, consistent decisions as software development continues to evolve.

Amanda Schlank
Partner, Assurance and Advisory
SingerLewak
[email protected]