FASB Amends Guidance on the Accounting for and Disclosure of Software Costs (September 18, 2025)

FASB Amends Guidance on the Accounting for and Disclosure of Software Costs

Background

On September 18, 2025, the FASB issued ASU 2025-06,1 which amends certain aspects of the accounting for and disclosure of software costs under ASC 350-40.2 The ASU makes targeted improvements to ASC 350-40 but does not fully align the framework for accounting for internally developed software costs that are subject to ASC 350-40 with the framework applied to software to be sold or marketed externally that is subject to ASC 985-20. The ASU also does not amend the guidance on costs of software licenses that are within the scope of ASC 985-20. The amendments supersede the guidance on Web site development costs in ASC 350-50 and relocate that guidance, along with the recognition requirements for development costs specific to Web sites, to ASC 350-40.

Recognition

One of the FASB’s stated objectives of the project that resulted in the issuance of ASU 2025-06 was to modernize the guidance to reflect the software development approaches currently used. Specifically, the Board observed that software is not always developed in a linear manner, which is an underlying tenet of the existing internal-use software capitalization framework. To clarify how the guidance applies to both linear and nonlinear software development, the ASU removes all references to “development stages” from ASC 350-40. Under current GAAP, capitalization of software development costs for internal-use software is required once the preliminary project stage is complete. Under the ASU, however, only the following criteria in ASC 350-40-25-12(b) and (c) must be met for entities to begin capitalizing software costs:

“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’).”

While an entity is already required to meet the above criteria under current GAAP to capitalize software development costs, the ASU provides new guidance on how to evaluate whether the probable-to-complete recognition threshold has been met. Specifically, such threshold would not be met when there is “significant uncertainty associated with the development activities of the software (referred to as ‘significant development uncertainty’).” ASC 350-40-25-12A(a) and (b) (added by the ASU) specify that if either of the following factors is present, significant development uncertainty exists:

“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 in the ASU’s Basis for Conclusions that for certain internal-use software projects, such as enterprise resource planning (ERP) implementations that use a developed solution, an entity may be able to conclude that the probable-to-complete threshold has been met without the need to evaluate whether significant development uncertainty is present. Further, the Board indicated that it expects that as a result of the amendments, more costs will be expensed for the development of software that will be sold as part of a cloud computing arrangement. This is because the amendments require entities to apply judgment in determining whether the probable-to-complete threshold is met, which would not be the case if the software being developed exhibits either of the factors listed in ASC 350-40-25-12A. The Board believes that these factors may be observed more often for software that is being developed to be sold as a service because the development risks associated with such software may be similar to those for software within the scope of ASC 985-20 that is developed to be sold or marketed externally.

Connecting the Dots

ASC 985-20 requires any development costs that are incurred before technological feasibility is established to be expensed as incurred. Under ASC 985-20-25-2, one indication that technological feasibility has been established is that a “detail program design has been reviewed for high-risk development issues (for example, novel, unique, unproven functions and features or technological innovations), and any uncertainties related to identified high-risk development issues have been resolved through coding and testing.” Because any high-risk development issues need to be resolved through coding and testing, which is typically finished at or around the same time software development is complete, most costs for developing software that will be sold, leased, or marketed externally would be expensed as incurred.

Under the amended recognition threshold, entities developing internal-use software will similarly need to consider whether such software has “technological innovations or novel, unique, or unproven functions or features” and, if any are identified, whether uncertainty associated with the ability to develop those features or functions would also need to be “resolved through coding and testing.” This assessment would be performed at the level at which performance requirements have been established (i.e., the software project level), whereas the development risks associated with software designed to be sold or marketed externally within the scope of ASC 985-20 are evaluated at a product design level.

Product design is defined in the ASC master glossary as “[a] logical representation of all product functions in sufficient detail to serve as product specifications.” However, the term “software project” is not defined. Accordingly, when determining what constitutes a software project for which the probable-to-complete threshold is met, entities will need to apply judgment and document their reasoning. For example, a software project may be a whole application (e.g., a new ERP system), a major feature (e.g., a new reporting module), or even a set of functions (e.g., a set of application programming interfaces).

Further, under the ASU, entities are not required to review a detail program design for high-risk development issues (i.e., an entity does not need to have a detail program design to conclude that the probable-to-complete threshold has been met for a software project). Consequently, under the ASU, differences in capitalization thresholds might continue to exist between software that is developed for internal use in accordance with ASC 350-40 and software that is to be sold or marketed externally (in accordance with ASC 985-20).

The examples below illustrate the application of ASC 350-40 upon the adoption of ASU 2025-06.

