ASU 2025-06 and ASC 350-40: The 2026 Practitioner's Guide to Software Capitalization

If your team is still capitalizing software costs by tracking when the "preliminary project stage" ends, the rules have changed. FASB issued ASU 2025-06 in September 2025, replacing the nearly 27-year-old three-stage model in ASC 350-40 with a principles-based framework built around two new concepts: a probable-to-complete recognition threshold and significant development uncertainty. This guide explains what changed, what stayed the same, and what your team needs to do before the mandatory effective date.

Key takeaway: ASU 2025-06 is the most significant change to software capitalization under ASC 350 since SOP 98-1 was codified in 1998. FASB explicitly expects more costs to be expensed under the new rules, particularly for AI-driven and agile development projects.

What Is ASC 350-40 and How Does It Govern Software Capitalization?

ASC 350-40 is the primary U.S. GAAP standard for capitalizing internal-use software development costs. It sits within ASC 350 (Intangibles, Goodwill and Other) and applies whenever a company develops or obtains software for its own operations, rather than for sale or license to customers.

The standard determines which costs go on the balance sheet as an intangible asset and which get expensed immediately. That distinction matters enormously to reported earnings, particularly for technology-intensive companies with large development headcounts.

Two other subtopics are closely related:

• ASC 985-20: Governs software developed to be sold, leased, or marketed externally. ASU 2025-06 does NOT change this standard.
• ASC 350-50: Covered website development costs. ASU 2025-06 absorbs this guidance into the revised ASC 350-40 framework.

The Old Three-Stage Model: What It Said and Why It Broke Down

Under the legacy ASC 350-40 model, software costs were divided into three stages, each with different capitalization treatment. This framework was codified from SOP 98-1 and reflected how software was built in the late 1990s: sequentially, in a waterfall.

StageWhat HappensCapitalization TreatmentPreliminary project stageFeasibility assessment, vendor evaluation, high-level requirementsAll costs expensedApplication development stageCoding, testing, installationCosts capitalized once management commits funding and completion is probablePost-implementation/operation stageTraining, maintenance, bug fixesAll costs expensed

The model worked reasonably well for waterfall development. It broke down badly for agile. In a two-week sprint, a team can move through what the old model called "preliminary" and "application development" activities in the same iteration. Identifying the precise moment the preliminary stage "ends" became an exercise in fiction for most practitioners.

The other persistent pain points:

• Post-implementation costs (maintenance, bug fixes) are frequently misclassified as capitalizable application development costs.
• General and administrative overhead and training costs are sometimes incorrectly capitalized.
• The unit of account question (what counts as a single "project"?) was never clearly defined, leading to inconsistent application across companies.

How ASU 2025-06 Changes Software Capitalization Under ASC 350-40

ASU 2025-06 removes all references to project stages from ASC 350-40 and replaces them with two affirmative criteria that must both be met before any costs can be capitalized. As quoted in Deloitte's Heads Up publication, the new capitalization criteria are:

1. "Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding a computer software project."
2. "It is probable that the project will be completed and the software will be used to perform the function intended" (the probable-to-complete recognition threshold).

The probable-to-complete threshold is not met until significant development uncertainty has been resolved. This is the new, substantive gating concept.

What Is "Significant Development Uncertainty"?

Significant development uncertainty exists if either of the following conditions is present:

• The software has technological innovations or novel, unique, or unproven functions or features, and the uncertainty related to those has not been resolved through coding and testing; OR
• The significant performance requirements of the software have not been identified, or the identified requirements continue to be substantially revised.

Both conditions must be absent before capitalization can begin. The FASB defines "performance requirements" as "what an entity needs the software to do (for example, functions or features)" -- consistent with how the term was used in the old preliminary project stage definition, which provides some continuity.

The practical effect: for software built on proven technology with well-defined requirements, the new model may not change the capitalization start date much. For software involving novel technology -- particularly AI and large language models -- the new model will delay capitalization significantly. FASB explicitly expects more software development costs to be expensed under the revised guidance.

Capitalizing AI and LLM-Based Software Under ASU 2025-06

This is where ASU 2025-06 has the sharpest teeth, and where most existing guidance leaves practitioners without a worked example.

For AI-powered software built on large language models or other novel technology, the significant development uncertainty concept will typically delay capitalization well past the point of management funding approval. Deloitte's Heads Up includes an illustrative example involving Entity Y, a company building an AI-powered accounting tool with two components:

• An "extract" functionality using off-the-shelf technology (no significant development uncertainty)
• A "write" functionality using a novel LLM-based approach to generate accounting outputs (significant development uncertainty present)

The timeline for the write functionality shows how long capitalization can be delayed:

DateEventCapitalization StatusJanuary 15CEO approves fundingNot yet -- significant development uncertainty existsFebruary 28AI specialists hired; LLM service contract signedNot yet -- uncertainty remains unresolvedJune 30Specific performance requirements identifiedNot yet -- novel technology uncertainty still unresolvedSeptember 30AI specialists resolve development risk through coding and testingCapitalization begins

That is approximately 8.5 months from funding approval to the first capitalizable dollar -- entirely because the LLM-based functionality was novel and unproven. As Deloitte's example states: "Because the provider has not successfully delivered the analytical layer in the past, the software has unproven functions or features that have been identified and the uncertainty related to the development of the unproven functions or features has not been resolved through coding and testing; therefore, significant development uncertainty exists."

Can AI Model Training Costs Be Capitalized?

Yes, under the right conditions. Once the capitalization threshold is met, costs for training an AI model that are necessary to establish that the software can perform its intended function may be capitalized. In Deloitte's Entity Y example, the company capitalizes training costs through the date the model is validated as performing the performance obligation assessment in accordance with design specifications. Training costs incurred before the development uncertainty is resolved are expensed.

The Unit-of-Account Question: One Project or Two?

The Entity Y example also surfaces a critical new judgment area that ASU 2025-06 introduces but does not fully resolve: what constitutes a single "software project" for capitalization purposes?

BDO notes that entities must determine whether a software project is "a new product, a distinct module, or a major feature or function to an existing product." For Entity Y, two views are defensible:

• View A: Extract and write functionality are a single project. Capitalization of all costs is delayed until the novel write functionality uncertainty is resolved (September 30).
• View B: Each functionality is a separate project because extract can be delivered independently. Extract costs are capitalized from January 15; write costs are delayed until September 30.

This unit-of-account judgment will require documented accounting policy decisions and robust audit support. Companies building products that mix standard and AI-powered features should establish their policy before adoption.

Cloud and SaaS Implementation Costs: What ASU 2025-06 Does NOT Change

A common misconception: ASU 2025-06 does not change the rules for cloud computing and SaaS implementation costs. Those rules come from a different update.

ASU 2018-15 added guidance to ASC 350-40 requiring customers in a cloud computing arrangement that is a service contract to apply the same capitalization model as internal-use software to their implementation costs. This guidance remains in force and is separate from the ASU 2025-06 amendments.

The practical distinction that matters:

Arrangement TypeApplicable GuidanceKey QuestionSoftware license (on-premise or perpetual)ASC 350-40 (ASU 2025-06 framework)Does the arrangement convey a software license?Cloud/SaaS service contract (no license)ASC 350-40 (ASU 2018-15 framework)Which implementation stage were the costs incurred in?External-use software (sold/licensed to customers)ASC 985-20Has technological feasibility been established?

PwC's Financial Statement Presentation guide highlights that presentation of capitalized implementation costs for hosting arrangements remains a key practical issue -- these costs are often presented as prepaid assets rather than intangible assets, and the disclosure treatment differs accordingly.

For teams unsure whether a cloud arrangement conveys a software license, the classification analysis under ASC 350-40 is the threshold question. Get that wrong and the entire capitalization framework shifts.

ASU 2025-06 vs. ASC 985-20: Do the Two Models Now Align?

ASU 2025-06 was designed to bring ASC 350-40 closer to ASC 985-20 by incorporating a concept of unresolved development uncertainty as a barrier to capitalization -- similar to the "technological feasibility" threshold in ASC 985-20. In many cases, the two models will now produce similar outcomes.

But BDO cautions that "differences in capitalization thresholds might continue to exist between the two models because of certain nuanced differences in the guidance." Companies that develop software both for internal use and for sale or license need to maintain separate analyses under each standard and should not assume convergence is complete.

Effective Date, Early Adoption, and Transition Options

ASU 2025-06 is effective for fiscal years beginning after December 15, 2027, and interim periods within those fiscal years. Early adoption is permitted. Per EY's analysis, the guidance applies to all entities.

Three transition methods are available, each with distinct financial statement implications:

Transition MethodHow It WorksP&L / Retained Earnings ImpactKey DisclosureProspectiveApply new rules to costs incurred after adoption date for all projects, including in-processNo restatement; prior capitalized costs stay on balance sheetNature and reason for change per ASC 250-10-50-1(a)Modified prospectiveApply prospectively to new costs; derecognize capitalized costs on in-process projects that no longer qualify through a cumulative-effect adjustment to opening retained earningsRetained earnings hit for in-process projects that fail new criteriaNature and reason for change plus cumulative effect on retained earningsRetrospectiveRecast comparative periods; cumulative-effect adjustment to opening retained earnings as of the beginning of the first period presentedMost complex; full restatement of comparativesFull comparative period disclosure

Choosing the right method requires modeling. A company with a large in-process software portfolio -- particularly one involving AI or novel technology projects that would not meet the new significant development uncertainty threshold -- faces a material retained earnings write-down under the modified prospective or retrospective approaches. The prospective method avoids that hit but leaves legacy capitalized costs on the balance sheet under the old model until they amortize off.

