ASC 350-40 Software Capitalization: The 2026 Practitioner's Guide (Including ASU 2025-06)

If your company capitalizes internal-use software costs, the rules changed on January 1, 2026. FASB's ASU 2025-06 replaced the old three-stage model with a principles-based "probable-to-complete" threshold, added explicit guidance for AI and LLM-based development, and introduced new disclosure requirements. Public business entities must apply the new rules for fiscal years beginning after December 15, 2025, meaning calendar-year 2026 annual and interim periods. Many teams are still running on pre-ASU 2025-06 policies. That is an audit risk.

This guide walks through what changed, when capitalization starts under the new rules, how to handle AI model training costs, how to determine the unit of account for multi-function projects, and what your 2026 annual report must now disclose.

Key takeaway: The old preliminary-project-stage/application-development-stage bright line is gone. For calendar-year 2026 public companies, ASC 350-40 now turns on a judgment-based "probable-to-complete" threshold that can delay capitalization by months for novel or AI-driven software, and requires new note disclosures.

What Is ASC 350-40 Software Capitalization?

ASC 350-40 is the FASB standard that governs when and how companies capitalize costs to develop or obtain internal-use software under US GAAP. It covers everything from custom-built enterprise systems to cloud computing arrangement (CCA) implementation costs to AI-powered tools built on third-party LLMs. Getting it wrong means restatements, SEC comment letters, and audit adjustments.

ASC 350-40 applies when software is developed or obtained for the company's own internal operations or to deliver a service to customers (such as a SaaS platform the company hosts). It does not apply to software developed for external sale or licensing to customers as a standalone product; that falls under ASC 985-20, which uses a different "technological feasibility" threshold and was not changed by ASU 2025-06.

What Changed With ASU 2025-06 and When Does It Take Effect?

FASB issued ASU 2025-06 in June 2025, the most significant amendment to ASC 350-40 since SOP 98-1 was codified. The core problem it solves: the old waterfall-style three-stage model (preliminary project, application development, post-implementation/operation) does not map onto agile or AI-driven development, where there is no clean handoff between "deciding to build" and "building."

The key changes at a glance:

Early adoption is permitted for all entities. ASC 985-20 (external-use software) is unchanged.

When Does Capitalization Start Under the New Probable-to-Complete Threshold?

Capitalization begins when ALL of the following criteria in ASC 350-40-25-12 are met simultaneously. Two conditions must be present, and two blocking conditions must be absent.

Conditions that must be present:

1. Management with relevant authority has implicitly or explicitly authorized and committed to funding the project.
2. It is probable the project will be completed and the software will be used as intended (the "probable-to-complete recognition threshold").

Conditions that block capitalization (ASC 350-40-25-12A) -- capitalization cannot begin while either of these exists:

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

The practical implication is significant. Under prior GAAP, management authorization alone could trigger capitalization. Under ASU 2025-06, authorization is necessary but not sufficient. If the software has novel or unproven features, costs must be expensed until AI specialists, engineers, or developers resolve that uncertainty through actual coding and testing, not just planning or design work.

The good news for straightforward implementations: For off-the-shelf software from a reputable third-party provider, the Deloitte Heads Up analysis confirms the new threshold is met immediately upon management authorization, because there is no significant development uncertainty. The new rules are not universally more restrictive; they are more judgment-intensive.

How to Handle AI Model Training Costs Under ASC 350-40

AI model training costs are capitalizable under ASC 350-40 once the probable-to-complete threshold is met. FASB's own illustrative example in ASU 2025-06 makes this explicit.

The example involves Entity Y, which builds an AI-based accounting tool with two functionalities:

• An extract function using established technology (reads data from documents)
• A write function using a novel LLM-based approach (generates accounting outputs)

Here is how the capitalization timeline plays out for the write functionality under the FASB example, as analyzed in the Deloitte Heads Up:

The delay from funding approval to capitalization start is approximately 8.5 months. Every dollar of developer time, LLM API fees, and model training costs incurred before September 30 must be expensed.

As FASB states in the illustrative example: "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."

What this means for your AI projects:

• LLM fine-tuning costs: capitalizable once the threshold is met
• Third-party LLM API access fees (e.g., OpenAI, Anthropic service contracts) incurred during development: capitalizable once the threshold is met, because they are directly attributable to developing the software
• Data labeling and preparation costs: apply the same threshold test; capitalize only after development uncertainty is resolved
• Prompt engineering costs for novel, unproven functionality: expense until uncertainty is resolved through coding and testing
• User training costs (teaching employees to use the finished tool): always expensed, unchanged from prior GAAP

