Accounting for Internal-Use Software Under ASU 2025-06

In under a minute

• Accounting Standards Update (ASU) 2025-06, “Intangibles – Goodwill and Other – Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software,” does not change which software costs are eligible for capitalization or when capitalization must cease; it changes when capitalization can begin.
• The legacy software project stages have been eliminated and replaced with a single capitalization threshold based on authorization to fund and probability of completion.
• Entities must evaluate significant development uncertainty for all software projects; if such uncertainty exists, the probable-to-complete threshold is not met.
• Significant development uncertainty is limited to two factors: unresolved novel or unproven functionality and unstable significant performance requirements.
• The amendments are expected to have the greatest impact on software as a service (SaaS) and cloud-delivered software, which often are accounted for as internal-use software.
• The most consequential judgments now center on defining the software project, identifying significant performance requirements, and documenting when development uncertainty is resolved through coding and testing.

Background

For many software companies, economically similar development activities have long produced different accounting outcomes depending on how software is delivered to customers. In an on-premises licensing model, software development costs typically are evaluated under Accounting Standards Codification (ASC) 985-20 (software to be sold, leased, or marketed). By contrast, SaaS and cloud-delivery arrangements often do not convey a software license for accounting purposes; instead, customers receive access to a hosted service. As a result, software companies historically have accounted for substantial portions of product development spend as internal-use software under ASC 350-40, even when that software is central to revenue-generating offerings.

ASU 2025-06 is aimed at modernizing and improving the internal-use software model. Most important for software companies, the ASU improves operability across development approaches (including agile environments) by replacing legacy project stage gating with a recognition threshold based on 1) management’s authorization to fund and 2) probability of completion, with explicit consideration of development uncertainty.

Crowe observation

Importantly, ASU 2025-06 leaves untouched the guidance in ASC 985-20 for costs incurred for software to be sold, licensed, or otherwise marketed. Consequently, the greatest expected impact of the new ASU will be on software delivered via hosting arrangements, which often is accounted for as internal-use software.

Scope considerations

While ASU 2025-06 does not modify the scope of ASC 350-40, software companies should have clear accounting policies for when software arrangements convey a license and fall within the scope of ASC 985-20 versus when they are treated as a service under ASC 350-40.

For hosted arrangements, a customer is considered to have obtained a software license if it meets both conditions of a two-condition U.S. GAAP test:

1. The customer has a contractual right to take possession of the software at any time during the hosting period without significant penalty.
2. The customer has the ability to run the software on its own hardware or contract with an unrelated party to host it.

If either condition is not met, the arrangement with the customer is treated as a service contract, not a software license.

Practical software company implications

For software companies, the scope of ASC 350-40 becomes especially important when the company deploys software that customers access via a hosted arrangement. While ASC 350-40 generally excludes from its scope software that is marketed externally, software that a customer obtains access to in a hosting arrangement often is treated as internal-use software because the customer either cannot take possession of the software or it is not feasible for the customer to deploy the software independent of the software vendor.

Capitalization trigger moves away from stages and toward a recognition threshold

The headline change of ASU 2025-06 is that it eliminates the project stage gating (the preliminary, application development, and post-implementation stages) as the primary trigger for capitalization. Instead, the ASU introduces a streamlined capitalization threshold.

Under the amended guidance (350-40-25-12), capitalization begins only when both of the following conditions are met:

• Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding a computer software project. Examples of authorization and commitment to funding a computer software project include the execution of a contract with a third party to develop the software, approval of expenditures related to internal development, or a commitment to obtain the software from a third party.
• It is probable that the project will be completed and the software will be used to perform the function intended (referred to as the probable-to-complete recognition threshold). In evaluating whether the probable-to-complete recognition threshold has been met, an entity shall assess whether there is significant uncertainty associated with the development activities of the software (referred to as significant development uncertainty) in accordance with paragraph 350-40-25-12A.

“Probable” is not new, but its role is more explicit

The ASU anchors the second criterion of the recognition threshold on “probable,” referencing the Master Glossary definition, “likely to occur.” For software companies, that matters because the recognition decision is no longer a mechanical “we entered the application development stage” moment; it becomes a documented accounting judgment about whether completion and intended use are likely, with explicit consideration of development risks.

Significant development uncertainty is a new gating condition

Under ASC 350-40-25-12A, an entity cannot conclude that the probable-to-complete recognition threshold has been met if significant development uncertainty exists. Accordingly, capitalization is deferred until that uncertainty is resolved.

Importantly, the evaluation of significant development uncertainty is required for all internal-use software projects, regardless of delivery model (on-premises, hosted, or cloud-based). For some projects, such as implementations or configurations of established third-party software, the assessment might be straightforward and quickly resolved. For others, the assessment will require more judgment and documentation.

ASU 2025-06 limits significant development uncertainty to two specific factors. If either factor is present, the probable-to-complete recognition threshold is not met:

