ASC 350-40 Capitalize vs. Expense Software Costs: A 2026 Practitioner Walkthrough

If your team is still sorting software costs into preliminary, application development, and post-implementation buckets, you're working from a model FASB replaced in September 2025. ASU 2025-06 scrapped the three-stage framework and replaced it with a principles-based test that demands more judgment and, FASB says, will push more costs to the income statement. This walkthrough tells you exactly how to apply the new rules, step by step, including the AI development scenarios and unit-of-account calls that trip up even experienced controllers.

Key takeaway: Under ASU 2025-06, capitalization under ASC 350-40 turns on two criteria plus a "significant development uncertainty" gate. Getting the sequence right matters: the gate can block capitalization even after management has signed off on funding.

For a full conceptual overview of what ASU 2025-06 changed and why, see our ASC 350-40 software capitalization 2026 guide. This article focuses on the how-to: the decision sequence, worked examples, and the documentation your auditors will expect.

What Costs Can Be Capitalized vs. Expensed Under ASC 350-40?

Under the new ASC 350-40 framework, a software cost is capitalizable only when two criteria are both met and no significant development uncertainty blocks the gate. Costs that fail any part of the test are expensed as incurred. Certain categories are always expensed regardless of where the project stands.

Always expensed, no exceptions:

• Training costs
• Data conversion costs (unless the conversion software itself is being developed, in which case that software's development costs follow the standard rules)
• General and administrative costs and overhead
• Post-deployment maintenance

Everything else runs through the two-part capitalization test below.

How to Apply the New Two-Part Capitalization Test

ASC 350-40-25-12, as amended by ASU 2025-06, sets two criteria that must both be satisfied before capitalization begins. Work through them in order.

Step 1: Management Authorization (ASC 350-40-25-12(b))

Management with the relevant authority must have implicitly or explicitly authorized and committed to funding the software project.

In practice, this means a documented decision: a signed project charter, an approved capital budget line, an executed vendor contract, or board minutes authorizing spend. Verbal approval from a project sponsor does not clear this bar. The authorization must come from someone with actual funding authority, not just technical leadership.

This criterion is usually the easier of the two to satisfy and to document. The harder gate is Step 2.

Step 2: Probable-to-Complete Threshold (ASC 350-40-25-12(c))

It must be probable that the project will be completed and the software will be used to perform the function intended.

Probable here carries its standard GAAP meaning: likely to occur. A project with a clear business case, committed resources, and no material technical obstacles generally clears this bar. But the standard adds a critical modifier: the probable-to-complete threshold is not met if significant development uncertainty exists.

Step 3: The Significant Development Uncertainty Gate (ASC 350-40-25-12A)

This is the new concept that changes outcomes most dramatically. Significant development uncertainty exists, and capitalization is therefore blocked, if either of the following conditions is present:

1. Novel technology condition: "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." (ASC 350-40-25-12A, per Deloitte Heads Up)

2. Undefined requirements condition: "The significant performance requirements of the software have not been identified, or the identified significant performance requirements continue to be substantially revised." (ASC 350-40-25-12A, per Deloitte Heads Up)

Note that "performance requirements" means what the entity needs the software to do, specifically its functions or features. This is consistent with how the term was used in the old preliminary project stage definition.

The key practical implication: management authorization (Step 1) can be complete, resources can be hired, and vendor contracts can be signed, and capitalization still cannot begin if significant development uncertainty remains unresolved. FASB expects more costs to be expensed under this framework than under the old stage model, precisely because this gate delays or prevents capitalization in more scenarios.

Old Three-Stage Model vs. New Principles-Based Framework: Side-by-Side

Most teams need to understand both models during the transition period. Here is the comparison that no ranking article currently provides in a single table.

For off-the-shelf (COTS) software from a reputable vendor with no novel features, the new framework generally produces a similar outcome to the old model: capitalization begins promptly once management authorizes and the probable-to-complete threshold is met, because neither significant development uncertainty condition is typically triggered. The real change hits custom and AI-driven development.

How to Apply the New Rules to AI and LLM Software Development

This is where the new framework bites hardest, and where most published guidance leaves practitioners without a concrete answer. Deloitte's Heads Up on ASU 2025-06 includes a detailed illustrative example (Entity Y) that is worth walking through carefully.

The scenario: Entity Y's CEO approves funding on January 15, 20X0 for a novel AI tool that will extract data from contracts and write accounting entries. Y hires AI specialists and signs a contract to access a third-party LLM. The tool uses unproven AI technology for the "write" functionality.

Here is how the capitalization assessment plays out across key dates, per Deloitte's analysis:

The result: despite CEO sign-off in January, capitalization does not begin until September 30, approximately 8.5 months later. All costs incurred between January and September 30 are expensed. This is a material difference from the old model, under which those costs would likely have been capitalized once the application development stage was deemed to have started.

Practical implication for AI projects: document the specific technical milestones that resolve novel technology uncertainty. "We finished the sprint" is not enough. You need evidence that coding and testing have resolved the specific unproven functions or features. Auditors will ask for this documentation.

The Unit-of-Account Question: What Is a "Software Project"?

This is the most consequential new judgment area in ASU 2025-06, and BDO flags it explicitly: "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."

The unit-of-account determination directly controls when capitalization begins, because the significant development uncertainty assessment is made at the project level.

The View A vs. View B analysis (from Deloitte's Entity Y example):

• View A (single project): The extract and write functionalities are funded together and assessed as one project. Because the write functionality has novel AI uncertainty, the entire project is blocked from capitalization until September 30, 20X0. The extract functionality's costs are also expensed during this period, even though extract alone has no significant uncertainty.

• View B (separate projects): Because Y can deliver the extract functionality independently of the write functionality, each is a separate software project. On January 15, 20X0, the extract project meets both criteria immediately (no novel uncertainty, requirements defined). Capitalization of extract-related costs begins on day one. The write project still waits until September 30, 20X0.

The financial statement difference between View A and View B is the entire cost of extract development from January through September. For a large AI initiative, that can be millions of dollars.

How to make the call in practice:

1. Ask whether each functionality or module can be placed in service independently and deliver standalone value.
2. If yes, treat as separate projects (View B). Document the business rationale.
3. If the components are interdependent and cannot function without each other, treat as a single project (View A).
4. Apply the significant development uncertainty assessment at the project level you have defined.
5. Keep the documentation. Auditors will scrutinize unit-of-account judgments closely under the new model.

Does ASU 2025-06 Apply to Cloud Computing and SaaS Implementation Costs?

Yes. This is a common source of confusion. ASU 2018-15 (now codified in ASC 350-40) already required entities to apply the internal-use software capitalization framework to implementation costs of cloud computing arrangements (CCAs) that are service contracts. ASU 2025-06 amends ASC 350-40 as a whole, so the new principles-based framework applies to CCA implementation costs as well.

If you are implementing a SaaS platform and incurring implementation costs, run those costs through the same two-part test and significant development uncertainty gate. The practical difference: most COTS SaaS implementations involve no novel technology, so the uncertainty gate is unlikely to block capitalization. But custom configurations, AI-enhanced integrations, or bespoke modules built on top of a SaaS platform may trigger the novel technology condition.

Choosing Your Transition Method: A Decision Framework

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 an annual reporting period. Three transition approaches are available, and the choice has real balance sheet and retained earnings consequences.

Practical guidance on which to choose:

• Choose prospective if your in-process capitalized software projects would pass the new two-part test. You avoid a retained earnings hit and the disclosure burden is minimal.
• Choose modified prospective if you have material in-process balances that would fail the significant development uncertainty gate under the new rules. You take the retained earnings charge at adoption but avoid restating prior periods.
• Choose retrospective if you are a public company with institutional investors who weight year-over-year comparability, or if you are preparing for a capital markets transaction where clean comparatives matter.
• Early adopt if you have significant AI or agile development programs and want to align your accounting policy now, before the mandatory effective date in 2028. Early adoption is permitted as of the beginning of any annual period.

Whichever method you choose, update your internal accounting policy, retrain your finance and engineering teams on the new recognition criteria, and revise your close-process controls to capture the documentation needed to support capitalization decisions at the project level.

Disclosure Changes: From ASC 350-30 to ASC 360-10

The disclosure shift is a practical change that many finance teams have not yet addressed. Under ASU 2025-06:

• Required: Apply ASC 360-10 (Property, Plant, and Equipment) disclosure requirements to all capitalized internal-use software costs and related amortization, regardless of where on the balance sheet the asset is presented.
• No longer required: ASC 350-30 intangible asset disclosures for internal-use software costs.

In practice, this means your footnote disclosures for capitalized software shift from the intangibles note to the PP&E note (or a combined note), with the gross carrying amount, accumulated amortization, and amortization expense presented consistently with how you disclose other long-lived assets. Review your disclosure templates now, before adoption, so you are not scrambling at the first reporting date.

ASC 350-40 vs. ASC 985-20: What Changes for Companies With Both?

ASU 2025-06 does not touch ASC 985-20, which governs software developed for external sale, lease, or marketing. Companies that develop both internal-use and external-use software still apply both standards separately.

The practical shift: the new ASC 350-40 framework introduces a significant development uncertainty concept that is conceptually similar to ASC 985-20's technological feasibility threshold. FASB expects this to produce more similar accounting outcomes across the two standards in many cases. But BDO cautions that "differences in capitalization thresholds might continue to exist between the two models because of certain nuanced differences in the guidance."

If your company straddles both standards, map each software project to the correct standard first, then apply the relevant capitalization test. Do not assume the outcomes will be identical just because the concepts have converged.

A Note on Section 174 and Book-Tax Differences

One point almost no GAAP-focused article addresses: the interaction between ASC 350-40 capitalization decisions and Section 174 of the Internal Revenue Code. Since 2022, Section 174 requires domestic R&D and software development costs to be capitalized and amortized over five years (15 years for foreign research) for federal tax purposes, regardless of GAAP treatment.

This means a cost you expense under the new ASC 350-40 framework may still need to be capitalized for tax purposes, creating a deferred tax asset. Conversely, a cost you capitalize for GAAP may have a different amortization period for tax. CFOs and tax teams need to track software cost decisions in both systems and ensure the book-tax difference is correctly reflected in the ASC 740 provision. Do not conflate GAAP capitalization policy with tax treatment: they are parallel but separate determinations.

FAQ

Should software costs be expensed or capitalized under ASC 350-40? It depends on whether both capitalization criteria are met and no significant development uncertainty exists. COTS implementations with clear requirements generally capitalize promptly. Novel AI or custom development often expenses costs until technical uncertainty is resolved through coding and testing.

When does capitalization begin under the new ASU 2025-06 rules? Capitalization begins on the date both criteria are first met: management authorization and probable-to-complete, with no significant development uncertainty present. For novel technology projects, this can be months after project initiation.

How do we document that significant development uncertainty has been resolved? Maintain records of specific coding and testing milestones that demonstrate the novel functions or features work as intended. Sprint retrospectives, test results, and technical sign-offs from engineering leadership are the types of evidence auditors will look for.

Does ASU 2025-06 change how we account for SaaS implementation costs? Yes, indirectly. The new principles-based framework in ASC 350-40 applies to cloud computing arrangement implementation costs (per ASU 2018-15). Most standard SaaS implementations are unaffected because they involve no novel technology, but custom AI-enhanced configurations may trigger the significant development uncertainty gate.

What is the mandatory effective date for ASU 2025-06? Annual reporting periods beginning after December 15, 2027, with early adoption permitted as of the beginning of any annual period.

How does the unit-of-account decision affect capitalization timing? Defining a broader project (View A) means one component's novel uncertainty blocks capitalization for all costs in the project. Splitting into separate projects (View B) allows the non-novel component to begin capitalizing immediately. The determination must be supportable based on whether each component can stand alone.