ASC 350-40 Explained: What It Is and How It Works (2026)

ASC 350-40 is the FASB standard that governs when companies capitalize versus expense the costs of developing or obtaining software for internal use. If your company builds its own ERP, trains an AI model, or implements a SaaS platform, this standard determines whether those costs hit your income statement immediately or sit on the balance sheet as an intangible asset. Getting it wrong has direct P&L and balance sheet consequences, and the SEC actively comments on companies' capitalization policies.

This article explains the standard from the ground up: what it covers, how the capitalization threshold works, what ASU 2025-06 changed, and where the hardest judgment calls live in 2026.

Key takeaway: ASU 2025-06, issued by FASB on September 18, 2025, is the most significant update to ASC 350-40 in roughly seven years. It removes the old project-stage model and replaces it with a principles-based capitalization threshold built around a new concept: "significant development uncertainty."

What Is ASC 350-40?

ASC 350-40, "Intangibles -- Goodwill and Other -- Internal-Use Software," is the section of the FASB Accounting Standards Codification that tells companies how to account for software they develop or obtain for their own operations. The "40" subtopic sits within Topic 350 (Intangibles -- Goodwill and Other), alongside ASC 350-20 (goodwill) and ASC 350-30 (general intangibles).

The standard applies to software that will not be sold, leased, or otherwise marketed to external parties. If software is intended for sale or license, ASC 985-20 governs instead. That distinction matters at the outset of every project, because the two standards have meaningfully different capitalization thresholds.

The core framework traces back to AICPA Statement of Position 98-1, issued in 1998, making the original model nearly 28 years old as of 2026. It predates cloud computing, agile development, and AI by decades, which is precisely why FASB modernized it with ASU 2025-06.

Why ASC 350-40 Exists

Before codified guidance, companies applied wildly inconsistent policies to software development costs. Some expensed everything; others capitalized aggressively. The resulting financial statements were difficult to compare and, in some cases, materially misleading.

ASC 350-40 exists to create a consistent, principled answer to one question: at what point in a software project does spending shift from speculative (expense it) to productive (capitalize it)? The answer has real stakes. Capitalizing costs that should be expensed overstates assets and inflates EBITDA. Expensing costs that should be capitalized understates the balance sheet and depresses earnings in the development period.

SEC staff have issued comment letters challenging companies' capitalization policies, useful-life estimates, and impairment assessments for internal-use software. This is a "Your Money or Your Life" topic: the accounting choice affects reported earnings, leverage ratios, and investor perception.

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

Before ASU 2025-06, ASC 350-40 organized software development into three sequential stages. Understanding this model still matters, because ASU 2025-06 is not yet mandatory for most companies (see effective dates below), and many in-process projects were accounted for under the old rules.

The boundary between Stage 1 and Stage 2 -- when capitalization begins -- was the most contested line in practice. The old model tied that boundary to the "project stages" concept, which mapped reasonably well onto waterfall development but broke down badly in agile environments where requirements evolve continuously and coding begins before requirements are fully defined.

For a detailed walkthrough of applying these rules to specific cost categories, see Finrep's ASC 350-40 practitioner how-to guide.

What ASU 2025-06 Changed: The New Capitalization Framework

ASU 2025-06, issued September 18, 2025, removes all references to project stages from ASC 350-40 and replaces them with a principles-based, two-part capitalization test. According to FASB's project page, the amendments are intended to make the guidance neutral to different development methodologies -- waterfall, agile, or anything that comes next.

Under the new framework, a company begins capitalizing internal-use software costs when both of the following conditions are met simultaneously:

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

The second condition is where the real work happens.

What "Probable-to-Complete" Actually Means

The probable-to-complete threshold is not met as long as significant development uncertainty exists. ASU 2025-06 adds a new paragraph, ASC 350-40-25-12A, that defines this concept explicitly for the first time. Significant development uncertainty exists if 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."

Both conditions are drawn directly from ASU 2025-06 as summarized by Deloitte's DART Heads Up. The first condition targets technological novelty -- the AI and LLM problem. The second targets requirements instability -- the agile problem.

This is a meaningful shift. Under the old model, a company could sometimes begin capitalizing once it entered the "application development stage" even if significant technical uncertainty remained. Under ASU 2025-06, novel technology uncertainty must be resolved through actual coding and testing before the clock starts.

Key takeaway: Management approval and budget commitment are necessary but not sufficient. Capitalization cannot begin until significant development uncertainty is resolved -- no matter how senior the sponsor or how large the budget.

The Off-the-Shelf Exception