• Novel or unproven functionality. The software being developed includes technological innovations or novel, unique, or unproven functions or features, and the related uncertainty has not yet been resolved through coding and testing.
• Unstable significant performance requirements. The software’s significant performance requirements (that is, what the software needs to do) have not been identified, or those identified requirements continue to be substantially revised.

The ASU does not require all performance requirements to be finalized before capitalization begins. Rather, the focus is on whether significant performance requirements remain unresolved or subject to substantial revision. Ongoing refinement of minor features or incremental tuning does not, by itself, create significant development uncertainty.

As a practical matter, the most challenging judgments are shifting away from labeling development “stages” and toward clearer, evidence-based questions:

• What is the defined software project?
• What are the significant performance requirements?
• What aspects of the software are genuinely novel or unproven?
• What specific coding and testing activities resolved that uncertainty, and when?

ASU 2025-06 relies on a “software project” concept, but the term is not defined in the Master Glossary – a point that will require judgment and documentation.

For SaaS companies, a workable policy might align “software project” with how the organization approves and funds meaningful product initiatives – for example, at the level of:

• A new platform capability (for example, multitenant re-architecture or a new permissions framework)
• A major product module (such as a billing engine rewrite)
• A regulated or security-driven initiative (for example, a Federal Risk and Authorization Management Program readiness buildout)

Defining the software project requires judgment, but that judgment should be exercised within clear guardrails. Defining a project too broadly (for example, as an entire product road map or multiyear platform vision) might inappropriately delay capitalization by importing unresolved uncertainty from unrelated initiatives. Conversely, defining a project too narrowly (for example, at the sprint or user-story level) might fail to reflect how management authorizes funding, evaluates success, and manages development risk.

A defensible software project definition generally aligns with how management governs the initiative – specifically, where there is a clear funding decision, an identifiable intended function, and a basis for assessing development uncertainty and substantial testing completion.

The accounting objective is not to mirror the development methodology perfectly; it is to choose a unit that 1) has an identifiable intended function, 2) has a governance decision point where management commits funding, and 3) can be assessed for development uncertainty and “substantial testing completed.” Importantly, the project definition should be neutral to the desired accounting outcome and applied consistently across similar initiatives.

Step 1: Identify the “authorization and commitment to fund” event

U.S. GAAP provides concrete examples of what authorization and commitment might look like: executing a third-party development contract, approving internal development expenditures, or committing to obtain software from a third party.

For SaaS development, an authorization and commitment to fund event often is evidenced by:

• Product investment committee approvals
• Capital allocation memos
• Board-level budget approvals for a platform initiative
• Signed statement of work contracts with systems integrators

The key is consistency: The company’s policy should explain what constitutes commitment and how it is documented.

Step 2: Determine whether it is probable that the project will be completed and the software used as intended

The amended capitalization threshold ties the probable-to-complete determination to an explicit evaluation of whether any significant development uncertainty is present.

Conceptually, SaaS companies should treat this as a two-layer analysis:

• First, does the company expect to complete the initiative and deploy it? That is, is completion probable (per the Master Glossary, “likely to occur”)?
• Second, even if leadership intends to complete the initiative, is there significant development uncertainty under ASC 350-40-25-12A that prevents meeting the probable-to-complete recognition threshold until that uncertainty is resolved?

Step 3: Assess significant development uncertainty

ASU 2025-06’s significant development uncertainty triggers are tightly framed:

• Novel or unproven functions or features (or technological innovations) not yet resolved through coding and testing
• Significant performance requirements not yet identified or still being substantially revised

Practical steps for assessing significant development uncertainty include:

• Identify the significant performance requirements for the project – that is, the significant functions and features and the performance, security, and reliability constraints that management considers essential.
• Ask whether those requirements are stable (no longer being substantially revised).
• Identify any novel or unproven functions and features, and document what it would mean to resolve the uncertainty through coding and testing.
• Document the date significant development uncertainty was concluded to be resolved as well as the evidence for the conclusion (for example, test results, performance benchmarks, architectural proof points, or a successful pilot in production-like conditions).

Use the ASU examples as a sanity check. For example, ASU 2025-06’s “Development of a Novel Technology” illustration delays capitalization until novel functionality uncertainty is resolved through coding and testing and performance requirements are identified and stable. Only then does the company conclude that the capitalization requirements are met and begin capitalizing eligible software costs.

Crowe observation

The board indicated it expects more costs will be expensed for software being developed to be sold as part of a cloud computing arrangement because significant development uncertainty might be observed more often for that profile of software.

Software companies should plan for the operational impact: They likely will need better documentation about “what was novel,” “what was stable,” and “when did we cross the line.”

Step 4: Begin capitalization only when the threshold is met; cease when substantial testing is completed

The amended guidance makes clear that if significant development uncertainty exists, the threshold is not met until that significant development uncertainty is resolved.

