ASC 350-40 Software Capitalization Guide: Before and After ASU 2025-06
If your team is still debating which sprint activities belong to the "preliminary project stage," this guide is for you. ASC 350-40 governs how US GAAP companies capitalize internal-use software development costs, and the rules are changing in a fundamental way. FASB issued ASU 2025-06 in September 2025, replacing the nearly 27-year-old three-stage model with a principles-based framework that works for agile, waterfall, and whatever comes next.
This guide covers both the current (pre-ASU) rules and the new model side by side, so your team can operate correctly today and plan the transition with confidence.
What Does ASC 350-40 Cover and Who Does It Apply To?
ASC 350-40 applies to any entity that develops or obtains software for its own internal operations or to provide services to customers. That scope is broader than most practitioners assume. It covers the ERP your finance team uses, the customer portal your SaaS company hosts, and the AI tool your data science team is building to automate contract review.
Two other subtopics sit alongside it:
- ASC 985-20: Governs software developed to be sold, leased, or marketed externally. ASU 2025-06 does not change this standard.
- ASC 350-50: Covered website development costs. ASU 2025-06 absorbs this guidance into the revised ASC 350-40 framework.
For SaaS providers, the scope question is frequently misread. As PwC's November 2025 Software Costs guide notes, ASC 350-40 applies to a customer's accounting for implementation, setup, and other upfront costs in a cloud computing arrangement that is a service contract. If you host the software and sell access to it, ASC 350-40 applies to your development costs, not ASC 985-20.
The Three-Stage Model Under Current ASC 350-40 (Pre-ASU 2025-06)
Under the current rules, capitalization treatment depends entirely on which of three project stages a cost falls into. This framework was codified from SOP 98-1 in 1998 and reflects how software was built then: sequentially, in a waterfall.
| Stage | Activities | Capitalization Treatment |
|---|---|---|
| Preliminary project stage | Feasibility assessment, vendor evaluation, high-level requirements | All costs expensed |
| Application development stage | Coding, testing, installation, data conversion | Costs capitalized once management commits funding and completion is probable |
| Post-implementation / operation stage | Training, maintenance, bug fixes | All costs expensed |
The model worked for waterfall. It broke down badly for agile. In a two-week sprint, a team can move through what the old model called "preliminary" and "application development" activities in the same iteration. Identifying the precise moment the preliminary stage "ends" became an exercise in judgment that produced inconsistent results across companies and audit engagements.
The other persistent pain points under the current model:
- Post-implementation costs (maintenance, bug fixes) are frequently misclassified as capitalizable application development costs.
- General and administrative overhead and training costs are sometimes incorrectly capitalized.
- The unit-of-account question (what counts as a single "project"?) was never clearly defined.
- Cloud computing arrangement (CCA) implementation costs require mapping activities to the same three stages under ASU 2018-15, which is equally awkward in practice.
How ASU 2025-06 Replaces the Stage Model
ASU 2025-06, issued September 18, 2025, removes all references to project stages from ASC 350-40 and replaces them with two affirmative conditions that must both be satisfied before any costs can be capitalized.
As KPMG's Financial Reporting View summarizes the new threshold:
"The internal-use software development cost capitalization threshold eliminates accounting consideration of software development 'stages.' Cost capitalization will now begin solely when management has authorized and committed to funding the software project, and it is 'probable' the project will be completed and the software used to perform its intended function (the 'probable-to-complete' threshold)."
The two conditions are:
- Management authorization and funding commitment. Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding the software project.
- Probable-to-complete threshold. It is probable the project will be completed and the software will be used to perform the function intended.
FASB defines "probable" using the ASC Master Glossary definition: the future event or events are likely to occur. That is a higher bar than "reasonably possible" and higher than some practitioners applied informally under the old stage model.
Critically, the probable-to-complete threshold is not met until significant development uncertainty has been resolved.
What Is "Significant Development Uncertainty" and When Is It Resolved?
Significant development uncertainty is the new gating concept under ASU 2025-06. It blocks capitalization even after management has authorized and committed funding. According to KPMG's February 2026 handbook, significant development uncertainty exists when either of the following is present:
"(1) the software or its core features/functions are novel, unique or unproven, or (2) the significant performance requirements of the software (i.e. what the software is needed to do) remain unidentified or subject to substantial further revision."
For software built on proven technology with well-defined requirements, the new model may not change the capitalization start date much. For software involving novel technology, particularly AI and large language models, capitalization will be delayed until the uncertainty is resolved through coding and testing.
How is significant development uncertainty resolved? The uncertainty must be resolved through coding and testing that establishes the software can meet its performance requirements. This is analogous to how "high-risk development issues" are resolved for external-use software under ASC 985-20, creating a conceptual bridge between the two standards.
For audit purposes, documentation matters. The resolution event should be supported by:
- A dated technical memo from the development team confirming the novel functionality was successfully demonstrated
- Test results or proof-of-concept outputs that establish the software can perform its intended function
- Sign-off from an engineer or technical lead with authority to confirm the uncertainty is resolved
A proof-of-concept alone may not be sufficient if it does not establish that the software can meet its actual performance requirements at production scale.
Key takeaway: Management funding approval is necessary but not sufficient to begin capitalizing costs. If significant development uncertainty exists, capitalization cannot start until coding and testing resolve it, regardless of how much has been spent or approved.
Before vs. After ASU 2025-06: Side-by-Side Comparison
This table covers every major judgment point practitioners face.
| Judgment Point | Current ASC 350-40 (Pre-ASU) | ASU 2025-06 (Post-Adoption) |
|---|---|---|
| Capitalization trigger | Entry into application development stage | Management authorization + probable-to-complete threshold met |
| Agile / iterative development | Stage boundaries must be identified within each sprint (highly subjective) | Stage-neutral; same two conditions apply regardless of methodology |
| Novel / unproven technology | No explicit concept; judgment applied at stage boundary | Significant development uncertainty blocks capitalization until resolved through coding and testing |
| CCA implementation costs | Mapped to three stages under ASU 2018-15 | Same two-condition model applies; stage mapping eliminated |
| AI / ML development costs | No explicit guidance; applied by analogy to stage model | Significant development uncertainty concept directly applicable; KPMG Feb 2026 handbook addresses AI data costs |
| Cessation of capitalization | Entry into post-implementation/operation stage | When the software is substantially complete and ready for its intended use |
| Amortization start | When software is ready for its intended use | Unchanged |
| Unit of account | Undefined; inconsistent practice | Judgment required; a project can be a new product, distinct module, or major feature |
| New required disclosure | None specific to cash flows | Cash paid for capitalized software development costs |
As Wipfli noted in its comment letter on the exposure draft: "The targeted improvements to remove project stages will align accounting practices more closely with current nonlinear software development methodologies, such as Agile. This will improve consistency and application of Subtopic 350-40, as there will be less interpretation around applying modern nonlinear development methodologies to the 'waterfall' based principles that currently exist in ASC 350-40."
Wipfli also noted that entities are expected to capitalize a similar amount of costs under both frameworks for most projects, with one important exception: the significant development uncertainty concept may delay capitalization for truly novel software projects relative to the old application development stage trigger.
Capitalizing AI and LLM-Based Software Costs Under ASU 2025-06
This is where ASU 2025-06 has the sharpest practical teeth, and where most existing guidance leaves practitioners without a concrete answer. The KPMG February 2026 handbook is the first major Big-4 publication to tackle AI and ML training data capitalization directly in the context of ASU 2025-06.
The Deloitte AI Worked Example: Entity Y
Deloitte's Heads Up publication includes an illustrative example involving Entity Y, a company building an AI-powered accounting tool with two components:
- Extract functionality: Uses off-the-shelf, proven technology to pull data from documents.
- Write functionality: Uses a novel LLM-based approach to generate accounting outputs (performance obligation assessments).
The timeline for the write functionality shows how long capitalization can be delayed:
| Date | Event | Capitalization Status (Write Functionality) |
|---|---|---|
| January 15 | CEO approves and commits funding | Not yet; significant development uncertainty exists |
| February 28 | AI specialists hired; LLM service contract signed | Not yet; uncertainty remains |
| June 30 | Specific performance requirements identified | Not yet; technology remains novel and unproven |
| September 30 | AI specialists resolve novel development risk through coding and testing | Capitalization begins |
| December 15 | Software substantially complete | Capitalization ceases |
From funding approval to capitalization start: nine and a half months, solely due to significant development uncertainty. All costs incurred before September 30 are expensed.
The Unit-of-Account Question: View A vs. View B
The Deloitte example also illustrates a judgment that can dramatically change capitalization timing: whether a software initiative is one project or multiple.
View A treats extract and write as a single project (funded together, one unit of account). Capitalization does not begin until September 30, when the novel write functionality uncertainty is resolved. All costs, including those for the proven extract functionality, are expensed until that date.
View B treats them as separate projects, because the extract functionality can be delivered independently even if the write functionality is never completed. Under View B, extract functionality costs begin capitalizing on January 15 (CEO approval date, no significant development uncertainty). Write functionality costs still do not capitalize until September 30.
The practical implication: a single unit-of-account judgment can shift months of development costs from the income statement to the balance sheet. This determination requires documented analysis of whether each component can be independently delivered and used.
Can You Capitalize AI Training Data and LLM Fine-Tuning Costs?
The Deloitte example confirms that costs incurred for training an AI model that are necessary to establish that the software can perform its intended function through the design specification phase are capitalizable once the probable-to-complete threshold is met. This means:
- AI model training costs: Capitalizable after significant development uncertainty is resolved, if the training is necessary to meet performance requirements.
- LLM service contract costs (compute): Capitalizable to the extent they are incurred during the capitalization window and directly attributable to the development effort.
- Training data acquisition costs: The KPMG February 2026 handbook addresses AI data costs directly; the analysis depends on whether the data is consumed in development (capitalizable if it meets the threshold) or is an ongoing operational cost (expensed).
- General R&D exploration costs: Expensed. If the team is still determining whether the AI approach is feasible, significant development uncertainty almost certainly exists.
Cloud Computing Arrangement (CCA) Implementation Costs
Under ASU 2018-15, customers in a cloud computing service contract apply the same stage-based model as ASC 350-40 to determine which implementation costs are capitalizable. This means SaaS customers must map their implementation activities to the preliminary, application development, and post-implementation stages, even though the arrangement does not include a software license.
Upon adoption of ASU 2025-06, the stage-neutral two-condition model will apply to CCA implementation costs as well. The stage-mapping exercise disappears. Capitalization begins when management authorization and the probable-to-complete threshold are both met, and significant development uncertainty (if any) is resolved.
For most standard SaaS implementations using off-the-shelf software from a reputable provider, significant development uncertainty will not exist. The software is proven, and performance requirements are typically defined early. The practical effect for CCA costs may be minimal, but the documentation burden of stage mapping is eliminated.
ASC 350-40 vs. ASC 985-20: Which Standard Applies?
The determination of which standard applies is a threshold question with significant financial statement consequences. The two standards differ in their capitalization triggers:
- ASC 985-20 requires capitalization only after technological feasibility is achieved, which in practice is a late-stage trigger. Most development costs are expensed.
- ASC 350-40 (current model) requires capitalization once the application development stage begins, which is an earlier trigger. More costs are capitalized.
For SaaS companies, the key test is whether the customer can take possession of the software and run it independently. If yes, ASC 985-20 may apply. If the software is hosted by the developer and customers only access it as a service, ASC 350-40 applies to the developer's costs. When the same codebase serves both internal operations and external customers, a "predominant use" analysis is required.
As Wipfli observed, the probable-to-complete threshold under ASU 2025-06 is analogous to technological feasibility under ASC 985-20, narrowing the conceptual gap between the two standards. BDO has noted that FASB expects more software development costs may be expensed under the revised ASC 350-40 guidance, particularly for novel software, which further narrows the practical difference in outcomes.
Transition Methods for ASU 2025-06: Which Should You Choose?
ASU 2025-06 offers three transition approaches, each with different financial statement and operational implications. The mandatory effective date is for annual periods beginning after December 15, 2027 (calendar-year 2028). Early adoption is permitted as of the beginning of any annual period, meaning a calendar-year entity could have early-adopted as of January 1, 2026.
| Transition Method | How It Works | Key Implication |
|---|---|---|
| Prospective | Apply new rules to all new costs from adoption date; existing capitalized balances continue under old rules | Simplest operationally; no restatement; creates a mixed-model period |
| Modified prospective | Apply new rules prospectively; derecognize capitalized costs on in-process projects that no longer meet the new criteria through a cumulative-effect adjustment to opening retained earnings | Cleans up the balance sheet for projects that would not qualify under new rules; one-time retained earnings hit |
| Retrospective | Recast comparative periods; cumulative-effect adjustment to opening retained earnings of the earliest period presented | Most comparable financial statements; highest restatement effort |
The prospective method is operationally simplest but can create a "cliff" effect: projects that were being capitalized under the old stage model but would not meet the probable-to-complete threshold under the new model continue to carry capitalized balances until amortized or impaired. This can mislead readers about the quality of the balance sheet.
The modified prospective method is often the right choice for entities with in-progress agile projects where stage boundaries were applied inconsistently. It clears out costs that should not have been capitalized without the full restatement burden.
The retrospective method produces the most comparable financial statements and is worth the effort for entities where software capitalization is material to investors and analysts.
Tax Implications of Transition Method Choice
The transition method you choose has deferred tax consequences that belong in the CFO's analysis. If the modified or retrospective method results in derecognizing previously capitalized software costs, the book-tax difference narrows or reverses, affecting the deferred tax liability balance and the current-period tax provision under ASC 740.
This interacts directly with Section 174A, which requires capitalization and amortization of specified research and experimental (R&E) expenditures for tax purposes. Software development costs that are expensed for book purposes under the new ASU 2025-06 rules may still require capitalization under Section 174A for tax, creating a permanent book-tax difference. See Finrep's Section 174A deferred tax guide for the full mechanics.
New Disclosure Requirements Under ASU 2025-06
ASU 2025-06 introduces a new required disclosure: cash paid for capitalized software development costs. This is a decision-useful disclosure for financial statement users seeking information about a reporting entity's cash outflows for software investment.
Additionally, ASU 2025-06 clarifies that the disclosure requirements under ASC 360-10 (Property, Plant, and Equipment) apply to all capitalized internal-use software costs, regardless of how those costs are presented in the financial statements. Entities no longer need to provide the intangible asset disclosures under ASC 350-30 for internal-use software.
For preparers, the new cash-paid disclosure requires:
- Identifying cash outflows attributable to capitalized software development (separating them from expensed development costs)
- Determining whether those cash flows are classified as operating or investing in the statement of cash flows
- Drafting disclosure language that clearly communicates the amount and nature of the investment
Many preparers are not tracking cash paid for capitalized software separately from total development spend. Building that tracking into time-reporting and project accounting systems before adoption is a practical prerequisite.
Should You Early-Adopt ASU 2025-06?
For a calendar-year entity, early adoption as of January 1, 2026 is permitted. The case for early adoption is strongest when:
- Your development team uses agile or iterative methodologies and the stage-boundary exercise is producing inconsistent results
- You have significant AI or novel technology development where the new framework provides clearer guidance
- Audit friction over stage identification is consuming disproportionate time and creating restatement risk
- You want to align book and tax treatment more closely before Section 174A differences compound
The case against early adoption:
- In-progress projects with large capitalized balances may require derecognition under the modified or retrospective method, creating a one-time earnings impact
- The new judgment requirements (unit of account, significant development uncertainty documentation) require updated internal policies and time-tracking systems
- Deferred tax adjustments from transition require coordination with the tax team
FASB Chair Richard R. Jones described modernizing software accounting guidance as a "top priority identified by stakeholders during our last agenda consultation", signaling that the changes reflect broad practitioner demand. For most entities with active software development programs, the operational benefits of early adoption outweigh the transition complexity.
For the full analysis of ASU 2025-06's mechanics and the AI cost treatment, see Finrep's 2026 practitioner's guide to software capitalization under ASU 2025-06.
FAQ
When does capitalization begin under the current ASC 350-40 three-stage model? Capitalization begins when the entity enters the application development stage, which requires management to have committed to funding the project and the completion of the project to be probable. All costs in the preliminary project stage are expensed.
What is the mandatory effective date for ASU 2025-06? ASU 2025-06 is effective for all entities for annual reporting periods beginning after December 15, 2027, and interim periods within those annual periods. For calendar-year entities, that means January 1, 2028. Early adoption is permitted as of the beginning of any annual period.
Can we capitalize costs incurred before significant development uncertainty is resolved? No. Under ASU 2025-06, the probable-to-complete threshold is not met while significant development uncertainty exists. Costs incurred before the uncertainty is resolved through coding and testing must be expensed, even if management has already authorized and committed funding.
How do we determine the unit of account for a software project? Judgment is required. A software project can be a new product, a distinct module, or a major feature or function to an existing product. The key question is whether a component can be independently delivered and used. If yes, it may represent a separate unit of account with its own capitalization timeline, as illustrated by the Deloitte View A vs. View B analysis.
Does ASU 2025-06 change the accounting for software to be sold externally (ASC 985-20)? No. ASU 2025-06 does not change ASC 985-20. External-use software continues to follow the technological feasibility trigger.
Where can we get authoritative guidance on edge cases not covered by the standard? FASB's Technical Inquiry System is available for entities with specific application questions about ASU 2025-06. The KPMG February 2026 handbook and Deloitte's Heads Up publication are the most current Big-4 resources and cover AI data costs and worked examples in detail.