Unit of Account: Single Project or Separate Projects?

The unit-of-account determination is one of the most consequential judgment calls under ASU 2025-06, and it directly affects how much gets capitalized and when.

Using the same Entity Y example, FASB illustrates two views:

View A (single unit of account): The extract and write functionalities are funded as one project and assessed together. Because the write function has significant development uncertainty, capitalization for the entire project is delayed until September 30, 20X0. Under this view, only approximately 2.5 months of costs (October through mid-December) are capitalized out of an 11-month development cycle.

View B (separate units of account): Because Entity Y can deliver the extract functionality even if the write functionality is never completed, each represents a separate software project. The extract project begins capitalizing costs immediately on January 15, 20X0 (established technology, no significant development uncertainty). The write project still waits until September 30, 20X0. Under View B, the extract project captures nearly a full year of capitalizable costs.

As FASB states: "Because Y can provide the extract functionality even if the write functionality is not developed, each functionality represents a separate software project."

The practical test for your projects:

• Can the functionality be delivered to users independently of the uncertain component? If yes, it may qualify as a separate unit of account.
• Is the uncertain component a prerequisite for the rest of the software to function at all? If yes, a single unit of account is more appropriate.

Document this judgment explicitly. Auditors will ask.

ASC 350-40 and Cloud Computing Arrangements (SaaS Implementations)

ASC 350-40 also governs the capitalization of implementation costs for cloud computing arrangements (CCAs) that are service contracts, meaning arrangements where the customer does not hold a software license. This covers the vast majority of SaaS implementations.

Under PwC's Viewpoint guidance, implementation costs for CCAs are capitalized using the same framework as internal-use software, and the capitalized amounts are amortized over the term of the hosting arrangement (not a separate useful life). ASU 2025-06 applies the same probable-to-complete threshold to CCA implementation costs. FASB noted in the ASU's Basis for Conclusions that for CCA software development, the amendments could result in a decrease in capitalization relative to prior practice, because the novel-feature blocking condition will apply to custom development work done on top of a SaaS platform.

For a standard SaaS implementation with no custom development (configuring Workday, for example), the threshold is likely met at authorization. For a heavily customized implementation involving novel AI-powered modules, the blocking conditions apply.

ASC 350-40 vs. ASC 985-20: Which Standard Applies?

The threshold question is whether the software is for internal use or for external sale. The answer determines which standard governs and significantly affects how much gets capitalized.

The practical test from Crowe's analysis: if the customer can take possession of the software and operate it independently (or contract with a third party to host it) without significant penalty, ASC 985-20 likely applies. If the software is hosted by the vendor and the customer accesses it as a service, ASC 350-40 applies.

Companies that develop software primarily for internal use but also license it to customers must make this determination carefully for each product. Getting it wrong in either direction creates restatement risk.

New Disclosure Requirements Under ASU 2025-06

Starting with fiscal year 2026 annual reports, public companies must apply the ASC 360-10 property, plant, and equipment disclosure requirements to all capitalized internal-use software costs, regardless of how those costs are presented on the balance sheet.

This is an expansion over prior GAAP. Under the new rules, your notes must include:

• The nature of capitalized internal-use software
• Gross carrying amounts and accumulated amortization
• Amortization expense for the period
• Estimated amortization expense for each of the five succeeding fiscal years
• Remaining useful lives

Companies do not need to provide the general intangible asset disclosures under ASC 350-30 for internal-use software costs. The ASC 360-10 disclosures replace those.

If your 2026 annual report does not include these disclosures, expect a comment letter.

How to Transition to ASU 2025-06: Three Options

ASU 2025-06 offers three transition methods, each with different P&L implications. This is a live decision for calendar-year 2026 adopters.

1. Prospective approach (ASC 350-40-65-4(c)(1)): Apply the new rules to costs incurred after the adoption date for all projects, including in-process projects. No restatement of prior periods. Operationally straightforward, but in-process projects that no longer meet the new criteria will see a step-down in capitalized amounts going forward.

2. Modified prospective approach: Apply the new rules prospectively to new costs. For in-process projects that met the old criteria but fail the new probable-to-complete threshold, derecognize previously capitalized costs through a cumulative-effect adjustment to opening retained earnings at adoption. This approach requires identifying which in-process projects no longer qualify.

3. Retrospective approach: Recast comparative periods and recognize a cumulative-effect adjustment to opening retained earnings at the beginning of the first period presented. Most operationally complex, but provides the most comparable financial statements.

