ASU 2025-06: What Changed, When It Takes Effect, and What to Do Now

On September 18, 2025, FASB issued ASU 2025-06, the most significant overhaul of internal-use software accounting in more than 25 years. The old three-stage model is gone. What replaces it will change how CFOs, controllers, and their teams document, time, and defend every software capitalization decision, including AI and ML projects, starting in 2028.

This article covers the mechanics of what changed, the effective date and transition options, the financial metrics implications most explainers skip, and a practical timeline for getting ready.

Key takeaway: ASU 2025-06 is mandatory for all industries, not just tech companies. Calendar-year companies must adopt for fiscal year 2028. If your capitalization policy still references "preliminary project stage" or "application development stage," it needs to be rebuilt from scratch.

What Is ASU 2025-06 and Why Did FASB Issue It?

ASU 2025-06 amends ASC Subtopic 350-40 (Internal-Use Software) to replace the legacy project-stage framework with a principles-based capitalization threshold. The old guidance, which traces back to SOP 98-1 and was codified more than 25 years ago, assumed software development followed a linear waterfall sequence: preliminary project, application development, post-implementation. Most organizations no longer work that way.

Agile sprints, continuous deployment, cloud-native architectures, and AI-assisted development blur the lines between planning, building, and testing. That made the stage-based model hard to apply consistently, and it showed: companies in the same industry reached different capitalization conclusions for functionally identical projects. FASB's response is a threshold that works regardless of development methodology.

The standard also incorporates website development guidance previously housed in ASC 350-50 into the new framework, and it clarifies that the ASC 360-10 (Property, Plant, and Equipment) disclosure requirements apply to all capitalized internal-use software costs, regardless of how those costs are presented on the balance sheet.

What the New Capitalization Threshold Actually Requires

Under ASU 2025-06, capitalization begins only when all three of the following criteria are met simultaneously.

Criterion 1: Management Authorization and Funding Commitment

"Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding a computer software project." Common evidence includes a board-approved budget line, a signed contract with a third-party developer, or documented executive approval of an internal development initiative. CEO verbal approval alone, without funding commitment, is not sufficient.

Criterion 2: Probable-to-Complete Recognition Threshold

"It is probable that the project will be completed and the software will be used to perform the function intended." FASB defines "probable" using the ASC Master Glossary standard: the future event is likely to occur. This is a higher bar than "reasonably possible" but does not require certainty.

Criterion 3: Resolution of Significant Development Uncertainty

This is the new judgment hot spot. The probable-to-complete threshold is not met until significant development uncertainty has been resolved. Significant development uncertainty exists if either of the following is present:

• "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: you cannot start capitalizing costs just because a project is funded and staffed. You must demonstrate, through coding and testing, that the novel or unproven aspects of the software actually work.

What Did NOT Change

Before teams start rebuilding every policy, it helps to know what ASU 2025-06 left alone. Per PwC, the following remain unchanged:

The standard changes when you start capitalizing, not what you capitalize once the threshold is met.

The AI and ML Software Problem: A Worked Example

For teams building AI tools, the significant development uncertainty criterion creates a timing gap that most companies are not yet accounting for.

Deloitte's Heads Up walks through a detailed illustrative example: an entity ("Y") develops an AI tool to automate accounting tasks using a large language model (LLM). The project timeline looks like this:

In this example, approximately 8.5 months of development costs are expensed before capitalization can begin, even though the project was funded from day one. Costs capitalized from September 30 include in-house model development, LLM implementation, and model training costs necessary to establish that the write functionality performs as designed.

The unit-of-account question matters here too. If the extract functionality (a proven capability) and the write functionality (novel and unproven) can be delivered independently, they may be treated as separate software projects. Under that view ("View B" in the Deloitte example), capitalization of extract-related costs begins in January when funding is committed, because no significant development uncertainty exists for that component. Only the write functionality costs are deferred until September 30.

Key takeaway: For AI and ML projects, the resolution of significant development uncertainty through coding and testing, not the hiring of engineers or the signing of contracts, is the capitalization trigger. Document the specific date and the testing evidence that resolved the uncertainty.

