ASC 350-40 Software Capitalization Guide: Before and After ASU 2025-06

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.

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:

1. Management authorization and funding commitment. Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding the software project.
2. 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.

Buying from a vendor doesn't settle the question for custom work. In one of the Deloitte Heads Up examples, a purchased base layer met the threshold right away. An analytical layer the provider had never delivered before carried significant development uncertainty, so those costs were expensed until coding and testing resolved it.

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.

Impairment: What Happens If the Criteria Are No Longer Met

Capitalization can switch off midstream. If the requirements in ASC 350-40-25-12 through 25-12A stop being met for software still in development, you stop capitalizing and apply the impairment guidance in ASC 350-40-35-1 through 35-3 to the balance already on the books (ASC 350-40-25-13, as amended).

That test is harsh. The asset is reported at the lower of carrying amount or fair value less costs to sell, and the rebuttable presumption is that uncompleted software has a fair value of zero (ASC 350-40-35-3).

A common trigger is a substantial rewrite of performance requirements after capitalization began, which brings significant development uncertainty back. The codification's other indicators include no budget or spend for the project, programming problems that can't be resolved on time, significant cost overruns, and a decision to buy third-party software instead. Document the triggering event and the impairment assessment when they happen.

Before vs. After ASU 2025-06: Side-by-Side Comparison

This table covers every major judgment point practitioners face.

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:

From funding approval to capitalization start: about eight 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).
• Model fine-tuning costs: Same answer as training. Capitalize only after the threshold is met, and only the work needed for the software to meet its design specifications.
• Data labeling and preparation costs: Same threshold test, so nothing before the uncertainty is resolved. Watch ASC 350-40-25-5, which expenses data conversion costs such as purging or cleansing existing data.
• Prompt engineering for unproven functionality: Expensed until coding and testing resolve the uncertainty.
• User training costs: Always expensed, before and after ASU 2025-06. The amended ASC 350-40-25-4 says training costs aren't internal-use software development costs.
• 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.

Do the two models now align? They're closer, and they still differ. In the ASU's basis for conclusions, the Board expects more of the cost to build software delivered through a cloud arrangement to be expensed, which moves SaaS outcomes toward on-premises software under ASC 985-20, but it says the amendments "will not entirely eliminate the differences." It also chose not to import the technological feasibility test into ASC 350-40.

If you build software that is both hosted and licensed, keep a separate analysis under each standard. For the full scope test and a side-by-side of both models, see Finrep's ASC 350-40 vs ASC 985-20 comparison.

Capitalization Decision Checklist (Post-ASU 2025-06)

Run each software project, or each functionality you can deliver on its own, through these steps. For the full procedure with a worked example, see Finrep's step-by-step guide to capitalizing internal-use software costs.

Step 1: Confirm the standard

• Software for internal use, or a service you host for customers? ASC 350-40.
• Software to be sold, leased or otherwise marketed? ASC 985-20.

Step 2: Define the unit of account

• Can each functionality be delivered and used on its own? If yes, assess each as a separate project.
• If not, assess one project. The most uncertain component sets the start date.

Step 3: Test the "two present, two absent" criteria

• Present: management with the relevant authority has authorized and committed to funding the project (ASC 350-40-25-12(b)).
• Present: it is probable the project will be completed and the software used as intended (ASC 350-40-25-12(c)).
• Absent: novel, unique or unproven functions or features whose uncertainty hasn't been resolved through coding and testing (ASC 350-40-25-12A(a)).
• Absent: significant performance requirements that are unidentified or still being substantially revised (ASC 350-40-25-12A(b)).

Step 4: Document the start date

• Record the date all four conditions are met. That's the capitalization start date.
• File the evidence that resolved the uncertainty: test results, working builds, specialist sign-off.
• Capitalize only the costs ASC 350-40-30-1 allows: external direct costs, payroll for time spent directly on the project, and interest under Subtopic 835-20.

Step 5: Sort post-launch costs

• Training and maintenance: expense as incurred.
• Upgrades and enhancements that add functionality: run them back through Step 3.

Step 6: Disclose

• Apply the ASC 360-10 PP&E disclosures to all capitalized internal-use software.
• Disclose the transition method, plus the cumulative effect on retained earnings if you use the modified approach.

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.

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.

Whichever method you pick, disclose the nature of and reason for the change under ASC 250-10-50-1(a). The modified approach adds the cumulative effect on retained earnings as of the adoption date, and the retrospective approach brings most of the ASC 250 transition disclosures.

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. Section 174A(d)(3) treats software development costs as research or experimental (R&E) expenditures, and Section 174A(a) lets companies deduct domestic R&E as incurred for tax years beginning after December 31, 2024, unless they elect to amortize it over at least 60 months (IRS Rev. Proc. 2025-28). Foreign R&E stays under Section 174 and is amortized over 15 years.

So domestic software costs you capitalize for book but deduct for tax create a temporary difference that reverses as the asset amortizes. Expensing more for book under ASU 2025-06 shrinks it. See Finrep's Section 174A deferred tax guide for the full mechanics.

New Disclosure Requirements Under ASU 2025-06

ASU 2025-06 adds no new disclosure. The exposure draft would have required cash paid for capitalized internal-use software to be presented as a separate investing outflow in the statement of cash flows. The Board dropped that proposal and decided against any incremental presentation or disclosure requirements (ASU 2025-06, paragraphs BC96 to BC100).

What the ASU does is clarify 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 (ASC 350-40-50-1). The intangible asset disclosures in ASC 350-30-50-1 through 50-3 are not required for internal-use software.

If your internal-use software note follows the ASC 350-30 intangibles format, move it and your disclosure checklist to the ASC 360-10 format before adoption.

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 a focused read on the ASU itself, see Finrep's ASU 2025-06 guide.

What Your Team Needs to Do Before Adoption

Adoption is a process and controls project as much as a policy update. Work through these before you pick a date.

1. Inventory in-process projects. Flag the ones built on novel, unique or unproven technology. They're the candidates for derecognition under the modified or retrospective approach.
2. Set a unit-of-account policy. Agree with development leads which products, modules and features count as separate projects, and write down why. Auditors will test this.
3. Replace stage-gate cost tracking. Retire the "preliminary," "application development" and "post-implementation" time codes. Track cost by project, and record the date the two-part test was first met and any date it stopped being met.
4. Keep a significant development uncertainty log. For each project, record the novel technology involved, the status of performance requirements, and the coding and testing milestones that resolved the uncertainty. Have technical accounting approve the capitalization start date.
5. Model all three transition methods. The retained earnings effect can be material for a large software portfolio, so run the numbers before you commit.
6. Update disclosure templates. Move internal-use software notes to the ASC 360-10 format.
7. Bring in tax early. The transition choice changes book-tax differences on capitalized software, so agree the deferred tax effects before you elect a method.

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.

Related reading

• What Is ASC 350-40? The 2026 Definitive Guide
• How to Capitalize Internal-Use Software Costs Under ASC 350-40
• ASC 350-40 vs ASC 985-20: Which Standard Governs Your Software Project?