ASU 2025-06: Information for Nonsoftware Companies

We cover the key changes under Accounting Standards Update (ASU) 2025-06, including how it can be applied, implementation considerations, and next steps for nonsoftware companies.

Most leaders do not think of their organizations as software companies, yet some of their largest transformation initiatives often depend on software: enterprise resource planning (ERP) system replacements, customer relationship management (CRM) software migrations, data platform builds, cybersecurity tooling, and the integrations that connect it all. Those projects can drive meaningful financial statement effects, including impact on balance sheet recognition, expense timing, and earnings trends. ASU 2025-06, “Intangibles – Goodwill and Other – Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software,” changes how organizations determine when those project costs qualify for capitalization, replacing legacy project stage-based triggers with a judgment-based threshold designed for modern implementation environments.

Leaders of nonsoftware companies should understand how ASU 2025-06 applies across common scenarios – what changes, what does not, and how finance teams can adapt controls, documentation, and transition planning accordingly.

What changes under ASU 2025-06?

For most nonsoftware companies, the significance of ASU 2025-06 is not that it overturns existing accounting conclusions. The Financial Accounting Standards Board (FASB) has stated it does not expect overall capitalization outcomes to change materially for most internal-use software projects.

What does change is how capitalization judgments are developed and supported. Under the amended guidance, preparers and auditors will focus less on mapping activities to legacy project stages and more on clearly articulating and evidencing key judgments related to the capitalization threshold, including management’s authorization and commitment to fund and the probability of completion, including an assessment of significant development uncertainty.

Goodbye, stage-based gating; hello, threshold-based accounting

Historically, accounting policies and control frameworks were built around the idea that capitalization of software costs begins once the project moves beyond the preliminary stage. The legacy accounting model often drove extensive debates about whether activities were in “planning,” “development,” or “post-implementation.” That has changed. ASU 2025-06 eliminates the software project development stages as a capitalization consideration, replacing them with a revised threshold that can be applied regardless of whether projects follow traditional sequential methods (for example, the waterfall model) or more iterative methods (such as agile development).

This change is a practical shift: Nonsoftware companies should expect audits to focus less on the stage in which an expense occurred and more on documentation supporting when the capitalization threshold was met and the basis for the conclusion that significant development uncertainty did – or did not – exist.

The new threshold: Funding authorization plus probable-to-complete recognition threshold

Under the amended guidance, capitalization begins only when both of these conditions are met:

• Management has authorized and committed to funding the software project.
• It is probable the project will be completed and the software will be used to perform its intended function.

Those conditions might seem familiar, but ASU 2025-06 makes their role explicit and ties them to a concept that will now play a central role in applying the capitalization threshold: significant development uncertainty.

Significant development uncertainty: What it is and why it’s the new judgment hot spot

The amended guidance frames significant development uncertainty around whether a project’s core requirements are still unknown or unstable and whether resolution is expected through development effort. The codification describes uncertainty when the project involves technological innovations; novel, unique, or unproven functions or features; or significant performance requirements, where resolution is expected to occur through coding and testing.

Practically, this concept is designed to distinguish between two types of projects:

• Projects that are primarily execution based (configuration, integration, and implementation of known functionality)
• Projects where the organization is still resolving whether it can build the needed functionality or meet material performance requirements through coding and testing

For many nonsoftware company initiatives, especially implementation of a developed solution such as an ERP system, the FASB expects the significant development uncertainty assessment to be relatively straightforward once the company selects the system and can determine whether intended functionality requires significant development. Consistent with how most ERP programs evolve, the primary work is configuring and integrating a product that already exists, not inventing a new, unproven functionality.

Significant development uncertainty becomes more consequential for nonsoftware companies when projects include one or more of the following:

• Extensive bespoke development that introduces novel functions
• Significant performance requirements that are not yet identified or remain in flux
• Complex integrations where requirements are still being materially revised as the team learns what the system realistically can do

A key implementation consideration is that finance teams will need a repeatable way to evaluate and document when performance requirements have stabilized and when uncertainty has been resolved. The evidence needed to support these conclusions typically already exists within the organization. Implementation teams, system integrators, and project management offices (PMOs) routinely define requirements, approve architectures, set baseline performance criteria, and document testing outcomes as part of standard delivery governance. The practical challenge for nonsoftware companies is not creating new analyses but ensuring that the finance team is connected to those processes and understands how to translate implementation milestones into supportable accounting conclusions.