How This Affects EBITDA, IPO Readiness, and Transaction Valuations

This is the dimension that generic explainers skip, and it is the one CFOs should be focused on right now.

PwC states explicitly: "Adopting the new standard is much more than a technical accounting change. The application of the new standard may influence reported performance, financing flexibility, and transaction exit readiness, be it an IPO or a sale."

Here is the mechanism. Under the old stage-based model, many companies began capitalizing costs as soon as a project entered the "application development stage," which could happen relatively early. Under ASU 2025-06, if significant development uncertainty exists, those same costs are expensed until the uncertainty is resolved. For companies with large AI, ML, or bespoke software development pipelines, this shift can meaningfully reduce capitalized software balances and increase near-term operating expenses.

The downstream effects:

• EBITDA compression. Capitalized software costs are excluded from EBITDA; expensed development costs are not. A shift from capitalizing to expensing reduces reported EBITDA, which affects debt covenants, management incentive plans, and analyst coverage.
• IPO readiness. Companies preparing for an IPO will have their capitalization policies scrutinized in the S-1 registration process. Policies that do not reflect ASU 2025-06 will draw SEC staff comments.
• M&A due diligence. Acquirers will need to assess whether target companies' capitalized software balances are compliant with the new threshold. Historical over-capitalization under the old stage model may require purchase accounting adjustments or disclosure.
• Lender and covenant impact. If EBITDA-based covenants are tied to reported figures, a reduction in capitalized software balances could trigger headroom concerns.

Companies with material software development spend should model the impact of the new threshold on their capitalized balances before the 2028 effective date, not after.

ASU 2025-06 Effective Date and Transition Options

The effective date is fiscal years beginning after December 15, 2027. For calendar-year companies, that means mandatory adoption for fiscal year 2028, including interim periods within that year. Early adoption is permitted.

Three transition approaches are available:

Under the prospective approach (ASC 350-40-65-4(c)(1)), companies cease capitalizing incremental development costs under the old model and apply the new threshold going forward from the adoption date. No prior-period restatement is required.

Should You Adopt Early?

Early adoption makes sense in specific situations:

• Companies preparing for an IPO or sale. Getting the policy right before the S-1 or data room review avoids last-minute adjustments.
• Companies with large AI or ML development pipelines. The new threshold is already the more accurate framework for these projects; early adoption removes the risk of over-capitalizing under the old model.
• Companies whose stage-based tracking systems are already broken. If agile delivery has made your existing policy unworkable, the new principles-based model may actually be easier to apply.
• Companies with material in-process projects that clearly meet the new threshold. Early adoption locks in the accounting treatment before auditors start applying the new standard.

Companies that are close to debt covenants or have EBITDA-sensitive compensation plans should model the impact carefully before electing early adoption.

What Needs to Change Before 2028: A Practical Roadmap

PwC notes that "ASU 2025-06 is designed to be more practical in modern delivery environments, but it raises the bar on documentation, governance, and cross-functional alignment." Companies with policies and processes built around the old stage model will need to rebuild them.

Here is what that looks like in practice:

2026 (now):

1. Inventory all active and planned software development projects, including ERP implementations, cloud migrations, analytics platforms, and AI/ML tools.
2. Assess which projects have significant development uncertainty under the new criteria.
3. Model the financial impact: how would the new threshold change your capitalized software balances and EBITDA if adopted today?
4. Brief the audit committee and board on the standard and its financial metrics implications.

2027:

1. Revise the internal capitalization policy to eliminate all references to project stages.
2. Redesign project tracking and cost allocation processes to capture the three criteria (authorization, probable-to-complete, uncertainty resolution) rather than stage transitions.
3. Align IT, finance, legal, and project management on the new documentation requirements.
4. Decide on transition approach (prospective, modified prospective, or retrospective) and early adoption timing.
5. Engage external auditors early to align on what evidence will satisfy the new criteria, particularly for AI and ML projects.

