ASC 350-40 Guide: Practitioner Walkthrough for 2026

If your team is still mapping sprint costs to the "preliminary project stage," this guide is for you. ASC 350-40 governs internal-use software capitalization under U.S. GAAP, and ASU 2025-06 rewrites the rules that have been in place since 1998. The mandatory effective date is January 1, 2028 for calendar-year entities, but the decisions your team makes right now, on early adoption, transition method, and cost-tracking redesign, will shape your financial statements for years.

This walkthrough is for controllers, CFOs, and technical accounting teams at mid-to-large enterprises who need to operate correctly under both the current model and the new one. For a side-by-side comparison of the old and new frameworks, see our ASC 350-40 software capitalization guide. For the detailed capitalize-vs-expense decision tree, see our capitalize vs. expense practitioner walkthrough. This article goes deeper on the how-to: sequencing the new capitalization test, evaluating significant development uncertainty, handling AI development costs, choosing a transition method, and updating your disclosures.

Key takeaway: ASU 2025-06 is the first major overhaul of ASC 350-40 in over 25 years. The FASB explicitly expects more costs to be expensed under the new model. Finance teams that wait until 2027 to prepare will face a compressed timeline on a complex transition.

What Does ASC 350-40 Cover?

ASC 350-40 (Intangibles, Goodwill and Other, Internal-Use Software) is the U.S. GAAP standard governing when entities capitalize versus expense software development costs for internal use. Its scope is broader than most practitioners assume.

The standard covers three categories:

• Software developed or obtained for internal operations (ERPs, data platforms, internal tools)
• Implementation costs of cloud computing arrangements (CCAs) that are service contracts (per ASU 2018-15)
• Website development costs (absorbed from ASC 350-50 by ASU 2025-06)

Two subtopics sit alongside ASC 350-40 and are frequently confused with it:

For SaaS providers, the scope question is frequently misread. If you host the software and sell access to it, ASC 350-40 applies to your development costs, not ASC 985-20. The test turns on whether the customer can take possession of the software and operate it independently. Deloitte's Heads Up on ASU 2025-06 notes that the ASU does not fully align ASC 350-40 with ASC 985-20, so practitioners still need to understand both models.

The Current Three-Stage Model (Pre-ASU 2025-06)

Under the current rules, which remain in effect until you adopt ASU 2025-06 (mandatory January 1, 2028), capitalization depends entirely on which of three project stages a cost falls into.

The three stages and their treatment:

This model was codified from SOP 98-1 in 1998 and reflects how software was built then: sequentially, in a waterfall. It broke down badly for agile. In a two-week sprint, a team moves through what the old model calls "preliminary" and "application development" activities in the same iteration. Identifying the precise moment the preliminary stage ends became an exercise in judgment that produced inconsistent results across companies and audit engagements.

The persistent pain points practitioners report under the current model:

• Stage boundary disputes: Auditors and preparers frequently disagree on when the application development stage begins, directly affecting how much gets capitalized.
• Post-implementation misclassification: Maintenance and bug-fix costs are regularly (and incorrectly) capitalized as application development costs.
• CCA awkwardness: ASU 2018-15 requires customers in CCA service contracts to mirror the same three-stage model, which is equally unworkable in agile environments.
• Unit-of-account ambiguity: The standard never clearly defined what constitutes a single "project," leaving teams to make inconsistent calls on whether a module or feature is a separate project.

How ASU 2025-06 Replaces the Stage Model

ASU 2025-06, issued September 18, 2025, removes all references to project stages from ASC 350-40 and replaces them with two affirmative conditions that must both be satisfied before any costs can be capitalized.

As FASB Chair Richard R. Jones stated at issuance: "Modernizing software accounting guidance was a top priority identified by stakeholders during our last agenda consultation. The new ASU addresses changes in software development methods, increasing the operability of the recognition guidance for improved financial reporting."

The two conditions are:

1. Management authorization and funding commitment. Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding the software project.
2. Probable-to-complete threshold. It is probable the project will be completed and the software will be used to perform the function intended.

"Probable" uses the ASC Master Glossary definition: the future event or events are likely to occur. That is a higher bar than "reasonably possible."