How ASU 2025-06 applies in three common nonsoftware company scenarios

Nonsoftware companies typically encounter the internal-use software accounting guidance in a small number of recurring scenarios – often without thinking of them as software accounting issues at all.

Implementing licensed enterprise systems

For nonsoftware companies implementing licensed enterprise systems – such as replacing an ERP system, rolling out new CRM software, or upgrading core finance or human resources platforms, often with significant configuration, integration, and data migration work – the most visible impact of ASU 2025-06 is how the capitalization starting point is determined. Under legacy project stage-based models, some organizations effectively treated the end of planning as a proxy for when capitalization began. Under the amended guidance, the analysis is anchored instead in whether the capitalization threshold has been met, including whether any significant development uncertainty exists.

Notwithstanding the change, the outcome might be similar to many ERP implementations for two reasons:

• Management authorization and commitment to funding typically are established through existing governance structures (for example, approved budgets, steering committee approvals, and signed statements of work).
• Once the solution and implementation plan are defined, projects often are probable to be completed and used as intended.

Where ASU 2025-06 pushes additional discipline is in requiring teams to be explicit about what constitutes the “software project.” Because that term is not defined in U.S. GAAP, judgment is required – particularly for modular implementations or phased rollouts.

A practical approach for many nonsoftware companies is to align the software project definition with how investments already are governed: via a project charter, defined scope, identified intended functions, and a milestone path that includes testing and deployment. Doing so creates a clear link among governance decisions, probability of completion, and evidence that the system is ready for use.

Adopting SaaS and other hosted solutions

When organizations adopt software as a service (SaaS) or other hosted solutions – such as cloud-based procurement, payroll, customer service, or cybersecurity tools, where the arrangement is usually a service contract but implementation costs still require accounting analysis – the initial accounting question remains unchanged: Does the arrangement convey a software license, or is it a service contract?

A hosted arrangement conveys a license only if both of the following conditions are met:

• The customer has the contractual right to take possession of the software at any time during the hosting period without significant penalty.
• It is feasible for the customer to run the software on its own hardware or have it hosted by an unrelated third party.

Many common SaaS arrangements fail one or both conditions and therefore are accounted for as service contracts. That classification drives how payments are presented and how related implementation costs are evaluated.

As a practical connection to ASU 2025-06, even when the arrangement is a service contract, Accounting Standards Codification (ASC) 350-40 requires certain implementation costs to be evaluated for capitalization as though the arrangement were an internal-use software project. While the hosted implementation-cost model itself is not being overhauled, teams might need to reassess when implementation activities meet the revised capitalization threshold, given the elimination of stage-based gating.

Bespoke internal development

Most nonsoftware companies do relatively little ground-up development compared to a decade ago. Still, bespoke internal work remains common – workflow automation, system interfaces, reporting and analytics layers, and internal applications built to support operations rather than to be sold.

This is where ASU 2025-06 can have the greatest impact, because it draws a sharper distinction between execution and development uncertainty. When projects involve novel or unproven functionality, or when significant performance requirements are still being resolved through coding and testing, development uncertainty becomes the central accounting issue.

What stays the same under ASU 2025-06?

Nonsoftware companies should be clear about what the ASU does not change:

• This is still ASC 350-40. The ASU modernizes the internal-use software accounting model; it doesn’t replace it.
• Maintenance is still maintenance. Training and routine maintenance activities remain expensed as incurred.
• The SaaS “license versus service” test remains the same. It is still a frequent gating analysis in practice.
• Board expectations are not altered. The board indicated it does not expect the amendments to significantly change accounting outcomes for most types of internal-use software.

In other words, total capitalization levels might not swing dramatically for many ERP-style programs, but the method to evaluate the model, documentation package, and internal controls likely needs to evolve to match the revised decision framework.

How the FASB expects the amended model to be applied

The board stated it does not expect significant accounting changes for most internal-use software. It also suggested that for “developed solution” implementations (such as ERP), evaluating significant development uncertainty should be relatively straightforward once the software is selected and the company can determine whether the intended functionality requires significant development.