2028 (mandatory effective date for calendar-year companies):

1. Apply the new threshold to all software development costs from the beginning of the fiscal year.
2. Disclose the nature and reason for the change in accounting principle in the first interim period of adoption.
3. Ensure ASC 360-10 PP&E disclosures cover all capitalized internal-use software costs.

Documentation: What Auditors Will Look For

The new standard does not prescribe how to document compliance, but auditors will focus on four areas:

• Management authorization and funding commitment. Board minutes, signed contracts, approved capital budgets, or documented executive approvals with funding amounts.
• Probable-to-complete assessment. Written management judgment, updated at each reporting date, that the project will be completed and used as intended.
• Significant development uncertainty identification and resolution. A contemporaneous record of what novel or unproven aspects existed, how they were tested, and the specific date on which testing resolved the uncertainty.
• Agile cost tracking. A methodology for allocating costs to specific projects and criteria states in an iterative environment, whether time-based, roles-based, or sprint-based.

The standard does not mandate detailed time tracking over a roles-based model, but whichever approach a company uses must be applied consistently and defensible under audit.

Who Is In Scope (and a Common Misconception)

ASU 2025-06 applies to all entities subject to ASC 350-40 guidance, across all industries. It is not limited to technology companies. Any organization that develops, customizes, or implements software for internal use is in scope, including:

• ERP implementations (SAP, Oracle, Workday)
• Cloud migrations and SaaS implementations
• Custom analytics and data platforms
• AI and ML tooling built for internal operations
• Digital customer-facing tools used internally

For off-the-shelf vendor software, the probable-to-complete criterion is generally met because the software is developed by a reputable third party. However, if the vendor is implementing novel, unproven functionality that has not been successfully delivered before, significant development uncertainty may still exist and must be assessed.

The standard does not affect ASC 985-20 (software sold, leased, or marketed to customers) or the scoping determination between ASC 350-40 and ASC 985-20.

For a deeper look at how to apply the new capitalization criteria step by step, including the unit-of-account analysis and worked cost examples, see our ASC 350-40 capitalize vs. expense practitioner walkthrough.

FAQ

Does ASU 2025-06 apply to SaaS and cloud implementations? Yes. Cloud and SaaS implementation costs that are in scope of ASC 350-40 are subject to the new threshold. For most off-the-shelf SaaS implementations, significant development uncertainty will not exist because the vendor's software is proven. However, if the implementation involves novel customizations or integrations with unproven performance requirements, the assessment must be made.

Can we adopt ASU 2025-06 before the 2028 mandatory date? Yes. Early adoption is permitted as of the date of this writing. Companies should model the financial impact and align with their auditors before electing early adoption.

Will ASU 2025-06 reduce our capitalized software balances? For most standard ERP and SaaS implementations, the FASB does not expect material changes in capitalization outcomes. For cloud computing arrangements and projects with novel or unproven functionality (including AI and ML tools), the FASB acknowledges that capitalization may decrease under the new model. PwC and others flag that this can compress EBITDA and affect key financial metrics.

What happens to in-process projects at the adoption date? It depends on the transition approach chosen. Under the prospective approach, companies apply the new threshold to costs incurred after the adoption date and do not restate prior periods. Under the modified prospective approach, in-process projects that no longer meet the new threshold require a cumulative-effect adjustment to opening retained earnings.

How does this interact with Section 174 R&D capitalization for tax purposes? ASU 2025-06 is a GAAP accounting change and does not directly alter Section 174 tax treatment of software development costs. However, a shift in the GAAP capitalization timing may create book-tax differences that affect deferred tax balances. Tax teams should assess the interaction with their Section 174 analysis separately.

Does ASU 2025-06 affect how we disclose software costs in our financial statements? Yes, in one specific way: the standard clarifies that the ASC 360-10 (PP&E) disclosure requirements apply to all capitalized internal-use software costs, regardless of how those costs are presented on the balance sheet. Companies that present capitalized software as an intangible asset rather than PP&E must still apply the ASC 360-10 disclosures.