For each method, ASC 250-10-50-1(a) requires disclosure of the nature and reason for the change in accounting principle in the period of adoption.

Model the P&L impact of each method before deciding. The modified prospective approach can produce a one-time retained earnings hit that the prospective approach avoids, but the prospective approach may produce a multi-quarter step-down in capitalized amounts as old projects run off.

Capitalization Decision Checklist for ASC 350-40 (Post-ASU 2025-06)

Use this checklist for each software project or functionality assessed under the new rules:

Step 1: Determine the applicable standard

• Is the software for internal use or to deliver a service? (ASC 350-40)
• Is the software to be sold, leased, or marketed externally? (ASC 985-20)

Step 2: Define the unit of account

• Can each functionality be delivered independently to users?
• If yes, assess each as a separate software project
• If no, assess as a single project (most restrictive uncertain component governs)

Step 3: Apply the ASC 350-40-25-12 capitalization criteria

• Has management with relevant authority authorized and committed funding?
• Is it probable the project will be completed and used as intended?
• Does the software have novel, unique, or unproven functions or features?
  • If yes: has development uncertainty been resolved through coding and testing? (If not, stop -- expense costs)
• Have significant performance requirements been identified and are they stable?
  • If no or substantially changing: stop -- expense costs

Step 4: Document the threshold determination

• Record the date all criteria are met (this is the capitalization start date)
• Document what evidence resolves the development uncertainty (test results, working prototypes, specialist sign-off)
• Identify which costs are directly attributable to development (developer time, LLM API fees, model training)

Step 5: Post-implementation costs

• User training: expense as incurred
• Bug fixes that do not add new functionality: expense as incurred
• Maintenance: expense as incurred
• New features that meet the threshold: capitalize

Step 6: Disclosures

• Apply ASC 360-10 PP&E disclosures to all capitalized software
• Disclose transition method and cumulative effect (if applicable)

FAQ

Can software costs be capitalized under GAAP? Yes. Under ASC 350-40, internal-use software development costs are capitalizable once the probable-to-complete threshold is met and no significant development uncertainty exists. Costs incurred before that threshold must be expensed. Post-implementation costs (user training, maintenance, bug fixes) are always expensed.

How long does it take to amortize capitalized software? ASC 350-40 does not specify a fixed amortization period. Companies amortize capitalized software over its estimated useful life on a straight-line basis (or another systematic method), beginning when the software is ready for its intended use. Useful lives typically range from 3 to 7 years in practice, though this depends on the nature of the software and expected obsolescence.

Is software training capitalized or expensed? User training costs are always expensed as incurred under ASC 350-40, both before and after ASU 2025-06. This is unchanged. The only "training" that may be capitalizable is AI model training that is necessary to establish that the software can perform its intended function, and only after the probable-to-complete threshold is met.

Does ASU 2025-06 change the rules for cloud computing arrangement implementation costs? Yes, the same probable-to-complete threshold now applies to CCA implementation costs. For standard SaaS implementations with no novel custom development, the practical impact is limited. For AI-enhanced or heavily customized SaaS implementations, the new blocking conditions may delay capitalization relative to prior practice.

What is the difference between ASC 350-40 and ASC 985-20? ASC 350-40 governs internal-use software and uses the new probable-to-complete threshold. ASC 985-20 governs software developed for external sale or licensing and uses a "technological feasibility" threshold (generally a higher bar). ASU 2025-06 did not change ASC 985-20. Companies that develop software for both internal use and external sale must determine which standard applies to each product.

Should we early-adopt ASU 2025-06? For non-public entities, the mandatory effective date is fiscal years beginning after December 15, 2026, so early adoption is optional until then. For public companies, the rules are already mandatory for calendar-year 2026. If your company has significant AI or novel software development, early adoption gives you more time to build the documentation infrastructure the new rules require. See also our related coverage of SAB 74 disclosure requirements for ASU 2025-06.

How do auditors approach software capitalization under the new rules? Software capitalization is already a high-risk area for SEC comment letters and audit adjustments, particularly for technology companies that capitalize large percentages of developer salaries. Under ASU 2025-06, auditors will focus on: (a) the date the company determined development uncertainty was resolved and what evidence supports it; (b) the unit-of-account determination for multi-function projects; and (c) whether the new ASC 360-10 disclosures are complete. The requirement to resolve uncertainty "through coding and testing" creates a higher evidentiary bar but also a clearer audit trail if documented contemporaneously.