Accounting for and Disclosure of Software Costs

On June 22, 2022, the Financial Accounting Standards Board (FASB) decided to add the Accounting for and Disclosure of Software Costs project to its technical agenda. The purpose of the project is twofold, to modernize guidance on accounting for software costs, and to enhance transparency about an entity’s software costs. [1] The scope of the project includes recognition, measurement, presentation, and disclosure of all software costs either internally developed or acquired. The project covers all software costs subject to the guidance in ASC 350-40 and ASC 985-20. The project is still in the early stages of board deliberations and the guidance that has been suggested is subject to change. The main objective of this article is to give a broad understanding of what is currently proposed and to create awareness of foreseeable changes in this area of accounting. This article will address the current accounting for software costs under ASC 350-40 and ASC 985-20. It will then examine the current state of the project and what has been proposed.

Current Guidance ASC 350-40 and ASC 985-20

ASC 350-40 – Internal Use Software

According to ASC 350-40-15-2A, internal-use software has two characteristics. Firstly, it is acquired, developed, or modified to meet an entity’s internal needs. Secondly, during development, no substantive plan exists to market the software externally.[2] Guidance in ASC 350-40 does not apply to costs incurred to develop or acquire software that will be sold, leased, or marketed externally. This guidance is often interpreted as referring to software where hardware is physically delivered to the client site. Consequently, software arrangements that don't entail physical delivery to the client, such as Software as a Service (SaaS) contracts, may fall under ASC 350-40, even if they are sold beyond the business premises.

The guidance outlines four stages that occur during software development. Costs that are incurred to purchase or develop internal-use software are capitalized or expensed based on the state of the project during which those costs were incurred. The following table summarizes how costs incurred should be accounted for in each stage.

1. Preliminary project stage – determining performance requirements, making decisions, pre-commitment to the project, exploring needs and alternatives³	Expensed as incurred
2. Application development stage – management commits to funding a project and it is probable that the project will be completed³	Capitalized until the software project is substantially complete and ready for its intended use3 Indirect costs – expensed as incurred³
3. Postimplementation-operation stage	Expensed as incurred
4. Upgrades and enhancements	Capitalized if it adds additional functionality³

There are exceptions to these general rules that must be considered in each stage. This paper seeks to give an overview. Additional information can be found in PwC’s firm guide here.

ASC 985-20 – Internally developed software held for sale

In section ASC 985-20, costs are categorized as either capitalized or expensed, contingent upon the project's stage. Once the project attains technological feasibility, costs are capitalized. The accompanying illustration from PwC's guide aids in understanding the specific project stages when costs are capitalized.[4]

Technological feasibility is “established when the entity has completed all planning, designing, coding and testing activities that are necessary to establish that the product can be produced to meet its design specifications”[5]. Because this is such a high bar to meet, often companies designate the point at which technological feasibility has been met as just prior to the software being released to customers. Consequently, numerous software development firms currently expense all software costs as incurred.

Proposed Standards

In September of 2023, the FASB technical staff presented a single model approach to the Board. Many of the recommendations follow a timeline approach similar to the one currently utilized in the codification while broadening the scope in the process. While this approach was comprehensive, the Board ultimately decided in their March 2024 meeting to pursue a targeted improvement approach, rather than a single model approach. The primary rationale behind this decision seemed to stem from investor outreach, indicating, that a targeted improvement approach could sufficiently address investor needs while minimizing the costs for standard setters and reducing change in outcomes for financial statement preparers. One issue that investors want the project to address is Software as a Service (SaaS) projects being accounted for under ASC 985-20 rather than under ASC 350-40. Additionally, investors are looking to see changes in ASC 350-40 that allow for more movement between software development stages.

This information comes from the FASB website and an overview can be found here. Additionally, the more detailed information provided in this article can be found in the September 20, 2023 Board Meeting.

The proposed unit of account is at the software project level. The staff observed that this unit of account involves a judgment call for entity management based on their specific facts and circumstances, providing greater flexibility and consistency for companies.

Capitalization and Amortization Thresholds

Capitalization of software costs is to begin at the point in time at which it is probable that the software project will be completed. The staff suggested three criteria to be evaluated in identifying the point in time at which a company as crossed the probable to complete threshold.

Management commitment – This point is not characterized as the point at which management has been authorized to complete the activity, but the point at which they have committed to the activity, implying that due diligence for the project has been completed.
Core capabilities – Identifying core capabilities requires management to gain an understanding of the functionalities they require from the software. The rationale behind this criterion is that management cannot fully commit to a software project if they are still unaware of what they expect the software to do. Core capabilities, as identified, are essential functionalities that management cannot abandon to successfully complete the project.
Absence of unresolved high-risk development issues – Software that is exploratory or high-risk might not be considered an asset and as such, development costs should not be capitalized for these projects.

The staff also suggested a comprehensive factor for all three criteria, emphasizing that the entity should assess these criteria in view of its past experiences, recognizing that the past isn’t always an indication of future success, but it should be considered.

Amortization would begin when both the software project is substantially complete, and the software is placed into service.

Subsequent Activities

Subsequent activities should only be capitalized when the activity adds new functionality to the software. All other subsequent activities that fall under the software project should be expensed as incurred.

Targeted Improvement Approach Proposed in March of 2024

In a meeting on Wednesday, March 20, 2024, the Board decided on a few specific amendments to be addressed in targeted improvements to ASC 985-20 and ASC 350-40. While there were 5 different amendments presented by the staff, the Board ultimately decided to move forward with two of the amendments within Subtopic 350-40.

“Specify that the costs of software that has unresolved high-risk development issues would be accounted for as R&D expenses in accordance with ASC 730-10.”
“Clarify the starting capitalization threshold for nonlinear software development, including:

Remove the requirement for an entity to evaluate the preliminary project stage and application development stage when determining the starting point for capitalization
Require that an entity consider significant unresolved development uncertainties if it is unclear that it is probable that a project will be completed and the software will be used to perform the function intended.”⁶

These amendments appear to have originated from insights derived from the single model approach, emphasizing the most important pieces of information. Specifically, unresolved-high risk development issues might not be considered an asset and should therefore be included in R&D, and the starting point for the capitalization threshold should be determined by a probable to complete threshold. The Board has not yet made decisions about existing and future disclosures to be included in ASC 350-40 and ASC 985-20, but changes to disclosures will be discussed.

Conclusion

Currently, the board is in deliberations, and consequently, none of the information presented thus far is finalized, with all aspects subject to change. The Board has opted to address the project by refining topics ASC 350-40 and ASC 985-20 rather than continuing to work on a new all-encompassing standard similar to the one proposed. As of March 2024, this project might lead to changes in the accounting treatment of software costs and necessary disclosures. However, the Board does not appear to be pursuing an approach that would drastically modify the capitalization of software costs.