ASC 350-40 vs ASC 985-20 vs ASC 350-20: 2026 Comparison Guide

Three subtopics. One shared topic number. Endless confusion at the close. If your team is trying to figure out which FASB standard governs a software project, this guide gives you the decision framework, the key differences, and the one fact that most articles skip entirely.

Key takeaway: ASC 350-20 has nothing to do with software. It governs goodwill from business combinations. The real comparison is ASC 350-40 (internal-use and SaaS) versus ASC 985-20 (on-premise software sold to customers), and that distinction has direct, material consequences for EBITDA, EPS, and your balance sheet.

First: What Is ASC 350-20, and Why Does It Keep Appearing in This Search?

ASC 350-20 governs goodwill arising from business combinations. It sits inside FASB Topic 350 (Intangibles, Goodwill and Other) alongside ASC 350-40, which is why the two subtopic numbers appear together in search queries. They share a topic but have no substantive relationship.

If your question is about a software acquisition, the relevant standard is not ASC 350-20. Purchased software that is not part of a business combination is typically accounted for under ASC 350-40. Software acquired as part of a business combination falls under ASC 805, with the resulting intangible asset then subject to ASC 350-40 for subsequent measurement. ASC 350-20 governs the residual goodwill, not the identified software intangible.

Set ASC 350-20 aside. The rest of this article is about the two standards that actually govern software development costs.

The Core Question: ASC 350-40 vs ASC 985-20

The single most important question is infrastructure: whose servers does the software run on?

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

That single sentence resolves most scoping questions. But the practical test is more precise.

The Two-Question Scope Test

Under ASC 985-20, software development costs fall within its scope only if both of the following are true:

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

If either answer is no, ASC 350-40 applies. In practice, most SaaS arrangements fail both conditions, which is why Crowe notes that "the determination of which capitalization model to use is not always obvious" even though the underlying logic is straightforward.

The Counterintuitive Result for SaaS Sellers

Here is the fact that trips up more controllers than any other: a SaaS company selling software subscriptions uses ASC 350-40, not ASC 985-20. The software runs on the SaaS provider's own infrastructure. Customers access it online but cannot take possession of it. That means the software is, in accounting terms, internal-use, regardless of the fact that it generates external revenue.

This is not a gray area. It is settled practice confirmed by Crowe, Deloitte, and RSM. The scope call is contractual, not commercial.

Decision Framework: Which Standard Applies?

Work through these questions in order:

1. Is the question about goodwill from an acquisition? Yes: ASC 350-20. Stop here.
2. Is the software sold, leased, or marketed externally, and does the customer run it on their own infrastructure? Yes to both: ASC 985-20.
3. Can the customer take possession without significant penalty AND feasibly host it independently? Yes to both: ASC 985-20.
4. Everything else (internal tools, SaaS products, cloud-hosted software, ERP systems, CCA implementation costs): ASC 350-40.

ASC 350-40 is the default. ASC 985-20 is the exception, and a narrow one.

Key Differences: ASC 350-40 vs ASC 985-20

The choice of standard is not academic. The two models prescribe materially different accounting treatment across every dimension that matters to a CFO.

Why the Capitalisation Trigger Gap Is So Large

Under ASC 985-20, technological feasibility is defined at ASC 985-20-25-2 as the point 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 threshold is met only when a working model or completed detail program design exists, which is typically just before general availability. The result: Deloitte confirms that "many entities do not have material costs capitalized" under ASC 985-20.

Under ASC 350-40, there is no feasibility gate. Capitalisation begins earlier, and the resulting balance sheet intangible is materially larger. The same dollar of engineering spend can be expensed immediately under ASC 985-20 or capitalised over several years under ASC 350-40, depending solely on which standard applies. That difference flows directly into EBITDA, EPS, and operating cash flow (capitalised spend is an investing outflow under ASC 230).

