.png)
On Sept. 18, 2025, the Financial Accounting Standards Board (FASB) issued ASU 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software. This release was the most substantial revision to internal-use software accounting since the original guidance was written in 1998. Therefore, organizations have good reason to revisit capitalization policies that, in many cases, haven't been reexamined since then.
The Accounting Standards Update (ASU) refines the rules for software a company builds or buys for its own use, found in Accounting Standards Codification (ASC) 350-40, but it doesn't merge them with the rules for software a company sells to customers (ASC 985-20). Those customer-facing software rules stay the same. The update also eliminates the separate guidance for website development costs (ASC 350-50), so websites now follow the same rules as other internal-use software.
Why The Change?
The 1998-era guidance was built around a linear software development model that tied capitalization to completion of specific project stages, a framework that no longer reflects how most organizations develop software today, where work doesn't necessarily move through discrete, sequential phases.
To address this, the ASU eliminates all references to development stages. In their place, it sets out two conditions that must be met before an organization can begin capitalizing internal-use software costs. Those conditions state:
- Management, with the relevant authority, implicitly or explicitly authorizes and commits to funding a computer software project.
- It is probable that the project will be completed and the software will be used to perform the function intended (referred to as the probable-to-complete recognition threshold).
Both of these conditions existed in some form under prior guidance, but the ASU adds new criteria for evaluating the probable-to-complete recognition threshold.
Evaluating The Probable-to-Complete Threshold
Under the amended guidance, the probable-to-complete threshold is not met if the project involves “significant development uncertainty.” That uncertainty exists when 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 FASB noted that some internal-use projects may clear the probable-to-complete threshold without needing a full development-uncertainty analysis.
This is a meaningful conceptual shift. Organizations developing internal-use software now need to think about technological feasibility in a way that echoes the analysis already required under ASC 985-20 for externally marketed software. The key difference is scope: ASC 985-20 feasibility analysis operates at the product-design level, while the ASC 350-40 assessment operates at the “software project” level, a term the ASC glossary leaves undefined. That means organizations will need to exercise judgment, and document their reasoning, in identifying what constitutes a project: a full application, a discrete module, or even a defined set of functions.
Disclosure & Effective Date
Capitalized costs under ASC 350-40 must now follow the property, plant, and equipment disclosure requirements in ASC 360-10, regardless of where those costs are presented in the financial statements.
The amendments apply to annual reporting periods beginning after Dec. 15, 2027, and to interim periods within those years, with early adoption permitted. Organizations may transition prospectively, retrospectively, or through a modified prospective approach, the last of which allows derecognition of in-process costs that no longer qualify for capitalization, with the effect run through a cumulative-effect adjustment to opening equity.
Practical Implications: More Than A Compliance Exercise
Although the ASU doesn't expand which costs qualify for capitalization, and the FASB's own expectation is that aggregate capitalization levels will hold steady or decline, early market feedback suggests the opposite may play out at some organizations. The driver isn't the new threshold itself; it's the fresh look that adoption forces. Many capitalization policies have quietly drifted out of step, even with the old guidance, and some organizations have defaulted to expensing nearly everything as a matter of convenience. For those organizations, adoption is a natural opportunity to re-examine capitalization policy.
That shift carries real financial-statement consequences worth flagging for management and audit committees:
- Moving costs from the income statement to the Statement of Financial Condition, where they're amortized, reduces operating expenses and can lift related metrics.
- A more robust Statement of Financial Condition may better reflect the technology investment organizations have made.
Building A Supportable Process
None of this is a green light to shift capitalization purely for income-statement effect. Any change should reflect how the organization actually develops software and be backed by thorough documentation. A few areas deserve particular attention as management builds or updates its process:
- Judgment is now central. The probable-to-complete assessment requires a real evaluation of whether unresolved, novel, or high-risk development issues exist, the exact kind of judgment call that attracts audit scrutiny.
- Real-time documentation of authorization and completion decisions. Funding commitments and completion assessments need to be captured as they happen, not reconstructed after the fact.
- Time tracking by developer and task. This is often the weakest link in supporting capitalized software costs. A reliable system for tracking development effort by task and developer is essential to substantiate what's been capitalized.
- Defined unit of account. Whether the “project” is a full application, a module, or a set of functions should reflect how it's actually authorized, funded, tracked, and managed, and that definition should be applied consistently.
- Recurring review. Capitalization decisions should be revisited periodically, not set once and left alone.
- Transition method and comparability. The chosen transition approach (prospective, modified, or retrospective) affects how your Statement of Financial Condition and income statement look, and is worth thinking through before committing.
- Downstream balance sheet effects. Higher capitalized balances bring larger amortization, ongoing impairment considerations, and expanded PP&E disclosure obligations under ASC 360-10.
Assigning clear accountability, setting explicit thresholds, and requiring regular sign-offs become more important under this framework, both to maintain internal consistency and to hold up under audit scrutiny. For more information about these changes and what you can do to prepare, contact GBQ's financial services team today.
Adopting ASU 2025-06 involves judgment calls that auditors will look at closely, from defining what counts as a project to choosing a transition method that shapes how your financial statements look. GBQ's Financial Services Team can help you review your current capitalization policy, build the documentation and time-tracking processes needed to support it, and model the financial statement impact before you commit to an approach. Contact our team to start the conversation.
Frequently Asked Questions About ASU 2025-06
What is ASU 2025-06?
ASU 2025-06 is an update from the Financial Accounting Standards Board (FASB) that changes how organizations account for software they build or buy for their own use. Issued Sept. 18, 2025, it is the most significant revision to internal-use software accounting since the original guidance was written in 1998.
What changed about when organizations can start capitalizing internal-use software costs?
The update removes the old project stages that determined when capitalization could begin. Instead, organizations can start capitalizing costs once two conditions are met: management has authorized and committed to funding the project, and it is probable the project will be completed and the software will work as intended.
What is the probable-to-complete threshold?
It's the second of the two conditions for capitalization. Under the new guidance, the threshold is not met if a project involves significant development uncertainty. That uncertainty exists when the software includes novel or unproven features that haven't been resolved through coding and testing, or when its major performance requirements haven't been identified or are still being substantially revised.
Does ASU 2025-06 affect software sold to customers?
No. Accounting for software developed to be sold, leased or marketed to customers under ASC 985-20 stays the same. The update applies only to internal-use software under ASC 350-40.
How are website development costs handled under the new guidance?
The separate guidance for website development costs in ASC 350-50 has been eliminated. Website costs now follow the same rules as other internal-use software under ASC 350-40.
When does ASU 2025-06 take effect?
The amendments apply to annual reporting periods beginning after Dec. 15, 2027, and to interim periods within those years. Early adoption is permitted.
Will the update change how much software cost my organization capitalizes?
It depends. The FASB expects overall capitalization levels to hold steady or decline, but organizations that have been expensing most software costs out of convenience may find that a fresh policy review leads them to capitalize more.