The implication for nonsoftware companies is that ASU 2025-06 is primarily an operability update – reducing stage-based debates and recentering the analyses on supportable threshold conclusions. Where outcomes might differ is in the narrower set of projects involving significant bespoke development, material performance uncertainty, or requirements that continue to shift late in the build.

Implementation considerations: Aligning finance, IT, and PMO decision-making

Effective date and early adoption

For public business entities, the amendments are effective for fiscal years beginning after Dec. 15, 2027, and interim periods within those fiscal years. For all other entities, they are effective for fiscal years beginning after Dec. 15, 2028, and interim periods within fiscal years beginning after Dec. 15, 2029. Early adoption is permitted.

Transition methods and how nonsoftware companies commonly choose

ASU 2025-06 permits prospective, modified retrospective, or retrospective transition. Deciding on the “best” transition method is rarely an abstract accounting preference; it typically is driven by the organization’s project inventory and data availability. In practice, the transition decision often is influenced by where major ERP, CRM, or SaaS implementation programs sit on the adoption timeline and how well historical cost data aligns with those programs.

• Prospective transition applies the amended guidance only to costs incurred after adoption and often fits nonsoftware companies seeking operational simplicity, particularly when bespoke internal development is limited.
• Modified retrospective transition applies the amended guidance prospectively but requires a cumulative-effect adjustment for in-process projects that no longer meet the capitalization threshold, making it attractive when a large ERP or CRM program is underway near adoption and the company wants improved comparability without reconstructing historical cost data in full.
• Retrospective transition applies the amended guidance to prior periods, recasting historical results, and is the most demanding approach – generally reserved for situations in which software capitalization is a dominant driver of financial trends and robust historical cost detail is available.

Adoption considerations

Successful adoption for nonsoftware companies typically comes down to three key tasks. Each is manageable but requires coordination across finance, IT, and the PMO so that accounting judgments are grounded in how projects are governed and executed.

1. Define “software project” at a governance-relevant unit. Because the term “software project” is not defined in U.S. GAAP, companies must decide – and document – how they identify the unit at which the capitalization threshold is assessed. This determination is especially important for phased implementations, modular deployments, and programs that roll out functionality incrementally.
   
   For nonsoftware companies, the most defensible approach often is to align the software project definition with existing investment governance structures: a project charter, defined scope, identified intended functions, and a milestone path that includes testing and deployment. This determination should align with how investment decisions are approved, monitored, and reported.
2. Refresh policy language related to the capitalization threshold – and remove stage-centric thinking. Accounting policies should be updated to explicitly reflect the amended capitalization threshold – management authorization and commitment to funding, plus probable completion and intended use – and to require a documented assessment of significant development uncertainty for projects that involve novel functionality or unstable performance requirements.
   
   For many organizations, this will involve replacing references to “preliminary,” “application development,” or similar legacy project stages with decision points tied to funding approval, scope definition, and the resolution of development uncertainty through evidence generated during implementation.
3. Build a documentation package that aligns with how IT actually works. To make significant development uncertainty assessments supportable, finance teams should align accounting checkpoints with artifacts that implementation teams already produce as part of normal delivery governance. These often include requirement baselines, defined performance criteria, architecture approvals, testing results, and go-live readiness reviews.
   
   The amended model is driven by evidence. The objective is to rely on contemporaneous project artifacts rather than reconstructing conclusions late in the process in a way that feels disconnected from how the project actually was executed.

Next steps

For nonsoftware companies, readiness under ASU 2025-06 depends on establishing a repeatable approach to defining the software project, documenting authorization and commitment, and demonstrating whether the probable-to-complete recognition threshold (including an assessment of significant development uncertainty) is met.

Organizations that begin this work early – while ERP, CRM, and SaaS implementation governance already is in motion – are best positioned to adopt ASU 2025-06 with clear audit trails, fewer late-stage surprises, and a transition approach aligned to their project portfolio rather than constrained by data gaps.

FASB materials reprinted with permission. Copyright 2026 by Financial Accounting Foundation, Norwalk, Connecticut. Copyright 1974-1980 by American Institute of Certified Public Accountants.