What ASU 2025-06 Changes for Internal-Use Software Accounting

Internal-use software costs are about to get harder to capitalize — and for many organizations, the change may be noticeable.

ASU 2025‑06 updates the accounting model in ASC 350‑40 to reflect how software is developed today. Instead of relying on development stages, the new guidance centers on management intent, authorization, and whether software can realistically be completed and used as planned.

That shift moves accounting decisions closer to governance, project certainty, and ongoing judgment — particularly in agile and iterative development environments.

While the update is described as “targeted,” it may reduce the amount of software costs capitalized, accelerate expense recognition, and create downstream effects across financial statements, EBITDA, margins, and debt covenants.

Companies developing internal-use software should review existing policies, documentation practices, and project approval processes well before the effective date.

What ASU 2025‑06 changes about ASC 350-40

ASC 350-40applies to internal-use software — software developed or obtained to meet an entity’s internal needs, including certain website development activities. The model has always been intended to distinguish between:

• Costs that create probable future economic benefits (which may be capitalized), and
• Costs that are exploratory, operational, or maintenance related (which are expensed).

Before ASU 2025-06, the guidance operationalized that distinction using a stage-based model (preliminary project stage, application development stage, and post-implementation stage).

Capitalization was generally associated with the application development stage, once feasibility and funding conditions were met. The guidance applied to historical waterfall-style or linear development processes and became more difficult to apply as technology companies moved to agile development environments.

ASU 2025-06 removes all references to software development stages from ASC 350-40. Entities no longer need to identify a transition point from “preliminary” to “application development” to justify capitalization.

The capitalization criteria of internal-use software

Under ASU 2025-06, capitalization of internal-use software costs begins only when both of the following conditions are met:

1. Management authorization and funding

Management, with appropriate authority, has implicitly or explicitly authorized the project and committed to funding it.

This criterion emphasizes governance and intent so capitalization doesn’t begin while a project remains speculative, unfunded, or subject to ongoing approval debates. However, authorization alone isn’t sufficient.

2. Probable completion and intended use

It must be probable the project will be completed and the software will be used to perform its intended function — referred to as the “probable to complete threshold.”

When capitalization is not appropriate: Significant development uncertainty

ASU 2025-06 highlights new guidance on evaluating whether a probable completion threshold is met by introducing significant development uncertainty and that capitalization is inappropriate when significant development uncertainty exists.

In practical terms, development uncertainty exists when it’s not yet clear whether:

• The software can be completed as designed, or
• The completed software will function as intended.

Common sources of uncertainty include:

• Use of unproven or highly complex technology
• Unresolved technical feasibility issues
• Dependence on third-party tools or platforms that are not yet stable
• Early-stage development where outcomes remain highly variable

The ASU doesn’t change which types of costs are eligible for capitalization (e.g., training, data conversion, and maintenance continue to be expensed). The capitalization period will cease, as it does currently, when the software is substantially complete and ready for its intended use.

ASU 2025-06 is a judgment-driven framework. As a result, entities should:

• Update accounting policies to specifically reference:
• Management authorization and funding
• Probable completion and intended use criteria directly
• Establish clear documentation standards for evaluating probable completion
• Identify and track indicators of significant development uncertainty throughout the development lifecycle

The effective date of the ASU is for fiscal years beginning after December 15, 2027. Generally, it’s possible there will be a reduction in capitalized costs. Companies should consider impacts from this update, including balance sheet, EBITDA, covenants, and margin impacts.

How companies can adopt ASU 2025‑06

With these changes affecting when and whether costs are capitalized, companies should also consider how to adopt the guidance. Under the ASU, companies are given three transition approaches in adopting the new standard.

1. Prospective transition approach

Under the prospective transition approach, a company will apply the amendments in the ASU to new software costs incurred as of the beginning of the period of adoption for all projects, including in-process projects.

2. Modified transition approach

Under the modified transition approach, a company will apply the amendments in the ASU on a prospective basis to new software costs incurred for all projects, including those in-process. This doesn’t apply to in-process projects that, as of the date of adoption, don’t meet the capitalization requirements under the amendments but meet the requirements under current guidance.

For in-process projects, organizations should derecognize any capitalized costs through a cumulative-effect adjustment to the opening balance of retained earnings (or other appropriate components of equity or net assets in the statement of financial position) as of the date of adoption.

3. Retrospective transition approach

Under a retrospective transition approach, a company should recast comparative periods and recognize a cumulative-effect adjustment to the opening balance of retained earnings (or other appropriate components of equity or net assets in the statement of financial position) as of the beginning of the first period presented.

Why this update matters

• Capitalization decisions now depend on project authorization and technical certainty rather than development stages
• Agile and iterative projects may reach capitalization thresholds later, especially when scope or feasibility continues to evolve
• The guidance places greater weight on judgment, increasing the importance of governance, documentation, and coordination across finance and technology teams
• Differences in approval processes and project oversight may lead to more variability in capitalization outcomes across organizations

How CLA can help with internal‑use software accounting

ASU 2025‑06 places greater weight on governance, judgment, and documentation. CLA helps organizations assess how new criteria apply to their software projects, update accounting policies, and plan for adoption.

We also support coordination between finance and technology teams so capitalization decisions reflect both project realities and accounting requirements.

Contact us

Understand capitalization under new models and evaluate the impacts on your organization. Complete the form below to connect with CLA.