ASC 350-40 Development Stage Capitalization: 2026 Practitioner Walkthrough

If your team is trying to decide whether to capitalize or expense a specific batch of software development costs right now, this guide walks you through the decision, step by step. It covers the current three-stage model (still in force for most companies through at least 2027), the new ASU 2025-06 threshold that replaces it, and the hardest judgment calls your team will face in practice, including AI model training costs and the unit-of-account question.

Key takeaway: Under the legacy ASC 350-40 model, capitalization is required during the application development stage once management commits funding and completion is probable. Under ASU 2025-06, the stage model is gone, replaced by a two-part probable-to-complete threshold with a significant development uncertainty gate. For AI projects, that gate can delay capitalization by months, even after management approval.

What Is ASC 350-40 Development Stage Capitalization?

ASC 350-40 governs when a company must capitalize, rather than expense, costs incurred to develop or obtain software for internal use. The standard sits within ASC 350 (Intangibles, Goodwill and Other) and applies whenever software is built or acquired for the company's own operations, or to deliver services to customers (including SaaS providers).

The capitalization decision matters enormously to reported earnings. Capitalizing shifts costs to the balance sheet and amortizes them over the software's useful life; expensing hits the income statement immediately. For a company with a $20 million annual development headcount, the difference between capitalizing 60% and 30% of those costs is a $6 million swing in operating income in year one alone.

ASC 350-40 does NOT apply to software developed for sale or license to third parties. That falls under ASC 985-20, which uses a much later capitalization trigger (technological feasibility) and results in most development costs being expensed. If you are unsure which standard applies to your project, start with the two-question scope test covered in our ASC 350-40 vs. ASC 985-20 comparison.

Step 1: Confirm You Are in the Right Standard

Before applying any capitalization rules, confirm ASC 350-40 is the right standard. The two-question test from Crowe's practitioner analysis:

1. Can the customer take possession of the software during the hosting or subscription period without a significant penalty?
2. Can the customer operate the software independently, or contract with an unrelated third party to host it?

If both answers are yes, ASC 985-20 likely applies. If either answer is no, you are in ASC 350-40 territory.

One common misconception: ASC 350-40 is not just for technology companies. Manufacturers building robotic production software, banks developing online banking tools, healthcare organizations enhancing electronic patient record systems, and sales organizations building CRM platforms all fall under ASC 350-40 when that software is for internal use.

Step 2: Apply the Current Three-Stage Model (Pre-ASU 2025-06)

For most companies in 2026, the legacy three-stage model still applies. ASU 2025-06 is mandatory only for annual periods beginning after December 15, 2027 (calendar-year 2028 for most public companies). Early adoption is permitted, but if your team has not adopted yet, you are still operating under the original framework.

The three stages and their capitalization treatment:

Capitalization begins when two conditions are both satisfied:

• Management with relevant authority authorizes and commits to funding the project.
• It is probable the project will be completed and the software will be used as intended.

From that point forward, the following costs are capitalizable under ASC 350-40-30-1:

• External direct costs of materials and services consumed in developing the software
• Payroll and payroll-related costs for employees directly associated with the project
• Interest costs incurred during the development period

Costs that are never capitalizable, regardless of stage:

• Training costs
• Data conversion costs (except for costs to develop or obtain software that allows access or conversion of old data)
• General and administrative overhead
• Maintenance and routine bug fixes after the software is placed in service

The Agile Problem

The three-stage model was designed for waterfall development. In a two-week agile sprint, a team can move through what the old model calls preliminary and application development activities in the same iteration. There is no clean moment when the preliminary stage ends.

In practice, most teams document the stage transition by reference to a formal management authorization event: a project charter sign-off, a steering committee approval, or a committed budget allocation. The documentation does not need to be elaborate, but it does need to exist. Auditors reviewing capitalized software balances will ask for it.

Post-implementation costs are the most common misclassification error. Bug fixes and maintenance after go-live are expensed, full stop. If your team is capitalizing costs labeled as enhancements, each one requires a separate analysis: does it add new functionality (potentially capitalizable) or maintain existing functionality (expensed)?

Step 3: Apply the New ASU 2025-06 Threshold (If You Have Early-Adopted or Are Planning Ahead)

FASB issued ASU 2025-06 on September 18, 2025, replacing the three-stage model entirely. The new standard removes all references to project stages from ASC 350-40 and replaces them with a two-part capitalization test.