Critically, the probable-to-complete threshold is not met while significant development uncertainty exists. This is the new gating concept, and it is where most of the new judgment calls live.

What Is Significant Development Uncertainty?

Significant development uncertainty blocks capitalization even after management has authorized funding. Per ASC 350-40-25-12A as quoted in Deloitte's Heads Up, it exists when either of the following is present:

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

"Performance requirements" means what the entity needs the software to do (functions or features). This is consistent with how the term was used in the preliminary project stage under the old model.

The uncertainty must be resolved through coding and testing, not through planning documents or management sign-off. For audit purposes, document the resolution event with:

• A dated technical memo from the development team confirming the novel functionality was successfully demonstrated
• Test results or proof-of-concept outputs establishing the software can perform its intended function
• Sign-off from an engineer or technical lead with relevant authority

BDO's July 2026 Blueprint notes that the ASU "introduces new areas of judgment in determining whether and when to capitalize software costs based on the facts and circumstances including whether the probable-to-complete recognition threshold is met or significant development uncertainty exists."

Applying the Two-Part Test: Step by Step

Here is how to sequence the analysis for any software project under ASU 2025-06:

1. Define the unit of account. Determine what constitutes the "software project" for capitalization purposes. Is it the full product, a distinct module, or a major feature that can be delivered independently? This is now a key judgment call (see the unit-of-account section below).
2. Check condition one: management authorization. Has management, with relevant authority, explicitly or implicitly authorized and committed to funding this project? Document the approval event and date.
3. Check condition two: probable-to-complete. Is it probable the project will be completed and the software used as intended? If yes, move to step four. If no, expense all costs.
4. Assess significant development uncertainty. Does either sub-condition apply? If the software involves novel, unique, or unproven technology with unresolved uncertainty, or if significant performance requirements are not yet identified or are being substantially revised, capitalization cannot begin. Expense costs until the uncertainty is resolved.
5. Begin capitalizing. Once both conditions are met and no significant development uncertainty exists, capitalize eligible costs from that date forward.
6. Monitor continuously. If the capitalization criteria are no longer met at any point, stop capitalizing and apply impairment guidance under ASC 350-40 to the existing capitalized balance.

The Unit-of-Account Question: New Product, Module, or Feature?

How you define the "software project" directly determines when capitalization begins, and the new framework makes this judgment more consequential than ever.

Under the old stage model, the unit of account was implicit in the stage assessment. Under ASU 2025-06, defining the project boundary is an explicit, documented judgment that auditors will scrutinize.

Deloitte's Heads Up provides a concrete illustration using Entity Y, a company building an AI-powered accounting tool with two functionalities: extract (pulling data from contracts) and write (generating accounting entries). Two views are permissible:

• View A: Extract and write are funded as a single project and represent a single unit of account. Capitalization for the entire project cannot begin until significant development uncertainty is resolved for the project as a whole.
• View B: Because the extract functionality can be delivered independently, each functionality is a separate software project. Entity Y begins capitalizing costs allocable to the extract project as soon as that project meets the two-part test, even while the write project remains in the uncertainty phase.

The practical implication: if your development team can deliver a module or feature independently, treating it as a separate unit of account may allow earlier capitalization for that component. Document the rationale and apply it consistently.

AI Software Development Costs Under ASC 350-40

AI-related software development costs, including LLM training data, data labeling, model fine-tuning, and third-party API costs, have no explicit guidance in ASC 350-40. Practitioners are making judgment calls, and the Deloitte worked example is the most authoritative anchor available.

As KPMG's February 2026 handbook states: "This edition tackles new accounting questions stemming from the rapid advancement of AI, particularly concerning AI data costs." BDO's July 2026 Blueprint similarly notes: "As artificial intelligence (AI) training and data conversion costs become more prevalent, new practice issues may arise that are not directly addressed by the guidance."

The Deloitte AI tool example (Entity Y) illustrates how the new threshold applies in practice. The key dates and outcomes:

Once the threshold was met after September 30, eligible costs included:

• Costs related to the in-house model development
• Costs for implementing the third-party LLM model
• Model training costs necessary to establish that the write functionality can perform the performance obligation assessment (through December 15)

