What Is ASC 350-40? The 2026 Definitive Guide
ASC 350-40 is the FASB Accounting Standards Codification subtopic that governs how companies recognize, measure, and disclose costs incurred to develop or obtain software for internal use, and, since 2018, how they account for implementation costs of cloud computing arrangements (CCAs) that are service contracts. If your company builds software, buys SaaS, or uses AI tools in development, this standard touches your balance sheet.
In September 2025, FASB issued ASU 2025-06, the first major overhaul of ASC 350-40 in over two decades. The old three-stage waterfall model is gone. For calendar-year-end public companies, the new framework is already operative as of January 1, 2026. Most existing content on this standard still describes the superseded rules. This article explains what ASC 350-40 is, what it covers, and how it actually works today.
Key takeaway: If you are a public company with a December 31 fiscal year-end, you are already applying the post-ASU 2025-06 version of ASC 350-40. The three project stages no longer exist as capitalization triggers.
What Is ASC 350-40 Under US GAAP?
ASC 350-40, formally titled "Intangibles, Goodwill and Other, Internal-Use Software," is the primary US GAAP standard for accounting for costs to develop or obtain software that a company will use internally, not sell, lease, or market to customers. It sits within FASB's Accounting Standards Codification Topic 350 (Intangibles, Goodwill and Other), alongside subtopics covering goodwill (350-20) and general intangibles (350-30).
The standard traces back to AICPA Statement of Position 98-1, issued in 1998. For nearly 27 years, its core capitalization model remained largely unchanged, until ASU 2025-06 rewrote the recognition framework from the ground up.
As BDO notes, every entity uses software to some extent, which means ASC 350-40 applies across industries: banks building online lending platforms, manufacturers deploying robotic production software, healthcare organizations developing patient record systems, and retailers building inventory management tools all fall within its scope.
What Does ASC 350-40 Cover? Scope and Boundaries
ASC 350-40 applies to three distinct cost categories. Understanding which bucket your costs fall into is the first step before any capitalization analysis.
1. Costs to Develop or Obtain Internal-Use Software
This is the core scope. Software qualifies as "internal-use" when the company intends to use it to run its own operations or deliver services to customers, not to sell or license the software itself as a product. Examples include:
- A bank's proprietary loan origination system
- A retailer's custom inventory management application
- An insurer's claims processing platform
- Embedded software in a manufacturer's robotic equipment
2. Implementation Costs of Cloud Computing Arrangements That Are Service Contracts
When a company enters a SaaS or other hosted arrangement that does not convey a software license, the arrangement is a service contract. The ongoing service fees are expensed as incurred. But certain implementation costs, the upfront work to configure and customize the hosted software, can be capitalized under ASC 350-40's implementation cost model, using the same capitalization logic applied to internally developed software.
3. Website Development Costs (Absorbed Under ASU 2025-06)
Prior to ASU 2025-06, website development costs were governed by ASC 350-50. The new ASU absorbs that guidance into the ASC 350-40 framework, consolidating the treatment of website and internal-use software costs under a single standard. For entities with significant web development activity, this simplifies the analysis.
What ASC 350-40 Does NOT Cover
| Cost Type | Governing Standard |
|---|---|
| Software developed for external sale, lease, or marketing | ASC 985-20 |
| Goodwill and other general intangibles | ASC 350-20 / ASC 350-30 |
| Research and development costs (pre-scope determination) | ASC 730 |
| Ongoing SaaS subscription fees (not implementation costs) | Expense as incurred |
The boundary between ASC 350-40 and ASC 985-20 is a threshold scope question that must be resolved before any capitalization analysis begins. Get it wrong and you are applying the wrong standard entirely.
Why ASC 350-40 Exists: The Policy Rationale
FASB created ASC 350-40 to bring consistency to an area where practice had diverged significantly. Before the original 1998 guidance, companies treated internal-use software costs inconsistently, some expensed everything, others capitalized liberally. The standard established that software development costs meeting defined criteria represent an asset with future economic benefit, and should be recognized on the balance sheet accordingly.
The 2018 amendment (ASU 2018-15) extended the framework to CCA implementation costs, responding to the rapid shift toward SaaS and cloud-hosted applications. Without explicit guidance, companies were inconsistently expensing implementation costs that were economically equivalent to costs they would have capitalized for on-premise software.
ASU 2025-06 addresses a third wave of change: the shift from sequential (waterfall) to iterative (agile) development methods, and the emergence of AI-assisted development. The old stage-based model assumed a linear development process. Agile sprints do not work that way, planning, coding, and testing happen simultaneously, making the old stage boundaries nearly impossible to apply consistently.
The New ASC 350-40 Capitalization Framework (Post-ASU 2025-06)
Under ASU 2025-06, the three-stage model, preliminary project, application development, post-implementation, is eliminated entirely. All references to project stages have been removed from ASC 350-40. In their place, FASB introduced a principles-based, two-part capitalization test.
As KPMG summarized in its February 2026 handbook: "In September 2025, the FASB issued ASU 2025-06, marking the first major update to the internal-use software guidance in over two decades. These amendments to ASC 350-40 better align the rules with modern agile software development practices."
The Two-Part Capitalization Test (ASC 350-40-25-12)
Capitalization begins when both of the following conditions are met:
- Management authorization: Management with the relevant authority implicitly or explicitly authorizes and commits funding for the software project.
- Probable-to-complete recognition threshold: It is probable that the project will be completed and the software will be used to perform the function intended.
But there is a critical third gate that delays capitalization even after both conditions above are satisfied.
Significant Development Uncertainty: The Gate Most Practitioners Miss
The probable-to-complete threshold is not met until any "significant development uncertainty" has been resolved. This is the most consequential new concept in the standard, and it is absent from virtually every existing "what is ASC 350-40" article.
Significant development uncertainty exists when either of the following is present (ASC 350-40-25-12A):
- The software has technological innovations or novel, unique, or unproven functions or features, and the uncertainty related to those innovations 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.
"Performance requirements" is defined 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.
The practical effect: management approval and budget commitment are necessary but not sufficient to open the capitalization window. If the software involves novel technology or undefined requirements, costs must be expensed until those uncertainties are resolved through actual coding and testing.
Deloitte's illustrative example makes this concrete. In the example, Entity Y received CEO approval for a project on January 15, 20X0. But capitalization did not begin until September 30, 20X0, approximately 8.5 months later, because significant development uncertainty related to novel AI functionality was not resolved until that date through coding and testing. Costs incurred in the intervening months, including hiring AI specialists and entering into a third-party LLM service contract, were expensed as incurred.
Key takeaway: Management approval starts the clock on your commitment, not on your capitalization. Significant development uncertainty can delay the capitalization window by months, even on fully funded projects.
What Costs Are Capitalizable Once the Window Opens?
Once both conditions are met and significant development uncertainty is resolved, the following costs are generally capitalizable:
- External costs of materials and services consumed in developing the software
- Payroll and payroll-related costs for employees directly involved in development
- Interest costs incurred during development (for qualifying assets)
The following are always expensed, regardless of development stage:
- Training costs
- Data conversion costs (generally)
- General and administrative overhead
- Costs incurred after the software is substantially complete and ready for its intended use
For a step-by-step walkthrough of which specific costs qualify, see How to Capitalize Internal-Use Software Costs Under ASC 350-40.
What Is a "Software Project" Under ASC 350-40?
One of the most significant new judgment areas introduced by ASU 2025-06 is the unit-of-account question: what constitutes a "software project" for capitalization purposes?
As BDO explains: "Entities will need to apply judgment to determine what constitutes a software project, a new product, a distinct module, or a major feature or function to an existing product."
This determination matters because it affects when capitalization begins and ends for each unit of account. Deloitte illustrates two views:
- View A: Two functionalities ("extract" and "write") funded together are treated as a single software project. Capitalization cannot begin for any costs until significant development uncertainty is resolved for the entire project, including the novel "write" functionality.
- View B: Because the "extract" functionality can be delivered independently, each functionality is a separate software project. Capitalization of extract-related costs begins earlier, while write-related costs remain in the pre-capitalization phase until their uncertainty is resolved.
The unit-of-account decision is not merely academic. It can shift the capitalization start date by months and materially affect the balance sheet. Companies should document their project definition policy and apply it consistently.
ASC 350-40 and SaaS: Cloud Computing Arrangement Implementation Costs
For companies using SaaS or other hosted software, the first question under ASC 350-40 is whether the arrangement contains a software license. This is the most commonly misapplied aspect of the standard in practice.
| Arrangement Type | Accounting Treatment |
|---|---|
| CCA with a software license | License is an intangible asset under ASC 350-40 asset model; implementation costs capitalized alongside |
| CCA that is a pure service contract (e.g., SaaS) | Ongoing fees expensed as incurred; implementation costs subject to ASC 350-40 implementation cost model |
A CCA contains a software license when the customer can take possession of the software during the hosting period without significant penalty AND can operate the software independently or through an unrelated third party. Most SaaS arrangements fail both tests, they are pure service contracts.
For pure service contracts, the implementation cost model applies the same capitalization logic as internally developed software. Costs that would have been capitalizable under the internal-use software model (if the software were developed in-house) can be capitalized as a prepaid asset. Training costs and data migration costs are always expensed.
For a detailed practitioner walkthrough of CCA accounting, see ASC 350-40 Hosting Arrangement: 2026 Practitioner Walkthrough.
ASC 350-40 and AI Development Costs: The Live Practice Issue in 2026
The internal-use software accounting framework does not change merely because the development resource is an AI-enabled service rather than a person. But the nature, pricing, and evidence of AI-related costs creates new attribution challenges that the old cost-tracking infrastructure was not designed to handle.
As Deloitte notes: "A token-based charge is not capitalizable merely because it is measurable, and a fixed or subscription-based charge is not necessarily noncapitalizable merely because it is not billed by usage. The analysis should focus on the nature of the service, how and when the service is consumed, the activity supported, and whether the associated cost can be directly attributed to a qualifying software project."
For an AI tool cost to be capitalizable under ASC 350-40, it must satisfy all four of the following:
- Represent an external cost of materials or services consumed in developing internal-use software
- Be directly attributable to a specific qualifying software project
- Relate to a qualifying development activity
- Be incurred during the period in which costs for the project are eligible for capitalization
Four Fact Patterns from Deloitte's August 2026 Analysis
| Scenario | AI Tool Type | Capitalizable? | Reason |
|---|---|---|---|
| Token-based AI agent used exclusively by engineering team on a specific project | Token-based | Yes | Directly attributable to qualifying project |
| Broad organizational subscription used for coding and general productivity | Subscription | No | Cannot be directly attributed to a single project |
| Fixed subscription procured solely for a specific project, access restricted to that team | Subscription | Yes | Directly attributable despite fixed pricing |
| Hybrid pricing: fixed capacity + variable token charges, fixed portion shared across projects | Hybrid | Fixed: No / Variable: Yes if attributable | Fixed portion fails attribution test; variable tokens capitalizable if traceable |
LLM model training costs present a further nuance. Under ASU 2025-06, costs to train an in-house model may be capitalizable if they are necessary to establish that the software can perform its intended function, but only after significant development uncertainty is resolved. In Deloitte's Entity Y example, LLM training costs were capitalized starting September 30, 20X0, once the novel development risk was resolved through coding and testing.
The infrastructure implication: Historical processes for tracking and attributing personnel costs to projects are often insufficient for AI-related costs, particularly when AI services are shared across users, projects, or business functions. Companies need to redesign their project cost-tracking systems to capture AI service consumption at the project level, or lose capitalization eligibility entirely.
As KPMG's February 2026 handbook cautions: "As AI training and data conversion costs become more prevalent, new practice issues may arise that are not directly addressed by the guidance."
ASC 350-40 Disclosure Requirements
ASU 2025-06 clarifies which disclosure framework applies to capitalized internal-use software costs, and the answer changed.
Under the updated standard:
- Entities must apply ASC 360-10 (Property, Plant, and Equipment) disclosure requirements to all capitalized internal-use software costs and related amortization, regardless of how those costs are presented in the financial statements.
- Entities need not provide intangible asset disclosures under ASC 350-30 (General Intangibles Other than Goodwill) for internal-use software costs.
This is a practical change for financial statement preparers. If your footnotes currently include ASC 350-30 intangible asset disclosures for capitalized software, you will need to migrate those disclosures to the ASC 360-10 PP&E framework upon adoption.
ASC 350-40 vs. ASC 985-20: The Key Difference
ASC 985-20 governs software developed for external sale, lease, or marketing, not internal use. The two standards have different capitalization thresholds and different points at which capitalization begins.
Under ASC 985-20, costs are expensed until "technological feasibility" is achieved, a higher bar that historically resulted in later capitalization and more costs hitting the income statement. Under the old ASC 350-40 three-stage model, capitalization began earlier (at the application development stage), resulting in more costs on the balance sheet.
ASU 2025-06 intentionally moves the two models closer together by introducing the significant development uncertainty concept, but, as Deloitte notes, "the ASU makes targeted improvements to ASC 350-40 but does not fully align the framework for accounting for internally developed software costs with ASC 985-20." Nuanced differences in capitalization thresholds remain.
For a side-by-side comparison of both standards, see ASC 350-40 vs ASC 985-20: Which Standard Governs Your Software Project?
ASU 2025-06 Effective Dates and Transition Methods
ASU 2025-06 is effective for public business entities for fiscal years beginning after December 15, 2025, meaning calendar-year-end public companies are already applying it as of January 1, 2026. Non-public entities have an additional year (fiscal years beginning after December 15, 2026), with early adoption permitted for all entities.
Three transition methods are available:
| Transition Method | How It Works | Key Consideration |
|---|---|---|
| Prospective | Apply new rules to all new costs incurred after adoption date, including in-process projects | Simplest operationally; no restatement |
| Modified prospective | Apply prospectively to new costs; derecognize capitalized costs for in-process projects that no longer qualify, via cumulative-effect adjustment to opening retained earnings | Risk of balance sheet write-down for projects that fail the new test |
| Retrospective | Recast comparative periods with cumulative-effect adjustment to opening retained earnings as of the beginning of the first period presented | Most complex; provides comparability |
The modified prospective method carries a specific risk: if you have in-process projects with capitalized costs that would not have met the new capitalization criteria (because significant development uncertainty existed at the time), those costs must be derecognized through retained earnings at adoption. Companies should assess their in-process project portfolio before selecting a transition method.
For a deeper dive into the transition mechanics, see ASC 350-40 Guide: Practitioner Walkthrough for 2026.
FAQ: ASC 350-40 Common Questions
What is the difference between ASC 350-40 and ASC 985-20? ASC 350-40 covers software developed for internal use or used to deliver services to customers. ASC 985-20 covers software developed for external sale, lease, or marketing. The scope determination is a threshold question, get it wrong and you apply the wrong capitalization model entirely.
Does ASC 350-40 still use the three project stages after ASU 2025-06? No. ASU 2025-06 eliminated all references to the preliminary project, application development, and post-implementation stages. The new framework uses a two-part test (management authorization plus probable-to-complete) with a significant development uncertainty gate.
What is an ASC 350-40 analysis? An ASC 350-40 analysis is the process of determining: (1) whether the standard applies to your software costs; (2) whether your arrangement contains a software license or is a service contract; (3) whether the capitalization conditions are met; and (4) which specific costs qualify for capitalization versus must be expensed. Under ASU 2025-06, it also requires assessing significant development uncertainty and defining the unit of account (the "project").
What is ASC 350-50 and does it still exist? ASC 350-50 previously governed website development costs. ASU 2025-06 absorbed that guidance into the ASC 350-40 framework. Website development costs are now analyzed under the same principles-based model as other internal-use software costs.
Can we capitalize AI tool costs (token-based LLM fees, AI agent subscriptions) under ASC 350-40? Possibly, but only if the costs are directly attributable to a specific qualifying software project, relate to a qualifying development activity, and are incurred during the capitalization window. The form of pricing (token-based vs. subscription) does not determine capitalizability, the substance of the activity and its attribution to a qualifying project does. Companies need project-level cost tracking for AI service consumption.
When does ASU 2025-06 take effect for non-public entities? For non-public entities, ASU 2025-06 is effective for fiscal years beginning after December 15, 2026, with early adoption permitted. Three transition methods are available: prospective, modified prospective, and retrospective.