Capitalization begins when BOTH of the following are met:

1. Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding the 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 gating concept, and it is where most of the judgment lives.

What Is Significant Development Uncertainty?

Per ASC 350-40-25-12A as amended by ASU 2025-06, significant development uncertainty exists if EITHER of the following 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.
• 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. Once significant development uncertainty is resolved, capitalization starts for costs incurred from that point forward.

For software built on proven technology with well-defined requirements, the new model may not change the capitalization start date materially. 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.

Step 4: Handle AI and Novel Technology Projects

This is where ASC 350-40 development stage capitalization gets genuinely hard in 2026, and where most existing guidance leaves practitioners without a concrete framework.

For AI-powered software built on large language models or other novel technology, the significant development uncertainty concept in ASC 350-40-25-12A will typically delay capitalization well past management approval. Deloitte's Heads Up analysis of ASU 2025-06 includes a detailed worked example (Entity Y) that illustrates exactly how this plays out.

The Entity Y timeline (AI-enabled accounting tool with an LLM-based "write" functionality):

The gap between management approval (January 15) and the start of capitalization (September 30) is approximately 8.5 months. Every dollar of eligible development cost incurred in that window is expensed, regardless of how confident management is that the project will succeed.

As Deloitte's analysis states: "Eligible software development costs incurred after September 30, 20X0, would be capitalized, including those related to the model developed in-house and implementing the LLM model. Entity Y would capitalize the costs incurred for training the model that were necessary to establish that the write functionality can perform the performance obligation assessment in accordance with the design specifications through December 15, 20X0."

The practical implication: AI model training costs ARE capitalizable under ASU 2025-06, but only after the significant development uncertainty gate is cleared through coding and testing. Proof-of-concept costs, early model development, and iterative training runs before that gate is cleared are expensed.

Documenting the Resolution of Development Uncertainty

For AI projects, the documentation question is critical. Auditors will ask: how did you determine that development uncertainty was resolved? The answer needs to be specific and evidence-based, not a management assertion.

Practical documentation checklist for AI projects:

• Written summary of the specific novel or unproven functions at project inception
• Records of coding and testing milestones, with dates
• Technical sign-off from the development team (or AI specialists) confirming that the novel technology risk has been resolved
• Description of what "resolved" means for this specific project (e.g., model achieves target accuracy on validation dataset, specific performance requirement met in testing)
• Board or steering committee minutes or memos referencing the resolution event

The documentation does not need to be a formal deliverable, but it does need to exist before the close. Reconstructing it after the fact is an audit risk.

Step 5: Determine the Unit of Account

The unit-of-account question, when is a software project one asset versus multiple, is one of the highest-stakes judgment calls in ASC 350-40, and it is almost never addressed in practice guides.

The Deloitte Entity Y example illustrates both views:

View A (single unit of account): The extract and write functionalities are funded as a single project. Capitalization cannot begin until the novel-technology uncertainty for the write functionality is resolved in September. All costs incurred before September are expensed, including costs attributable to the extract functionality (which uses proven technology).

View B (separate units of account): Because Entity Y can deliver the extract functionality independently of the write functionality, each represents a separate software project. As Deloitte notes: "Because it is probable that the extract functionality will be completed (i.e., there isn't significant development uncertainty associated with the software project), Y begins capitalizing eligible development costs allocable to such software project" from January 15.

The difference in capitalized costs between View A and View B can be substantial for a large project. The key question is whether each functionality can be delivered and used independently. If yes, separate unit-of-account treatment is defensible and should be considered.

Practical guidance for multi-module platforms:

• Document at project inception whether each module or functionality can be placed in service independently.
• If modules are genuinely interdependent (one cannot function without the other), treat them as a single project.
• If modules can be delivered and used independently, even if developed concurrently, separate unit-of-account treatment is supportable.
• Apply the unit-of-account determination consistently across similar projects and document the policy.

Step 6: Decide Whether to Early-Adopt ASU 2025-06

Early adoption of ASU 2025-06 is permitted as of the beginning of any annual reporting period. The mandatory effective date for public business entities is annual periods beginning after December 15, 2027 (calendar-year 2028). For all other entities, the mandatory date is annual periods beginning after December 15, 2028.

The early-adoption decision is not symmetric. Who benefits and who does not:

Transition options under ASU 2025-06 (per FASB's project page):

1. Prospective: Apply the new threshold to costs incurred after adoption. Previously capitalized amounts are not restated. Simplest operationally.
2. Modified prospective: Apply prospectively to new costs. For in-process projects that met the old threshold but do not meet the new one, derecognize capitalized costs through a cumulative-effect adjustment to opening retained earnings.
3. Retrospective: Recast comparative periods with a cumulative-effect adjustment to opening retained earnings as of the beginning of the first period presented.

For most companies, the prospective approach minimizes disruption. The modified prospective approach is worth modeling if you have significant in-process AI projects where the new significant-development-uncertainty gate would have blocked capitalization under the new rules.

Step 7: Set Amortization and Monitor for Impairment

Capitalization is only half the story. Once software is placed in service, it must be amortized over its estimated useful life using a systematic and rational method (typically straight-line). There is no prescribed useful life under ASC 350-40; management must estimate it based on the expected period of benefit.

Practical considerations:

• Software useful lives in the 3-7 year range are common, but the right answer depends on the specific asset and how quickly technology in that domain evolves.
• AI-enabled software may have shorter useful lives than traditional software, given the pace of model improvement and competitive obsolescence.
• If a project is abandoned or significantly redesigned, the carrying amount of the capitalized software must be assessed for impairment. Write-offs of abandoned AI projects are increasingly common and require timely recognition.
• Under ASU 2025-06, the disclosure requirements of ASC 360-10 (Property, Plant, and Equipment) apply to all capitalized software costs, regardless of how they are presented in the financial statements. This means gross carrying amount, accumulated amortization, and amortization expense must be disclosed.

Common Mistakes and Audit Red Flags

Auditors are scrutinizing capitalized software balances more closely in 2026, particularly for AI projects. The most common errors:

• Capitalizing post-implementation costs. Maintenance, bug fixes, and training after go-live are expensed. Period.
• No documentation of the capitalization trigger. If you cannot point to a specific date and event when management committed funding and completion was probable, the capitalized balance is at risk.
• Treating the entire project as one unit of account when modules are independent. This can either delay capitalization unnecessarily (if one module has novel technology) or accelerate it incorrectly.
• Capitalizing AI proof-of-concept costs. Under ASU 2025-06, costs incurred before significant development uncertainty is resolved are expensed, even if management has approved the project.
• Applying ASC 350-40 to software that should be under ASC 985-20. The scope test matters. If your customer can take possession and operate the software independently, you may be in the wrong standard.
• Not reassessing the capitalization threshold when requirements change substantially. If significant performance requirements are substantially revised after capitalization begins, significant development uncertainty may re-emerge, stopping further capitalization.

FAQ

Should development costs be capitalized under ASC 350-40? Yes, but only during the application development stage (legacy model) or after the probable-to-complete threshold is met with no significant development uncertainty (ASU 2025-06 model). Preliminary and post-implementation costs are always expensed.

Can you capitalize software development costs under GAAP? Yes. ASC 350-40 requires capitalization of qualifying internal-use software development costs, not just permits it. The question is whether the specific costs meet the threshold criteria for the stage or period in which they are incurred.

How does ASC 350-40 apply to SaaS providers? SaaS providers generally fall under ASC 350-40, not ASC 985-20, because the software is used internally to provide the service rather than delivered to the customer. Apply the two-question scope test to confirm.

When does the capitalization threshold reset for an AI project? If significant performance requirements are substantially revised after capitalization begins, significant development uncertainty may re-emerge. At that point, further costs are expensed until the uncertainty is resolved again through coding and testing.

What happens to capitalized software costs when a project is abandoned? The carrying amount must be assessed for impairment immediately. If the software will not be completed or placed in service, the capitalized balance is written off to the income statement in the period the decision is made.

Does ASU 2025-06 change the rules for SaaS implementation costs? The core framework for implementation costs in cloud computing arrangements (originally addressed by ASU 2018-15) is absorbed into the revised ASC 350-40. The principles-based threshold now applies to those costs as well. FASB noted it expects a decrease in software capitalization for cloud computing arrangements under the new guidance.

For a full comparison of the old and new models side by side, see our ASC 350-40 software capitalization guide. For the ASU 2025-06 regulatory overview and effective date detail, see our ASU 2025-06 explainer.