A critical nuance from the same example: off-the-shelf software does not automatically satisfy the threshold. Because the OTS provider had not successfully delivered the analytical layer in the past, the software had unproven functions and the uncertainty had not been resolved through coding and testing. The probable-to-complete threshold was not met even for the OTS component.

For AI projects, apply this checklist before capitalizing any costs:

• Has management formally authorized and committed funding? Document the date and approver.
• Is the underlying technology (LLM, model architecture, training approach) proven for this specific use case, or is it novel and unproven?
• Have significant performance requirements been identified and stabilized, or are they still being substantially revised?
• Has the development team resolved the technological uncertainty through coding and testing? Document the test results.
• If using a third-party LLM or OTS model, has the provider successfully delivered this specific functionality before?

Cloud Computing and SaaS Implementation Costs (ASU 2018-15)

For customers in cloud computing arrangements that are service contracts, ASU 2018-15 requires applying the same capitalization model as internal-use software to implementation costs. ASU 2025-06 does not substantively change this.

The first question to answer for any CCA is whether the arrangement contains a software license:

• Contains a software license: The license element follows ASC 350-40 (internal-use software). Implementation costs also follow ASC 350-40.
• Service contract only (no license): ASU 2018-15 applies. Implementation costs are capitalized or expensed by mirroring the internal-use software model.

Under the current (pre-ASU 2025-06) model, CCA implementation costs are mapped to the same three stages as internal-use software. Under ASU 2025-06, the same two-part test and significant development uncertainty concept will apply to CCA implementation costs. This is a meaningful operational change for teams implementing major SaaS platforms: the stage-based mapping exercise goes away, replaced by the judgment-based threshold assessment.

Balance sheet presentation for capitalized CCA implementation costs: present as a prepaid or other asset, not as an intangible asset. This is a common error that generates SEC comment letters.

Choosing a Transition Method for ASU 2025-06

Three transition methods are available. The choice affects your balance sheet, retained earnings, and comparability, and it needs to be made before adoption. For calendar-year entities, mandatory adoption is January 1, 2028, but early adoption is permitted as of the beginning of any annual period.

The modified prospective method deserves particular attention. If your entity has capitalized significant costs for in-process projects under the old stage model, and those projects would not meet the new probable-to-complete threshold (because significant development uncertainty still exists), those capitalized balances must be derecognized through retained earnings at adoption. For a company with a $50M annual software development budget and substantial in-process balances, this can be a material balance sheet event.

Decision framework for early adoption:

• Adopt early (2026 or 2027) if: Your development team uses agile or iterative methods and the stage-based model is creating audit friction; you have few in-process projects with large capitalized balances that would need to be derecognized; or you want to align with the new model before the 2028 rush.
• Wait until 2028 if: You have significant in-process capitalized balances that would fail the new threshold and trigger a material retained earnings adjustment; or your development profile is primarily proven technology with well-defined requirements, meaning the new model changes little for you.

Under the prospective transition approach, ASC 250 requires disclosing the nature and reason for the change in accounting principle in both interim (if applicable) and annual reporting periods.

Disclosure Requirements: What Changed

ASU 2025-06 changes the disclosure framework for capitalized internal-use software. Many teams are still applying the wrong standard.

The change is straightforward but frequently missed:

• Required: Apply ASC 360-10 (Property, Plant, and Equipment) disclosure requirements to all capitalized internal-use software costs and related amortization, regardless of financial statement presentation.
• Not required: Intangible asset disclosures under ASC 350-30 (Intangibles, Goodwill and Other, General Intangibles Other than Goodwill) are not required for internal-use software.

Practically, this means your financial statement notes should disclose capitalized software costs and amortization consistent with PP&E disclosure conventions, including gross carrying amount, accumulated amortization, and amortization expense for the period. If you have been providing ASC 350-30 intangible asset disclosures for internal-use software, those are no longer required (though not prohibited).

For website development costs, ASU 2025-06 absorbs ASC 350-50 into the ASC 350-40 framework. Entities that previously applied ASC 350-50 separately should confirm their accounting policies and disclosures align with the consolidated ASC 350-40 framework after adoption.

