Use ASU 2025-06 to Modernize Your Software Capitalization Policy

Adopting ASU 2025-06 may give some companies an opportunity to revisit software capitalization policies, strengthen documentation, and better understand how capitalization decisions may affect EBITDA and valuation-related metrics before a sale.

The new standard changes the capitalization threshold for internal-use software, but it also gives finance teams a practical reason to revisit and reset policies that may no longer reflect how software gets built.

Understanding this change can help you make better capitalization decisions, strengthen support for your conclusions, and prepare for questions from auditors or buyers. 

A quick refresher on ASU 2025-06

Issued in September 2025, ASU 2025-06, Intangibles — Goodwill and Other — Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software, is the most significant update to internal-use software accounting in more than 25 years. 

The prior guidance, written in 1998, presumed a linear “waterfall” development approach and tied capitalization to project stages — an approach that fits poorly with the agile, iterative methods most organizations use today.

The ASU removes all references to project stages and instead requires an entity to begin capitalizing internal-use software costs when both of the following occur:

• Management, with the relevant authority, has authorized and committed to funding the software project; and
• It’s probable the project will be completed and the software will be used to perform its intended function (the “probable-to-complete” recognition threshold), which requires an entity to consider whether significant development uncertainty exists.

Notably, the ASU doesn’t change which costs are eligible for capitalization, when capitalization stops, or the accounting for external-use software under ASC 985-20. It also folds the former website development cost guidance (Subtopic 350-50) into Subtopic 350-40. 

The amendments are effective for all entities for annual reporting periods beginning after December 15, 2027, and interim periods within those annual periods, with early adoption permitted. Entities may transition using a prospective, modified, or retrospective approach.

How ASU 2025-06 may change capitalization decisions 

Because the ASU doesn’t expand the population of capitalizable costs, the Financial Accounting Standards Board (FASB) has indicated it expects entities to capitalize about the same amount — or less — under the new model. In practice, early conversations suggest the update is prompting some companies to move in the opposite direction. 

The reason is less about the new threshold itself and more about the fresh look it invites: Adoption forces finance teams to dust off policies that, in many cases, haven’t been meaningfully revisited in years.

Some companies expect to capitalize more going forward — not because the standard requires it, but because their historical practices were out of step with the guidance. 

In certain cases, companies had simply expensed nearly all their software development spend as a matter of convenience; in others, they were undercapitalizing relative to what even the prior rules supported. 

For these organizations, adopting ASU 2025-06 becomes the natural moment to align policy with practice and start capitalizing costs that arguably should have been capitalized all along.

Why companies are revisiting old policies now

Capitalizing software costs rather than expensing them shifts spending off the income statement and onto the balance sheet, where it’s amortized over time. That change carries two benefits companies are paying close attention to:

Potential EBITDA impact 

Previously expensed costs reduce operating income; capitalizing them instead removes that drag and, because amortization is added back, can improve EBITDA and related performance metrics.

Potential valuation considerations 

For companies preparing to be sold, improved EBITDA often translates directly into a higher purchase price under multiple-based valuations. Capitalized software can also present a more complete picture of the investment a company has made in its technology assets.

How to build a supportable software capitalization process

The opportunity is real, but it comes with responsibility. Any change in capitalization should reflect the substance of how software is developed and be supported by contemporaneous documentation — not driven solely by a desired earnings or valuation outcome. 

As companies revisit their policies, a few points are worth keeping in mind:

Understand judgment is now central

The probable-to-complete threshold requires entities to assess whether significant development uncertainty exists before capitalization begins. 

Under ASU 2025-06, that assessment should consider whether the project involves unresolved, novel, unique, unproven, or high-risk development issues that could prevent the software from being completed and used as intended — precisely the type of judgment auditors are likely to scrutinize.

Document authorization and completion decisions

Management’s authorization, funding commitment, and completion assessment should be captured in real time to support the timing of capitalization.

Track development time by task and developer

Capitalization ultimately depends on knowing how much development time was spent — and on what. This is frequently the weakest link when auditing capitalized software costs, and robust time records are essential to withstand auditor scrutiny.

Companies should have a supportable time management system that reliably tracks development effort by developer and by task, so qualifying costs can be identified, allocated, and substantiated. 

Update your process and controls

Capitalizing more means new judgments and higher balances flowing through the financial statements, so the underlying process needs to keep pace. 

Consider building repeatable procedures and internal controls that: 

• Define the unit of account in a way that reflects how management actually develops and manages the software, evaluating individual projects, modules, features, or components separately when they’re separately authorized, funded, tracked, and managed
• Capture management’s authorization and funding commitment
• Evaluate the probable-to-complete threshold and development uncertainty at inception
• Identify and accumulate qualifying costs
• Review capitalization decisions on a recurring basis

Clear ownership, defined thresholds, and periodic signoffs help apply the higher level of capitalization consistently and withstand auditor scrutiny.

Evaluate consistency and comparability

A policy change affects trends across periods; consider how the transition approach you select (prospective, modified, or retrospective) will present results to lenders, investors, and potential buyers.

Plan for added balance sheet tracking

Higher capitalized balances mean larger amortization, ongoing impairment considerations, and expanded property, plant, and equipment disclosures under ASC 360-10.

How CLA can help with software capitalization

Whether you’re preparing for ASU 2025-06, cleaning up long-standing practices, or positioning your company for a future transaction, CLA professionals can help you assess the impact, develop a clear capitalization policy, build the supporting processes and internal controls, and document your conclusions in a technical accounting memo. 

Contact us

Turn ASU 2025-06 into a policy reset. Complete the form below to connect with CLA.