ASC 350-40 vs ASC 985-20: Which Standard Governs Your Software Project?

The wrong answer to this question can shift millions in costs from the income statement to the balance sheet, or vice versa. ASC 350-40 and ASC 985-20 are the two US GAAP frameworks for software development cost capitalization, and the choice between them is one of the most consequential, and most frequently misapplied, judgments a software company makes.

This article gives you the decision framework, the side-by-side mechanics, and the three analytical gaps that existing coverage misses: the precise scope test, the conceptual bridge ASU 2025-06 built between the two standards, and how AI development costs behave under each.

Key takeaway: The scope dividing line is not whether you sell the software. It is whether the customer can take possession of it and run it independently. That single test determines everything that follows.

What Is the Difference Between ASC 350-40 and ASC 985-20?

ASC 350-40 (Intangibles, Goodwill and Other, Internal-Use Software) governs software the entity runs itself, whether for its own operations or to deliver a cloud or SaaS service to customers. ASC 985-20 (Software, Costs of Software to Be Sold, Leased, or Marketed) governs software the customer takes possession of and runs on their own infrastructure.

As Deloitte puts it: "With ASC 985-20, the software runs on the customer's on-premise infrastructure (or the customer's cloud vendor's infrastructure). With ASC 350-40, it runs on the entity's own internal infrastructure (or the entity's cloud vendor's infrastructure) where it can be accessed online by subscribing customers as SaaS or cloud solutions or used internally by the entity."

The practical consequence is significant. ASC 985-20 gates capitalization on technological feasibility, a threshold that in practice sits close to general availability. ASC 350-40 has no feasibility gate and historically produces materially larger capitalized balances.

The Possession and Infrastructure Test: The Real Scope Dividing Line

The scope question is not about commercial intent. It is about possession and infrastructure control.

ASC 985-20 applies only when both of the following conditions are met:

1. The customer can contractually take possession of the software during the hosting period without a significant penalty.
2. The customer can feasibly run the software on their own hardware or with an unrelated third-party host.

Fail either condition and ASC 350-40 applies, because the software is effectively internal-use from the vendor's perspective. In practice, most SaaS arrangements fail both conditions, which is why SaaS platform development costs almost always fall under ASC 350-40.

Edge Cases That Trip Up Experienced Teams

Three scenarios create the most audit friction:

• White-label SaaS arrangements. The vendor hosts the software; the customer brands it. The customer cannot take possession or run it independently. ASC 350-40 applies to the vendor's development costs.
• Customer-controlled cloud instances (BYOC). A customer brings their own AWS or Azure account and the vendor deploys a containerized version into it. If the customer can run that container independently without significant penalty, the possession test may be met and ASC 985-20 could apply. This requires a careful contractual analysis.
• Hybrid vendors. A company ships both an on-premise enterprise edition and a cloud-hosted version of the same codebase. Both standards apply simultaneously. Development costs must be tracked separately under each standard, and shared costs require a defensible allocation methodology. This is not optional: BDO's Accounting for Software Costs Blueprint flags that "the guidance in ASC 350-40 that applies to software licensing arrangements differs in important respects from the guidance in ASC 350-40 that applies to CCAs" and that correctly identifying the applicable guidance is essential.

For the hybrid vendor scenario, the audit documentation requirement is a contractual analysis for each product line, an infrastructure control assessment, and a cost allocation schedule that maps shared engineering time to each standard. Reconstructing this after the fact is where most audit friction originates.

ASC 350-40 vs ASC 985-20: Side-by-Side Comparison

How Capitalization Works Under Each Standard

ASC 985-20: Technological Feasibility as the Gate

Under ASC 985-20, all costs incurred before technological feasibility is established are treated as research and development and expensed when incurred. Capitalization begins only after technological feasibility is established and stops once the product is available for general release.

The catch is timing. Deloitte notes that because technological feasibility is often established shortly before the software product reaches the general availability stage, many entities do not have material costs capitalized under ASC 985-20. In practice, for many software products, the capitalizable window between feasibility and GA is measured in weeks, not months.

ASC 985-20 does permit capitalization of programmer overhead and dedicated hardware costs once feasibility is reached, which is a meaningful difference from ASC 350-40.

ASC 350-40: The Probable-to-Complete Threshold (Post-ASU 2025-06)

Under the revised ASC 350-40, as amended by ASU 2025-06, capitalization begins when both of the following conditions are met, per ASC 350-40-25-12:

1. Management, with the relevant authority, implicitly or explicitly authorizes and commits funding for the software project.
2. It is probable the project will be completed and the software will be used to perform its intended function.

KPMG defines "probable" here as a likelihood greater than 75%, consistent with the ASC Master Glossary.

Importantly, ASU 2025-06 does not change what costs are capitalizable once the threshold is met. ASC 350-40-30-1 remains untouched: the update changes only when to start capitalizing, not what to capitalize.

For a full walkthrough of the pre- and post-ASU 2025-06 mechanics under ASC 350-40, see the ASC 350-40 practitioner guide.

The Overhead Capitalization Trap

This is the most common misapplication when teams switch between the two standards or apply the wrong one.