Impairment: What Happens If the Criteria Are No Longer Met

If a project that was being capitalized stops meeting the capitalization criteria, you cannot simply continue amortizing the existing balance. Impairment guidance applies immediately.

Per BDO's July 2026 Blueprint, if the capitalization criteria are no longer met for software being developed, the entity cannot capitalize further costs and must apply impairment guidance to existing capitalized asset balances.

This is a practical risk under the new model. Consider a project where:

1. Management authorized funding and the probable-to-complete threshold was met.
2. Costs were capitalized for several months.
3. A significant revision to performance requirements occurs, reinstating significant development uncertainty.

At that point, capitalization stops and the existing balance is tested for impairment. Document the triggering event and the impairment assessment contemporaneously.

Updating Your Cost-Tracking Systems

The old model required tracking costs by project stage. The new model requires tracking costs by project and assessing the significant development uncertainty threshold. These are fundamentally different operational requirements.

Steps to prepare your cost-tracking infrastructure:

1. Redefine project units of account. Work with development leads to establish which products, modules, and features constitute separate "software projects" for accounting purposes. Document the rationale.
2. Replace stage-gate tracking with threshold-event tracking. Instead of tagging costs to "preliminary," "application development," or "post-implementation" buckets, track costs by project and record the date the two-part test was first met (and any date it ceased to be met).
3. Create a significant development uncertainty log. For each project, maintain a contemporaneous record of: (a) the nature of any novel or unproven technology; (b) the status of performance requirements; and (c) the coding and testing milestones that resolved the uncertainty.
4. Update time-reporting codes. If your engineers log time to project-stage codes, those codes need to be replaced with project-level codes tied to the new threshold framework.
5. Establish a capitalization start-date protocol. The date the two-part test is first met is the capitalization start date. This date should be documented, approved by technical accounting, and stored in your project accounting system.
6. Build an AI project sub-protocol. For any project involving novel AI technology (LLMs, custom model training, fine-tuning), apply the additional checklist from the AI section above before any costs are capitalized.

FAQ

What is the difference between ASC 350-40 and ASC 985-20? ASC 350-40 covers software developed for internal use, including software used to provide services to customers (SaaS providers). ASC 985-20 covers software developed to be sold, leased, or marketed externally as a standalone product. ASU 2025-06 does not change ASC 985-20. The key practical test: can the customer take possession of the software and run it independently? If yes, ASC 985-20 likely applies.

What is ASC 350-40-30-1? ASC 350-40-30-1 addresses initial measurement of capitalized internal-use software costs. It establishes that capitalized costs are measured at cost, including direct costs of materials and services consumed in developing the software, payroll and payroll-related costs for employees directly associated with the project, and interest costs incurred during development for certain entities.

When does ASU 2025-06 take effect? Mandatory adoption is for annual periods beginning after December 15, 2027, meaning January 1, 2028 for calendar-year entities. Early adoption is permitted as of the beginning of any annual reporting period. The same effective date applies to all entities: public companies, private companies, and not-for-profit entities.

Will ASU 2025-06 result in more or less capitalization? The FASB explicitly stated it expects more software development costs to be expensed under the new model compared to the old stage-based approach, due to the significant development uncertainty concept. The impact varies by entity: companies building on proven technology with stable requirements may see little change; companies developing novel AI or other innovative software will likely capitalize less and expense more.

How does ASC 350-40 apply to website costs after ASU 2025-06? ASU 2025-06 absorbs ASC 350-50 (website development costs) into the ASC 350-40 framework. Website development costs are now governed by the same two-part test and significant development uncertainty concept as internal-use software.

What disclosures are required for capitalized internal-use software under ASU 2025-06? Entities must apply ASC 360-10 (PP&E) disclosure requirements to all capitalized internal-use software costs and related amortization. ASC 350-30 intangible asset disclosures are not required for internal-use software.

The 2028 mandatory effective date feels distant. It is not. Defining project units of account, redesigning cost-tracking systems, modeling the retained earnings impact of each transition method, and building the significant development uncertainty documentation protocol all take time. Finance teams that start in 2026 will have choices. Those that wait until late 2027 will not.