Example 1

Entity X is a manufacturing company that has decentralized operations in several geographies and brands, each of which operates in distinct software environments that are aggregated during the consolidation process. The company has identified a need for a uniform reporting software layer to reduce the complexity of its consolidation process. Accordingly, X engages a reputable third-party software provider to implement the software solution (the “base layer”). During the negotiations, X determines that it would like the solution to provide functionality for identifying whether any of the key assumptions X made in reaching its consolidation conclusions about any of its variable interests have changed during the period (the “analytical layer”). This functionality does not currently exist in the third-party software, but the provider agrees to develop it under the contract.

The terms of the on-premise software license stipulate that the software will be provided for a five-year, noncancellable term, with fixed annual payments due when the software goes live and on each anniversary date thereafter during the term. The annual payments cover both the cost of the software license and postcontract customer support (PCS) for the base layer during the license term. The fees to develop the analytical layer are billed separately on the basis of market rates for time and materials. Management agrees to accept and use the ERP even if the analytical layer cannot be developed to perform the intended functionality.

The process for determining when to capitalize internal-use software license costs is the same regardless of whether the software is purchased or developed internally. Entity X first concludes that the off-the-shelf base layer and the analytical layer represent two separate software projects and therefore two units of account. Accordingly, X considers the criteria for capitalization of the software cost requirements in ASC 350-40-25-12 (as amended by the ASU) for each project individually. For the base layer, X concludes that as of the date it enters into the software contract:

“Management, with the relevant authority, implicitly or explicitly authorize[d] and committ[ed] 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” since the software is an off-the-shelf solution developed by a reputable third party.

Thus, X concludes that there is not significant uncertainty associated with the development activities of the base layer.

Then, X considers the analytical layer project and concludes that “management, with the relevant authority, implicitly or explicitly authorize[d] and committ[ed] to funding a computer software project.”

Next, X assesses the probable-to-complete recognition threshold and concludes that:

The significant performance requirements have been identified.
Because the provider has not successfully delivered the analytical layer in the past, the software has unproven functions or features that have been identified and the uncertainty related to the development of the unproven functions or features has not been resolved through coding and testing; therefore, significant development uncertainty exists and the probable-to-complete threshold has not been met.

As a result, at contract inception, X capitalizes costs associated with acquiring the base-layer software intangible asset and expenses professional service costs related to developing the analytical layer. Entity X allocates the fees paid that are attributable to the base layer and the PCS services, which represent an executory contract and, in accordance with ASC 350-40-25-17, recognizes an intangible asset for the costs attributable to the five-year term license of the base layer and a liability for the four unpaid years. The liability established is then discounted to reflect the fair value of the consideration transferred. Under ASC 350-40-30-1, X also capitalizes any eligible internal and additional external direct costs related to the implementation of the base layer. Any costs attributed to developing the analytical layer would be expensed as incurred until any development uncertainties have been resolved through coding and testing.

Example 2

Entity Y offers hosted ERP solutions to its customers as software as a service (SaaS). On January 15, 20X0, Y’s CEO approved and committed to funding a project to evaluate how Y can incorporate artificial intelligence (AI) into its SaaS offerings to provide a technical accounting support module. The module would be able to read customer contracts and extract key terms from the documents (the “extract functionality”) and, using generative AI technology trained on publicly available guidance, disclosures, and examples, create an output of revenue recognition considerations in the customer contract (the “write functionality”).

On January 15, 20X0, the technology necessary for providing the write functionality does not exist, and Y would need to use a combination of third-party tools and an in-house model to develop it. Entity Y has not selected the third-party tools and does not currently have the appropriate talent resources to perform the necessary in-house activities to develop the intended functionality. In addition, not all the significant performance requirements have been identified.

By contrast, the extract functionality is based on existing concepts and technology. Entity Y determines that it has decided what the software needs to do, and its in-house development personnel have the resources and capabilities to replicate the existing tool in the market. Accordingly, Y begins developing the extract functionality.

On February 28, 20X0, Y hired generative AI specialists to work on the write functionality and entered into a service contract to access a large language model (LLM) from a reputable third party. Through June 30, 20X0, Y evaluates how the AI specialists it hired can leverage and build on its existing LLM. As of June 30, 20X0, Y determined that the tool will be limited to identifying the distinct performance obligations in the contract; however, certain novel or unproven functions still need to be developed for the software to perform this task.

As of September 30, 20X0, the AI specialists have made significant progress toward developing the model and completed the coding and testing necessary to demonstrate that the write functionality can perform the intended task in accordance with the design specifications selected by Y. Although Y has resolved the development uncertainty, the model will still need to be trained on sufficient data to achieve the desired functionality.