Capitalization then begins when the other conditions (authorization and commitment plus probable-to-complete) are met and ends no later than when the software is substantially complete and ready for intended use – that is, after all substantial testing is completed.

Although ASU 2025-06 reshapes when to start capitalizing, many software companies will find that what they capitalize and how they track it still require the same core disciplines: identifying eligible internal payroll and external direct costs; excluding selling, training, and duplicative costs; and applying consistent time tracking and cost accumulation.

The difference in practice is that SaaS companies might need to remap cost tracking to the new decision points:

• Approval and commitment (authorization)
• Stability of significant performance requirements
• Resolution of novel or unproven feature uncertainty through coding and testing
• Substantial testing completion

In other words, reporting entities might find that the accounting model is now more synchronized with real SaaS gating artifacts (for example, architecture readiness, performance readiness, and security testing completion) rather than legacy “preliminary versus application development” language.

Implementation considerations

Controllers and chief accounting officers at software companies should take certain actions now.

Update the organization’s policy framework and documentation package

Software companies should anticipate that the most-audited decisions will be:

• How the company defines “software project”
• How the company defines and documents “significant performance requirements”
• How the company determines whether requirements are substantially revised
• How the company shows that novel or unproven uncertainty is resolved through coding and testing

As a strong practice, companies should create a standard capitalization threshold memo template that is completed at the point they begin capitalizing for each major project and is updated when key facts change.

At a minimum, a strong capitalization threshold memo typically would document:

• The defined software project and why that level of aggregation is appropriate
• Evidence of management’s authorization and commitment to fund the project (for example, approved budgets, investment committee materials, or executed contracts)
• The identified significant performance requirements and the basis for concluding they no longer are subject to substantial revision
• Any novel or unproven functions or features and the specific coding and testing activities that resolved the related uncertainty
• The date on which significant development uncertainty was concluded to be resolved
• The basis for determining when the software was substantially complete and ready for its intended use

In practice, these are the conclusions auditors and regulators will focus on when evaluating capitalization judgments under the amended guidance.

Expect and adjust for process changes in the project accounting workflow

Many SaaS companies will need to adjust:

• Time-tracking categories (capitalizable versus noncapitalizable activities)
• Capitalization start-stop controls tied to significant development uncertainty resolution and substantial testing completion
• Governance alignment (so finance knows when performance requirements are stable)

Prepare stakeholder messaging

If capitalization patterns shift (often toward more expensing early for novel SaaS projects), companies should consider communicating certain information to shareholders:

• Implications for non-GAAP measures, EBITDA narratives, or margin explanations
• Impact on financial covenants when changes in accounting principles are not contemplated under current financing arrangements
• Forecasting and budgeting (capitalization assumptions)
• Internal key performance indicators that treat product engineering as investment, including impacts on bonus arrangements tied to financial metrics

Effective date, transition, and adoption strategy

The amendments are effective for fiscal years beginning after Dec. 15, 2027, including interim periods within those fiscal years, with early adoption permitted.

Entities are required to apply the amendments using one of the following transition methods:

• Prospective transition. Apply the amendments to new software costs incurred after the adoption date for all projects, including costs incurred for in-process projects.
• Modified transition. Prospectively apply the amendments to new software costs incurred after the adoption date for all projects, including in-process projects. For any in-process project that, as of the adoption date, no longer meets the capitalization criteria in ASC 350-40-25-12 through 25-12A but had met the capitalization requirements before that date, derecognize previously capitalized costs through a cumulative-effect adjustment to opening retained earnings (or other appropriate components of equity or net assets) as of the beginning of the annual reporting period of adoption.
• Retrospective transition. Apply the amendments retrospectively through a cumulative-effect adjustment to the opening balance of retained earnings (or other appropriate components of equity or net assets) as of the beginning of the first period presented.

For software companies, the transition method choice often turns on two practical questions:

• Is historical project documentation sufficiently robust to reassess capitalization conclusions for in-process projects under the revised guidance?
• Are the expected income statement and balance sheet effects significant enough – and investor-relevant enough – to justify retrospective application?

The codification also specifies transition-related disclosure requirements under ASC 250-10-50 that vary based on the transition method elected, including additional cumulative-effect and comparative-period disclosures for entities applying the guidance using a modified or retrospective approach.

Call to action

For SaaS and hybrid software companies, ASU 2025-06 is less about new terminology and more about redefining when capitalization begins. The amended ASC 350-40 model aligns more closely with how software is developed today, but it requires clearer, more disciplined answers to foundational questions about project definition, performance requirements, and the resolution of development uncertainty.

To navigate adoption well, companies should align finance and engineering around a repeatable, evidence-based documentation process rather than rely on tooling or legacy stage concepts. Starting early – by piloting the new framework on a significant initiative – can allow organizations to choose a transition approach deliberately, communicate the impact clearly, and avoid last-minute surprises.

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