FASB’s project on updating guidance on software development costs is slowly moving forward, but the ultimate outcome is still uncertain. Staff performed extensive additional research after reviewing sharply divided stakeholder feedback. On September 20, 2023, FASB met to provide direction on a potential path forward on the capitalization threshold, unit of account, and subsequent measurement issues. This article provides details on FASB’s parallel path forward.
- Single model
- Targeted improvements to existing guidance in Accounting Standards Codification (ASC) 350 to better accommodate agile development
Due to the required additional research on this new second approach and open issues on the single model approach (subsequent measurement, disclosures, and cost-benefit analysis), an exposure draft is not expected until 2024. Read on for full details.
Project Background
FASB included software costs as a research agenda item in December 2021 as part of a bigger project on intangible assets. To address SEC and investor requests for quicker standard setting, software was broken out as a standalone project in June 2022. Staff researched two possible approaches:
- Initial development cost model. Entities would be required to capitalize all direct software costs from the point at which it is probable that the software project will be completed and the software will be used to perform the function intended.
- Dual model. This would require an entity to account for certain software costs as an expense as incurred model and other software costs under the initial development cost model.
At an April 2023 meeting, FASB decided to focus on a single model, the initial development cost model. The dual model received support from some preparers, including software companies that would prefer to continue to expense all their software costs and non-software companies that would like to continue their current capitalization policies. Most practitioners and preparers strongly opposed a dual model, citing cost and complexity. Due to the evolving nature of software rollout, most notably agile development, it is challenging for practitioners to determine which model to use. Preparers from non-software companies and most practitioners said a single model would be operable. However, software companies who participated in the outreach did not support the single model because too many research and development-type costs that are currently expensed would be capitalized as incurred.
Current Accounting Guidance
| Software Cost - Current Guidance | |
|---|---|
| ASC 350-40 | ASC 985-20 |
| Cost incurred to develop or purchase software that is solely for the entity’s internal use | Cost incurred to develop software to be sold or licensed to customers |
| Cost to develop a hosting arrangement platform | Cost incurred to develop software used in a hosting arrangement in which the customer can take possession |
| Costs incurred by a customer to implement a cloud computing arrangement | |
See additional accounting guidance details in the Appendix.
Single Model Directional Path Forward
FASB voted between potential alternatives, and the conclusions are highlighted below. These are high-level directions and will need substantial flushing out, including editing, clarifications, and illustrative examples before an exposure draft is ready for ratification into the new standard.
Starting Capitalization Threshold
There would be a defined point at which capitalization begins—when the software project is probable to be completed. Required criteria to be met to support that the software project is probable of being completed:
- Management, with relevant authority, has committed to completing the software project.
- The company has identified the core capabilities that will be included in the software, and the company does not expect those core capabilities to be abandoned. The ability to add capabilities would not preclude this criterion from being met. “Core capabilities” would be a new term in GAAP, and additional work is needed to define this new concept.
- The software being developed does not have unresolved high-risk development issues, e.g., software that is novel or exploratory.
An entity also would need to consider its past experience with similar types of software when evaluating each criterion. Cost recoverability would not be a criterion for recognition.
Unit of Account
Determining the unit of account is a significant decision for starting and ending capitalization. FASB members agreed that a software project may consist of one or more activities that together will achieve an overall objective. Determining what constitutes a software project is a matter of judgment and depends on individual facts and circumstances and incorporating all available evidence. In determining the unit of account, a company would consider how management commits to development activities, how the company identifies core capabilities, and how the company anticipates deploying the software to end users. A company’s method for determining what constitutes a software project would be consistently applied for software developed under similar facts and circumstances.
Subsequent Activities
Sometimes, it may not be clear if subsequent activities are a new software project under the unit of account definition. Rather than rolling forward the existing “maintenance/enhancement” guidance, FASB voted that only significant subsequent activities that add new functionality could be subject to capitalization. All other costs would be expensed as incurred as a residual. FASB concluded that “significant” is widely used in GAAP and should be understood by financial statement preparers.
Targeted Improvements to ASC 350-40?
Several board members noted that the resultant proposal following the above framework may still not pass the cost-benefit analysis needed for ratification. Because of this uncertainty, Chair Richard Jones offered to add a concurrent path with targeted improvements to the existing guidance in ASC 350-40, potentially addressing some stakeholder concerns.
Initial feedback noted that with the evolution to agile technology development, the current internal model in ASC 350-40 is outdated. Tech companies are relying on non-authoritative GAAP literature to justify the expensing of most software development costs. Investors primarily wanted better disclosure and transparency on development costs; they did not indicate a preference for a different accounting outcome. The decisions reached above for a single model would not be tied to the type of information that investors sought. Rather than solely pursuing the path above and possibly failing to reach a consensus for an exposure draft, the board voted also to pursue, concurrently, retaining a dual model and researching limited, targeted improvement to ASC 350-40 to incorporate into GAAP literature the non-authoritative guidance technology firms are currently relying on. This approach would retain current accounting outcomes. Additional disclosure would be considered to meet investor requests and will require additional extensive investor outreach.
Conclusion
All FASB decisions are tentative and are subject to change until a final accounting standards update is issued. Substantial additional research and stakeholder feedback will be required to move forward on this dual path. Any proposal is unlikely before 2024. FORVIS will continue to follow this project.
Contact our team to learn how we assist software and technology companies with accounting for their software development costs. If you have any questions or need assistance, please reach out to a professional at FORVIS or use the Contact Us form below.
Appendix – Current Accounting Guidance for Software Costs
ASC 350-40 Intangibles – Goodwill and Other – Internal-Use Software
ASC 985-20 Software – Costs of Software to Be Sold, Leased, or Marketed