ASC 350-40 prohibits all overhead capitalization. PwC's Software Costs guide states explicitly: "In contrast to ASC 985-20, ASC 350-40-30-2 does not permit capitalization of any overhead costs."

ASC 985-20 permits overhead. Programmer overhead, benefits allocations, and dedicated hardware costs are capitalizable once technological feasibility is reached.

The practical error pattern: a team that has historically applied ASC 985-20 to on-premise product development acquires a SaaS product line. They continue capitalizing overhead on the SaaS development costs under ASC 350-40, which is incorrect. The audit adjustment can be material, particularly for engineering-heavy organizations where overhead rates run 30 to 50 percent of direct labor.

The ASU 2025-06 Bridge: How the Two Standards Are Converging

ASU 2025-06, issued September 18, 2025, is the first major update to the internal-use software guidance in over two decades. It does not touch ASC 985-20. But it introduces a concept that creates a formal analytical bridge between the two standards.

Significant Development Uncertainty: ASC 350-40's New Feasibility Analog

Even after management authorizes and commits funding, capitalization under the revised ASC 350-40 is blocked if significant development uncertainty exists. ASC 350-40-25-12A, as amended by ASU 2025-06, defines significant development uncertainty as existing when:

• "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.

This is conceptually analogous to ASC 985-20's technological feasibility gate. Both standards now require that novel technical risk be resolved through actual coding and testing before capitalization begins, not merely through planning or design decisions. KPMG's February 2026 handbook notes this alignment explicitly, describing how ASU 2025-06 "more closely aligns the accounting for development of software that will be licensed to customers and software that will be sold via the cloud."

The gap between the two standards narrows for novel software but remains wide for routine enhancements. A standard feature addition to a mature SaaS platform will likely have no significant development uncertainty and can capitalize quickly under ASC 350-40. The same addition to an on-premise product under ASC 985-20 still must wait for technological feasibility, which may not arrive until near GA.

Key takeaway: ASU 2025-06 does not make ASC 350-40 and ASC 985-20 identical. But for novel software, including AI, the practical capitalization start date under both standards now depends on resolving technical uncertainty through coding and testing rather than through management intent alone.

Effective Date and Transition

ASU 2025-06 is effective for annual periods beginning after December 15, 2027. Early adoption is permitted as of the issuance date (September 18, 2025). As of September 2026, most calendar-year companies are still operating under the pre-ASU three-stage model while planning their transition. A capitalization policy written today must describe both frameworks and state plainly which one is currently running.

For a detailed treatment of the transition mechanics, see the ASC 350-40 software capitalization guide before and after ASU 2025-06.

AI Software Development Costs Under Both Standards

Existing coverage addresses AI costs superficially. Here is the rigorous treatment.

The applicable standard for AI software depends on the same possession and infrastructure test. AI software sold as an on-premise license falls under ASC 985-20. AI software accessed via SaaS or used internally falls under ASC 350-40.

Training Data Costs

Training data costs are not a clean fit for either standard's existing cost categories. KPMG's February 2026 handbook specifically addresses AI data costs, noting that the rapid advancement of AI has created new practice issues not directly addressed by existing guidance. The general principle: training data costs incurred before the capitalization threshold is met (technological feasibility under ASC 985-20; probable-to-complete with no significant development uncertainty under ASC 350-40) are expensed. Training costs incurred after the threshold, and necessary to establish that the software can perform its intended function, may be capitalizable. The Deloitte Heads Up on ASU 2025-06 illustrates this with Entity Y, where model training costs incurred after September 30, 20X0 (the date significant development uncertainty was resolved through coding and testing) were capitalized.

LLM API Fees During Development

LLM API fees paid to a third-party provider during development are service contract costs, not capitalizable software development costs, unless they are directly attributable to bringing the software asset to its intended condition. In practice, API fees incurred during the uncertainty resolution phase are expensed. Fees incurred after the capitalization threshold is met, and directly tied to training or fine-tuning the model, require judgment about whether they are direct costs of the asset.

Middleware and Orchestration Layers

EisnerAmper's analysis provides the clearest framework: if the AI model and its supporting middleware go live at the same time, are updated together, and are retired together, the supporting software is most likely a direct cost of the AI model rather than a standalone asset. If the middleware has independent economic utility and its own revenue stream or customer rights, it is evaluated separately.

For ASC 985-20 scope AI software, supporting middleware must be evaluated for whether it is a separately identifiable product with its own technological feasibility. If not stand-alone, its costs are capitalized when the supported AI model reaches technological feasibility.

The Significant Development Uncertainty Constraint for AI

For AI software under ASC 350-40, the significant development uncertainty concept is particularly consequential. Novel AI functionality, including LLM-based features with unproven performance characteristics, will almost always trigger the uncertainty constraint. Capitalization cannot begin until AI specialists resolve the uncertainty through coding and testing, not through design documents or vendor assurances. The Entity Y example in the Deloitte Heads Up illustrates this: despite CEO funding approval in January, hiring AI specialists in February, and identifying performance requirements in June, capitalization did not begin until September, when the novel portions were resolved through actual coding and testing.