For companies considering early adoption, the case is strongest if your current portfolio is relatively clean (few in-process projects with significant development uncertainty) and you want to align your accounting policy with agile development practices before the mandatory date.

Disclosure Changes: From ASC 350-30 to ASC 360-10

ASU 2025-06 also changes what you disclose and where. Under the new standard, entities must apply the disclosure requirements in ASC 360-10 (Property, Plant, and Equipment) to all capitalized internal-use software costs and related amortization, regardless of how those costs are presented in the financial statements. Entities are no longer required to provide intangible asset disclosures under ASC 350-30 for internal-use software.

This is a practical compliance change that financial reporting teams should flag now. The ASC 360-10 disclosure framework -- gross carrying amount, accumulated amortization, amortization expense, and estimated future amortization -- is familiar from PP&E disclosures but may require updates to footnote templates and disclosure checklists currently built around the ASC 350-30 intangibles model.

What Your Team Needs to Do Before Adoption

The transition to ASU 2025-06 is not just an accounting policy update. It requires new processes, controls, and audit documentation.

1. Inventory in-process projects. Identify which current projects involve novel, unique, or unproven technology. These are the candidates for a retained earnings impact under modified prospective or retrospective transition.
2. Define your unit-of-account policy. Establish and document what constitutes a "software project" for capitalization purposes. This is a new, judgment-intensive area that auditors will scrutinize.
3. Build a significant development uncertainty assessment process. Under the old model, you documented when the preliminary stage ended. Under the new model, you document when development uncertainty is resolved through coding and testing. That requires a different set of evidence -- milestone sign-offs, testing results, and engineering attestations.
4. Model the three transition options. Run the numbers on prospective, modified prospective, and retrospective transition before committing. The P&L and retained earnings impacts can be material for companies with large software development portfolios.
5. Update disclosure templates. Shift internal-use software footnote disclosures from the ASC 350-30 intangibles framework to ASC 360-10 PP&E-style disclosures.
6. Assess income tax implications. Transitioning to ASU 2025-06 may change the book-tax timing difference on capitalized software, affecting deferred tax assets and liabilities. Coordinate with your tax team before electing a transition method.
7. Review cloud/SaaS arrangements separately. Confirm that your team understands the ASU 2018-15 rules remain in force and are not superseded by ASU 2025-06.

For teams working through the technical memo to support their capitalization policy, the documentation standards for a judgment-intensive area like significant development uncertainty are high. See how to draft a technical accounting memo that survives audit and SEC review for the documentation framework auditors and SEC staff expect.

FAQ

Can you capitalize software costs under U.S. GAAP?Yes. ASC 350-40 requires capitalization of qualifying internal-use software development costs once both the probable-to-complete recognition threshold and the absence of significant development uncertainty conditions are met under ASU 2025-06. Before adoption of ASU 2025-06, costs in the application development stage are capitalized under the legacy three-stage model.

What is the effective date of ASU 2025-06?ASU 2025-06 is effective for fiscal years beginning after December 15, 2027, and interim periods within those fiscal years. Early adoption is permitted for all entities.

Does ASU 2025-06 change the rules for SaaS and cloud implementation costs?No. Cloud computing implementation costs for service contracts continue to be governed by the ASU 2018-15 amendments to ASC 350-40. ASU 2025-06 does not change those rules.

Does ASU 2025-06 affect external-use software under ASC 985-20?No. The technological feasibility model in ASC 985-20 remains unchanged. Companies developing software for sale or license to customers continue to apply ASC 985-20.

How does the new standard handle agile development?By removing all references to project stages, ASU 2025-06 is explicitly neutral to development methodology. Teams no longer need to map sprints to the old waterfall-aligned stages. Capitalization begins when management commits funding, completion is probable, and significant development uncertainty has been resolved through coding and testing -- regardless of whether development is agile, waterfall, or hybrid.

What happens to capitalized costs on in-process projects when we adopt ASU 2025-06?It depends on the transition method elected. Under the prospective approach, existing capitalized costs stay on the balance sheet and continue amortizing. Under the modified prospective approach, capitalized costs on in-process projects that no longer meet the new criteria are derecognized through a cumulative-effect adjustment to opening retained earnings. Under the retrospective approach, comparative periods are recast.

Are AI model training costs capitalizable under ASU 2025-06?Yes, once the capitalization threshold is met. Training costs necessary to establish that the software can perform its intended function may be capitalized after significant development uncertainty has been resolved through coding and testing. Training costs incurred before that point are expensed.

The KPMG February 2026 handbook on software and website costs -- which incorporates updated interpretations for ASU 2025-06 and AI data costs -- is the most current comprehensive reference for teams working through the detailed application questions.