For a deeper walkthrough of the ASC 350-40 capitalisation mechanics, see ASC 350-40 Development Stage Capitalization: 2026 Practitioner Walkthrough.

What ASU 2025-06 Changed, and What It Did Not

In September 2025, FASB issued ASU 2025-06, the first major overhaul of ASC 350-40 in over 25 years (the original guidance dates to SOP 98-1 in 1998). As KPMG's February 2026 Software and Website Costs Handbook describes it, the amendments "better align the rules with modern agile software development practices and more closely align the accounting for development of software that will be licensed to customers and software that will be sold via the cloud."

ASU 2025-06 is effective immediately upon issuance. Calendar-year 2025 and 2026 filers must assess its impact now.

What Changed Under ASC 350-40

The three-stage model (preliminary project, application development, post-implementation) is gone. ASU 2025-06 replaces it with two affirmative criteria that must both be met before capitalisation begins:

• Management, with the relevant authority, implicitly or explicitly authorises and commits to funding the project.
• It is probable the project will be completed and the software will be used to perform the function intended (the probable-to-complete threshold), and significant development uncertainty has been resolved.

The "significant development uncertainty" concept is the substantive new gate. It exists when either the software has technological innovations or novel, unproven functions whose uncertainty has not been resolved through coding and testing, or the significant performance requirements have not been identified or continue to be substantially revised.

For software built on proven technology with well-defined requirements, the new model may not shift the capitalisation start date much. For AI-powered software built on large language models, the new model will delay capitalisation significantly. FASB explicitly expects more costs to be expensed under the revised guidance.

What ASU 2025-06 Did NOT Change

• ASC 985-20 is untouched. The technological feasibility test remains exactly as it was.
• The list of capitalizable cost categories under ASC 350-40-30-1 is unchanged.
• The post-implementation stage treatment (expense as incurred) is unchanged.
• The amortisation and impairment mechanics under ASC 350-40 are unchanged.

For the full ASU 2025-06 analysis, see the 2026 Practitioner's Guide to ASU 2025-06 and ASC 350-40.

Amortisation and Impairment: The Difference Nobody Mentions

This gap is missing from every top-ranking article on this topic, and it has real P&L consequences.

Under ASC 985-20, capitalised software costs are amortised using the greater of:

• The ratio of current period revenues to total expected revenues from the product, or
• The straight-line method over the remaining estimated economic life.

This revenue-ratio method front-loads amortisation when a product launches strongly, which can create a mismatch between the amortisation charge and the period in which the economic benefit is consumed.

Under ASC 350-40, amortisation is straight-line over the software's estimated useful life. No revenue-ratio method. The charge is predictable and period-consistent.

For impairment, ASC 985-20 applies a net realisable value test: the unamortised cost cannot exceed the net realisable value of the product. ASC 350-40 applies its own impairment model, which assesses whether the carrying amount will be recovered through use.

The practical implication: a company that misclassifies a SaaS product as ASC 985-20 scope will not only capitalise less, it will amortise what it does capitalise on a different schedule. Both the asset balance and the amortisation pattern will be wrong.

AI and Generative AI Development Costs: An Open Question

Generative AI software development costs, including training data acquisition, model fine-tuning, and AI-specific infrastructure, do not fit cleanly into either standard's existing framework. KPMG's February 2026 handbook specifically addresses AI data costs as a new accounting question, but no FASB primary guidance has been issued specifically for AI development costs.

The working framework in 2026:

• Scope first: Apply the two-question test. If the AI product runs on the entity's infrastructure and customers cannot take possession, ASC 350-40 applies.
• Capitalisation gate: Under post-ASU 2025-06 ASC 350-40, the significant development uncertainty concept will typically delay capitalisation for novel LLM-based features until the underlying technological uncertainty is resolved through coding and testing.
• Training data costs: No explicit guidance exists. The most defensible position is to treat data acquisition costs as a separate question from software development costs, applying analogous reasoning from ASC 350-40 where the data is integral to the software's function.
• ASC 985-20 AI products: If an AI product is sold as on-premise software where customers can take possession, ASC 985-20 applies, and the technological feasibility bar is even higher for novel AI capabilities.