On December 15, 20X0, Y completes the model training necessary to demonstrate that the write functionality can perform the performance obligation assessment in accordance with the design specifications.

The appropriate accounting for the costs to develop the functionality depends on Y’s evaluation of the unit of account (i.e., what constitutes the “software project”). There are two acceptable views:

View A — The extract and write functionality were funded as a single software project and therefore represent a single unit of account.

For each of the key dates above, Y assesses whether the internal and external costs to develop the application meet the capitalization requirements in ASC 350-40-25-12 as follows:
- On January 15, 20X0, although the CEO approved the funding for the project, the capitalization criteria in ASC 350-40-25-12 are not met because of significant development uncertainties.
- As of February 28, 20X0, although Y has hired the AI specialists and entered into a service contract to access a third-party LLM in developing its tool, significant development uncertainties remain. Accordingly, as of February 28, 20X0, Y has determined that the software still does not meet the requirement in ASC 350-40-25-12(c).
- As of June 30, 20X0, Y has identified a specific accounting output that the software must be able to write and, as a result, it has identified the significant performance requirements that are known and not expected to change. However, the ultimate technology that Y intends to develop remains novel, unique, and unproven. Accordingly, as of June 30, 20X0, the company has determined that the software still does not meet the requirement in ASC 350-40-25-12(c).
- As of September 30, 20X0, the AI specialists have resolved the software development risk related to the novel portions of the project through coding and testing. On the basis of such progress, the development uncertainty associated with the novel, unique, and unproven aspects of the software development described in ASC 350-40-25-12A has been resolved through coding and testing, and Y therefore concludes that the software meets the requirements in ASC 350-40-25-12(c).
Eligible software development costs incurred after September 30, 20X0, would be capitalized, including those related to the model developed in-house and implementing the LLM model. Entity Y would capitalize the costs incurred for training the model3 that were necessary to establish that the write functionality can perform the performance obligation assessment in accordance with the design specifications through December 15, 20X0.
View B — Because Y can provide the extract functionality even if the write functionality is not developed, each functionality represents a separate software project.

On January 15, 20X0, the CEO approved both projects. Because it is probable that the extract functionality will be completed (i.e., there isn’t significant development uncertainty associated with the software project), Y begins capitalizing eligible development costs allocable to such software project.

The milestones in View B for the write functionality are the same as those in View A, and costs related to the write project incurred after September 30, 20X0, are capitalized.

Example 3

Assume the same facts as in Example 2, except that after Entity Y’s technical accounting module is ready for its intended use, Y determines that there is a demand for an enhancement to its software that would provide principal-versus-agent analyses for revenue contracts.

On the basis of what it learned from its original technical accounting module project, Y believes that it can develop the new functionality with internal expertise and that although the functionality does not yet exist, the only development risk is related to systematizing the logic inherent in the accounting rules related to the guidance on principal versus agent. On January 31, 20X1, the CEO approves the software enhancement.

Entity Y determines that the desired functionality represents an upgrade to its current software; therefore, it considers the guidance in ASC 350-40-25-17A through 25-17E and concludes that (1) it is probable that the upgrade will result in additional functionality and (2) it should evaluate the upgrade as a new software project. Entity Y once again considers the guidance in ASC 350-40-25-12 and 25-12A and determines that as of January 31, 20X1, management has committed to funding the project and that the probable-to-complete recognition threshold is met. In making this determination, Y considers the factors in ASC 350-40-25-12A and notes that the performance requirements are defined for principal-versus-agent analyses and that although the upgrade will result in additional functionality, there are no significant development uncertainties associated with such functionality. Management reaches this decision on the basis of the successful release of Y’s previous technical accounting module and concludes that no new technological innovations or novel, unique, unproven functions and features need to be developed for the new functionality to be created. Rather, the same logic and coding will be used to create the new module, and only routine coding, testing, and model training will be needed to create the new functionality.

Entity Y therefore begins capitalizing development costs of the new module after January 31, 20X1.

Presentation and Disclosure

In accordance with ASU 2025-06, entities must apply the disclosure requirements in ASC 360-10 on property, plant, and equipment to capitalized costs accounted for under ASC 350-40 regardless of how they present those costs in the financial statements.

Other Matters

Costs of Software to Be Sold, Leased, or Marketed

ASU 2025-06 does not amend the requirements in ASC 985-20.

Web Site Development Costs

Under the ASU, the guidance in ASC 350-50 is superseded and relocated to ASC 350-40. Example 4 in ASC 350-40-55-18 through 55-21, as amended, illustrates the application of ASC 350-40 to Web site development costs.