One important simplification: when a company implements software developed by a reputable third party (a SaaS vendor, for example), the probable-to-complete threshold is generally considered met automatically. As Deloitte's Heads Up explains, this is because "it is probable that the project will be completed and the software will be used to perform the function intended since the software is an off-the-shelf solution developed by a reputable third party." The technology uncertainty is the vendor's problem, not yours.

This simplifies the analysis for cloud and SaaS implementations considerably, though the three-stage logic for which implementation costs are capitalizable still applies.

ASC 350-40 vs. ASC 985-20: The Core Distinction

The most fundamental scoping question in software accounting is which standard applies.

The distinction is not always obvious. A company building a software product it will deliver via SaaS -- where customers access it online but cannot take possession -- is generally considered to be using the software internally to provide a service. That means ASC 350-40, not ASC 985-20, governs the development costs.

For a side-by-side comparison of how these two standards produce different outcomes on the same facts, see Finrep's capitalize vs. expense walkthrough.

ASC 350-40 and Cloud / SaaS Implementation Costs

When a company is the customer in a cloud computing arrangement that is a service contract (not a software license), ASU 2018-15 amended ASC 350-40 to provide specific guidance. The customer applies the same capitalization logic to implementation costs -- but the resulting asset is a prepaid asset on the balance sheet, not an intangible, and the amortization period is tied to the service contract term rather than a standalone useful life.

This matters because many companies have large SaaS implementation projects (ERP migrations, CRM buildouts) where the implementation work is substantial. Under ASU 2018-15, costs incurred during the equivalent of the application development stage are capitalizable; costs during the equivalent of the preliminary project and post-implementation stages are not.

ASU 2025-06 does not repeal ASU 2018-15's framework, but the FASB noted in its Basis for Conclusions that it expects the amendments could result in a decrease in software capitalization for cloud computing arrangements, because the significant development uncertainty test now applies more rigorously.

ASC 350-40 and AI: The Hardest Questions in 2026

The most contested area of ASC 350-40 in 2026 is AI and machine learning development. The core difficulty: AI projects are inherently novel. An LLM-based feature is, almost by definition, "novel, unique, or unproven" until someone actually builds and tests it. That means the significant development uncertainty condition is almost always present at the start of an AI project, pushing all early-stage costs into expense.

When Are AI Training Costs Capitalizable?

ASU 2025-06 addresses this directly. Training costs for an AI model are capitalizable if they are incurred during the application development stage -- that is, after significant development uncertainty has been resolved -- and are necessary to establish that the software can perform its intended function.

Deloitte's worked example illustrates this precisely: Entity Y develops an AI-powered accounting tool with a "write" functionality built on a novel LLM approach. Once AI specialists resolve the development uncertainty through coding and testing (September 30, 20X0), Entity Y capitalizes costs including model training costs "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, when the functionality is substantially complete.

Training costs incurred before that threshold is met -- during the uncertainty-resolution phase -- are expensed.

The Unit-of-Account Question

One of the most consequential judgment calls under ASC 350-40 is how to define the "software project" when a development effort has multiple components with different risk profiles. This is the unit-of-account question, and it has a dramatic effect on capitalization timing.

Deloitte's Heads Up presents two views for a project with an "extract" function (proven technology) and a "write" function (novel LLM-based technology):

• View A (single unit of account): The entire project is one software project. Capitalization cannot begin until the uncertainty for the novel write functionality is resolved -- September 30, 20X0 in the example. Under this view, costs are capitalizable for only approximately 2.5 months of an 11-month development cycle.
• View B (separate units of account): Because the extract functionality can be delivered independently of the write functionality, each is a separate software project. The extract functionality has no significant development uncertainty, so capitalization begins on January 15, 20X0 (CEO approval date). Under this view, extract functionality costs are capitalizable for the full 11 months -- dramatically increasing the capitalized asset balance.

The difference between View A and View B is not cosmetic. On a multi-million-dollar development project, the unit-of-account choice can shift tens of millions of dollars between the income statement and the balance sheet. Companies need a documented, defensible policy -- and the SEC will ask about it.

For a step-by-step guide to applying these rules to specific projects, including the AI carve-out and transition decisions, see Finrep's software capitalization guide.

Effective Dates and Transition Options for ASU 2025-06

ASU 2025-06 is effective for all entities for annual reporting periods beginning after December 15, 2027, with early adoption permitted as of the beginning of any annual reporting period. That means a calendar-year-end company must adopt by January 1, 2028 at the latest, but can adopt as early as January 1, 2026.

Three transition approaches are available:

1. Prospective: Apply the new guidance to costs incurred after the adoption date for all projects, including in-process projects. No restatement of prior periods.
2. Modified prospective: Apply prospectively to new costs. For in-process projects that no longer meet the new capitalization requirements but had met the old ones, derecognize previously capitalized costs through a cumulative-effect adjustment to opening retained earnings.
3. Retrospective: Recast comparative periods and recognize a cumulative-effect adjustment to opening retained earnings as of the beginning of the first period presented.

The modified prospective approach is the most operationally complex. Under ASC 350-40-65-4(c)(1), a company applying this approach would cease capitalizing incremental development costs for projects that fail the new significant development uncertainty test -- even if those projects were being capitalized under the old stage-based model.

Early adoption is worth evaluating now. Companies with large AI development programs may find that the new framework better reflects the economics of their projects. Companies with aggressive capitalization policies under the old model may face write-downs on adoption.

ASC 350-40 vs. IFRS IAS 38

Companies with IFRS subsidiaries or dual reporting obligations face a persistent gap between ASC 350-40 and IAS 38 (Intangible Assets). As Deloitte's Heads Up notes, ASU 2025-06 "makes targeted improvements to ASC 350-40 but does not fully align the framework for accounting for internally developed software costs" with IFRS.

The key structural difference: IAS 38 uses a research-phase / development-phase model. Costs in the research phase are always expensed. Costs in the development phase are capitalized once six specific criteria are met -- including technical feasibility, intention to complete, and ability to use or sell the asset. IAS 38's development-phase criteria can, in some circumstances, allow earlier capitalization than ASC 350-40's significant development uncertainty test.

The practical result: a company building the same AI tool under US GAAP and IFRS may reach different capitalization conclusions on identical facts. This divergence is a known gap that FASB chose not to close in ASU 2025-06.

What Is ASC 350-30?

ASC 350-30 is a separate subtopic -- "Intangibles -- Goodwill and Other -- General Intangibles Other than Goodwill" -- that covers the recognition and measurement of intangible assets acquired in transactions other than business combinations. It is not the software standard. ASC 350-40 is the software-specific subtopic.

One practical note from ASU 2025-06: companies are no longer required to provide the intangible asset disclosures under ASC 350-30 for internal-use software costs. Instead, the property, plant and equipment disclosure requirements under ASC 360-10 apply to all capitalized internal-use software costs, regardless of how those costs are presented in the financial statements.

FAQ

When did ASC 350-40 come out?

The core framework traces to AICPA SOP 98-1, issued in 1998, and was codified into ASC 350-40 when FASB launched the Accounting Standards Codification in 2009. The most recent major amendments are ASU 2018-15 (cloud computing implementation costs) and ASU 2025-06 (targeted improvements for AI and modern development methods), issued September 18, 2025.

What is the difference between ASC 350-40 and ASC 985-20?

ASC 350-40 covers software developed or obtained for internal use (including SaaS platforms a company uses to deliver services). ASC 985-20 covers software developed for sale, lease, or external marketing. The capitalization triggers differ: ASC 350-40 uses the probable-to-complete threshold (with significant development uncertainty as the gating concept); ASC 985-20 uses technological feasibility. ASU 2025-06 did not change ASC 985-20.

What are the GAAP rules for capitalizing software development costs?

Under ASC 350-40 as amended by ASU 2025-06, a company capitalizes internal-use software costs when two conditions are met simultaneously: (1) management has authorized and committed to funding the project, and (2) it is probable the project will be completed and the software will be used as intended. The second condition requires that significant development uncertainty -- defined in ASC 350-40-25-12A -- has been resolved through coding and testing.

What is ASC 350-30?

ASC 350-30 covers general intangible assets other than goodwill -- assets like customer lists, trade names, and non-compete agreements acquired outside of business combinations. It is a separate subtopic from ASC 350-40 (internal-use software) and ASC 350-20 (goodwill). ASU 2025-06 explicitly exempts internal-use software from ASC 350-30's disclosure requirements.

Does ASC 350-40 apply to AI and LLM development costs?

Yes. ASU 2025-06 was specifically designed to address AI and machine learning development. The significant development uncertainty concept in ASC 350-40-25-12A directly targets novel, unproven technology. AI model training costs incurred after the capitalization threshold is met -- and necessary to establish that the software can perform its intended function -- are capitalizable. Training costs incurred before that threshold is met are expensed.

When is ASU 2025-06 mandatory?

ASU 2025-06 is effective for all entities for annual reporting periods beginning after December 15, 2027 (calendar-year companies: January 1, 2028). Early adoption is permitted as of the beginning of any annual reporting period. Three transition approaches are available: prospective, modified prospective, and retrospective.