This is an area where auditor alignment before the period begins is essential, not after.

The FASB's Single-Model Project: What to Watch

FASB has added a project to its agenda to move toward a single software cost accounting model, likely anchored in ASC 350-40 logic rather than ASC 985-20. The Board's reasoning, as Deloitte reports: "with a dual-model approach, it would be difficult to determine which types of software projects should be expensed versus capitalized, and using a single model is preferable."

The proposal is not without controversy. 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."

No final standard has been issued. But the direction of travel is clear: the dual-model framework is under pressure, and ASC 985-20 as a standalone standard may eventually be absorbed or deprecated.

What to do now:

• Document your current ASC 985-20 vs ASC 350-40 policy decisions with specificity, including the contractual analysis supporting each scope conclusion.
• Monitor FASB's project page. A single-model transition would require policy changes and potentially restatement for companies currently using ASC 985-20.
• If you are currently using ASC 985-20 and expensing most development costs, a single-model world anchored in ASC 350-40 would increase your capitalised balances and change your amortisation profile.

Cloud Computing Arrangement Implementation Costs

One more scoping question that generates confusion: what about the costs of implementing a SaaS product you purchase (not develop)? For example, configuration, customisation, and integration costs for a third-party ERP or CRM subscription.

These costs are also governed by ASC 350-40, under ASU 2018-15, which aligned the accounting for cloud computing arrangement implementation costs with the internal-use software framework. The same stage-based (now threshold-based under ASU 2025-06) logic applies: costs in the preliminary phase are expensed, costs in the application development phase are capitalised, and post-implementation costs are expensed.

This is distinct from the entity developing its own SaaS product to sell. For a detailed walkthrough of CCA accounting, see ASC 350-40 Hosting Arrangement: 2026 Practitioner Walkthrough.

FAQ

What is the difference between ASC 350 and ASC 985? ASC 350 is a broad FASB topic covering intangibles and goodwill. The relevant subtopics for software are ASC 350-40 (internal-use software, including SaaS products the entity hosts) and ASC 350-20 (goodwill, unrelated to software development). ASC 985-20 governs software sold or licensed externally where the customer runs it on their own infrastructure. The core difference is whose infrastructure the software runs on and whether the customer can take possession.

What is ASC 350-40? ASC 350-40 is FASB's standard for internal-use software development costs. It applies to software an entity develops for its own operations and to SaaS or cloud products the entity hosts for customers. ASU 2025-06, effective September 2025, replaced the old three-stage model with a probable-to-complete threshold and a significant development uncertainty test.

What is ASC 350-20? ASC 350-20 governs goodwill arising from business combinations. It has no direct relationship to software development cost accounting. Searchers who include it in software-related queries are typically confused by the shared Topic 350 number.

Does our SaaS product fall under ASC 985-20 or ASC 350-40? Almost certainly ASC 350-40. Unless your customers can take possession of the software without significant penalty and feasibly run it on their own infrastructure, ASC 985-20 does not apply. Most SaaS arrangements fail both conditions.

How does the technological feasibility test work under ASC 985-20? Under ASC 985-20-25-2, technological feasibility is achieved when all planning, designing, coding, and testing necessary to establish that the product can be produced to meet its design specifications is complete. In practice, this is typically just before general availability, meaning most development costs are expensed and material capitalised balances are rare.

What changed with ASU 2025-06? ASU 2025-06 removed the three-stage model from ASC 350-40 and replaced it with a two-part test: management commitment plus a probable-to-complete threshold that requires significant development uncertainty to be resolved before capitalisation begins. It is effective immediately upon issuance in September 2025. ASC 985-20 was not changed.