ASU 2025-06

ASU 2025-06 is an Accounting Standards Update issued by the Financial Accounting Standards Board (FASB) in September 2025. Its full title refers to targeted improvements to the accounting for internal-use software, and it changes the rules in ASC 350-40 that determine when companies can capitalize the costs of building software for their own use. For any organization that develops software internally, from custom business applications to internal platforms, the update affects how much development cost appears on the balance sheet and how much hits the income statement.

The main reason for the change is that the old rules were written for a linear, waterfall style of development. They tied capitalization to project stages that rarely match how software is built today, with iterative, agile methods and continuous delivery. ASU 2025-06 removes those stages and replaces them with a principle-based threshold, which is intended to make the rules easier to apply to modern development practices.

Definition of ASU 2025-06

ASU 2025-06 amends ASC 350-40, the US GAAP subtopic covering internal-use software. Internal-use software is software acquired, developed or modified solely to meet an entity's internal needs, with no substantive plan to market it externally. The update changes when costs for such software begin to be capitalized, and it also moves website development guidance into ASC 350-40.

The update does not change the accounting for software developed to be sold, leased or otherwise marketed, which remains under ASC 985-20. It also does not change the basic idea that capitalized software is amortized over its useful life once it is ready for its intended use.

Removal of Project Stages

Before the update, ASC 350-40 divided internal-use software projects into three stages: a preliminary project stage, an application development stage and a post-implementation stage. Costs in the preliminary and post-implementation stages were expensed, while qualifying costs in the application development stage were capitalized.

ASU 2025-06 removes all references to these stages. Many organizations found the stages hard to apply to agile projects, where planning, design, coding and testing happen continuously and in short cycles. Without stages, companies no longer need to decide which phase each sprint or release belongs to.

The New Capitalization Threshold

Under the update, an entity begins capitalizing software costs when two conditions are met. Management, with the relevant authority, has authorized the project and committed to funding it, and it is probable that the project will be completed and the software will be used to perform its intended function. This is often described as the probable-to-complete threshold.

When evaluating whether completion is probable, an entity must consider whether there is significant development uncertainty. The update describes two factors: whether the software involves novel, unique or unproven technology, functions or features whose uncertainty has not yet been resolved through coding and testing, and whether the performance requirements are not yet clearly defined or are still changing significantly. If significant development uncertainty exists, capitalization is deferred until it is resolved.

Importance of ASU 2025-06 in IT Financial Management

Software development is a large and growing share of technology spending, and capitalization decisions affect how that spending is reported. Moving costs from operating expense to capital spreads them over future periods through amortization, which changes reported profit, budgets and key metrics.

The update therefore matters to CFOs, controllers and IT finance leaders, as well as to engineering leaders whose teams must track the time and costs that may be capitalized.

Simpler Application to Agile Development

The removal of project stages addresses a long-standing difficulty for organizations using agile methods. Under the old rules, finance teams often had to map sprints and backlogs onto a waterfall framework, which required judgment and created inconsistencies between companies.

The new threshold focuses on management commitment and the probability of completion, which can be assessed at the project or initiative level. This should make capitalization decisions more consistent and easier to document, although judgment is still required, especially when assessing development uncertainty.

Effects on Reported Results

Depending on how an organization applied the old rules, the update could increase or decrease the amount capitalized. Projects with significant development uncertainty, such as experimental or novel software, may see capitalization start later than before, increasing expenses in early periods.

Changes in capitalization affect the amount recorded as amortized cost on the balance sheet, the capex vs opex split of technology spending, the size of amortization in future years, the IT budget and metrics such as operating income and EBITDA. IT finance teams should model these effects before adoption so that budgets and forecasts reflect the new rules.