Effective Date and Transition

The ASU’s amendments “are effective for all entities for annual reporting periods beginning after December 15, 2027, and interim reporting periods within those annual reporting periods. . . . Early adoption . . . is permitted in an interim or annual reporting period in which financial statements have not yet been issued or made available for issuance. If an entity adopts the [ASU] in an interim reporting period, it shall adopt the [ASU] as of the beginning of the annual reporting period that includes that interim reporting period.” Entities may apply the guidance prospectively, retrospectively, or via a modified prospective transition method. The modified prospective transition approach would allow entities to account for an in-process project that, before the transition date, met the capitalization requirements but would no longer meet the requirements for capitalization under the ASU by derecognizing the capitalized costs for that in-process project through a cumulative-effect adjustment to the opening balance of retained earnings. The example below illustrates the application of each transition approach to an in-process software project.

Example 4

Entity U is developing software to modernize its IT infrastructure. Although the software has novel and unproven features, U has obtained approval, determined the performance requirements, and selected vendors for the project. Further, U’s management has decided that it can achieve the desired performance requirements by using existing technology and that even though novel and unproven features were identified, it is probable that the software project will be completed and placed into service. Therefore, U concludes that the software project is in the application development stage and begins capitalizing costs on September 1, 20X7. As of December 31, 20X8, U has capitalized $2 million of eligible costs in accordance with ASC 350-40.

As of its adoption of ASU 2025-06 for fiscal year 20X8, U has made substantial progress on the software project but has not yet resolved, through coding and testing, all the development uncertainty associated with certain novel features and functionality. Accordingly, U concludes that on the date it adopts the ASU, the software project no longer meets the criteria for capitalization. Entity U would elect one of the ASU’s transition alternatives and apply it as follows:

Prospective transition under ASC 350-40-65-4(c)(1) — Entity U would cease capitalizing the incremental development costs for its IT project until the significant development uncertainty has been resolved through coding and testing. The legacy capitalization would remain on the balance sheet, and U would evaluate the capitalized costs for impairment in accordance with ASC 350-40.
Modified prospective transition under ASC 350-40-65-4(c)(2) — Entity U would derecognize its IT project and make a cumulative-effect adjustment of $2 million to the opening balance of retained earnings (or relevant equity balance) as of January 1, 20X8.
Retrospective transition under ASC 350-40-65-4(c)(3) — Entity U would make a cumulative-effect adjustment to retained earnings to derecognize its IT project as of the beginning of the first period presented.

Contacts

	Chris Chiriatti Audit & Assurance Managing Director Deloitte & Touche LLP +1 203 761 3039 cchiriatti@deloitte.com		Kristin Bauer Audit & Assurance Partner Deloitte & Touche LLP +1 312 486 3877 kbauer@deloitte.com
	Katy Rossino Audit & Assurance Partner Deloitte & Touche LLP +1 617 437 2411 krossino@deloitte.com		Aaron Shaw Audit & Assurance Partner Deloitte & Touche LLP +1 202 220 2122 aashaw@deloitte.com
	Michael Riso Audit & Assurance Manager Deloitte & Touche LLP +1 813 428 2801 miriso@deloitte.com

Footnotes

FASB Accounting Standards Update (ASU) No. 2025-06, Targeted Improvements to the Accounting for Internal-Use Software.

For titles of FASB Accounting Standards Codification (ASC) references, see Deloitte’s “Titles of Topics and Subtopics in the FASB Accounting Standards Codification.”

Costs to acquire data to train models that have an alternative use can generally be recognized as a separate intangible asset under ASC 350-30. For more information, see Deloitte’s October 7, 2024, Technology Spotlight on the accounting for the development of generative AI software products.

Heads Up is prepared by members of Deloitte's National Office as developments warrant. This publication contains general information only and Deloitte is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte shall not be responsible for any loss sustained by any person who relies on this publication.

The services described herein are illustrative in nature and are intended to demonstrate our experience and capabilities in these areas; however, due to independence restrictions that may apply to audit clients (including affiliates) of Deloitte & Touche LLP, we may be unable to provide certain services based on individual facts and circumstances.

Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients. In the United States, Deloitte refers to one or more of the US member firms of DTTL, their related entities that operate using the “Deloitte” name in the United States and their respective affiliates. Certain services may not be available to attest clients under the rules and regulations of public accounting. Please see www.deloitte.com/us/about to learn more about our global network of member firms. Copyright © 2025 Deloitte Development LLC. All rights reserved.