Key takeaway: For AI software, the significant development uncertainty concept under ASC 350-40 and the technological feasibility gate under ASC 985-20 both function as novelty filters. Neither standard lets you capitalize your way through genuine technical uncertainty.

The Cash Flow Statement Consequence

This is the implication that CFOs and lenders most frequently underestimate.

ASC 230-10-45-13(c) classifies capitalized software development spend as an investing cash outflow. When a company capitalizes $10 million in development costs under ASC 350-40 rather than expensing them, operating cash flow improves by $10 million without a single additional dollar of cash arriving. Any debt covenant, board metric, or investor presentation built on operating cash flow must be read alongside the capitalization policy.

Companies applying ASC 985-20, where capitalization is often minimal, will show lower operating cash flow and lower intangible assets than economically similar companies applying ASC 350-40 to SaaS development. This is a real comparability problem for analysts and lenders evaluating software companies across delivery models.

FASB's Single-Model Project: Strategic Horizon

FASB has added a project to potentially unify ASC 350-40 and ASC 985-20 into a single model. The Board reached a preliminary decision that the single model would likely be more similar to ASC 350-40 than ASC 985-20.

This is controversial. As Deloitte notes, "Having a single model that results in more capitalized costs is incredibly unpopular with many that want a dual model. Many would prefer to expense everything if the software is being sold, whether it's sold on-prem or as SaaS, while software costs are capitalized for those that are truly for internal use only, like ERP systems."

For CFOs and controllers, the strategic implication is this: companies currently capitalizing significantly more under ASC 350-40 than they would under ASC 985-20 should build their capitalization policies with both the current dual model and a potential unified future model in mind. A policy that documents the possession and infrastructure test rigorously, tracks costs at the project level, and applies the significant development uncertainty concept consistently will be defensible under either framework.

The single-model project remains in early stages and the outcome is not certain. But the direction of travel is toward more ASC 350-40 logic, not less.

Practical Policy Checklist

For each active software development project, the controller's documentation file should include:

1. Scope determination memo. A written analysis of the possession and infrastructure test, including contractual review of customer rights to take possession and feasibility of independent hosting.
2. Standard applied. ASC 985-20 or ASC 350-40, with rationale. For hybrid vendors, both, with a cost allocation methodology.
3. Capitalization start date. The date technological feasibility was reached (ASC 985-20) or the date the probable-to-complete threshold was met with no significant development uncertainty (ASC 350-40), with supporting evidence.
4. Significant development uncertainty assessment. For novel or AI-related software under ASC 350-40, documentation of when and how uncertainty was resolved through coding and testing.
5. Cost categories. A schedule distinguishing direct labor, overhead (capitalizable under ASC 985-20 only), and third-party costs, with time-tracking or sprint-level allocation records.
6. Unit-of-account determination. For software with distinct functionalities, a documented decision on whether they constitute one project or multiple projects, with reference to the View A / View B framework from the Deloitte Heads Up.
7. ASU 2025-06 transition status. Whether the entity has early adopted or is still operating under the legacy three-stage model, stated plainly.
8. Impairment monitoring trigger. The condition under which capitalization would stop and impairment would be assessed under ASC 350-40-35-1 through 35-3 (or net realizable value testing under ASC 985-20).

FAQ

Does ASC 350-40 or ASC 985-20 apply to our SaaS product development costs? Almost certainly ASC 350-40. SaaS customers typically cannot take possession of the software or run it independently, which means the possession test fails and the software is treated as internal-use from the vendor's perspective.

We sell both an on-premise license and a cloud-hosted version of the same software. Which standard applies? Both, simultaneously. The on-premise product falls under ASC 985-20; the cloud-hosted version falls under ASC 350-40. You must track development costs separately under each standard and document the allocation methodology.

What is technological feasibility under ASC 985-20 and when is it typically reached? Technological feasibility is established when the entity has completed all planning, designing, coding, and testing necessary to establish that the product can be produced to meet its design specifications. In practice, this is often reached shortly before general availability, meaning most pre-GA development costs are expensed under ASC 985-20.

How does ASU 2025-06 change ASC 350-40, and does it affect ASC 985-20? ASU 2025-06, issued September 18, 2025, replaces the three-stage model in ASC 350-40 with a probable-to-complete threshold and introduces the significant development uncertainty concept. It does not affect ASC 985-20 at all. It is effective for annual periods beginning after December 15, 2027, with early adoption permitted.

Can we capitalize overhead costs under ASC 350-40? No. ASC 350-40-30-2 explicitly prohibits overhead capitalization. ASC 985-20 permits programmer overhead and dedicated hardware costs once technological feasibility is reached. Applying ASC 985-20 overhead rules to an ASC 350-40 project is a common and material misapplication.

How do we account for AI training data costs? Training data costs incurred before the applicable capitalization threshold (technological feasibility under ASC 985-20; probable-to-complete with no significant development uncertainty under ASC 350-40) are expensed. Training costs incurred after the threshold, and directly necessary to establish that the software can perform its intended function, may be capitalizable. LLM API fees are generally service contract costs and are expensed unless directly attributable to bringing the asset to its intended condition after the threshold is met.