FASB Proposes Internal-Use Software Accounting Changes

In under a minute

• On Oct. 29, 2024, the Financial Accounting Standards Board (FASB) issued a proposed Accounting Standards Update, “Intangibles – Goodwill and Other – Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software.”
• Recognizing the prevalence of nonlinear software development models (for example, agile development), the proposed amendments would replace the current project-stage-based framework with a principles-based approach, under which entities would capitalize internal-use software costs incurred after 1) management has authorized and committed to funding the project, and 2) the “probable-to-complete” threshold is met.
• The proposal includes a requirement to separately present cash paid to develop internal-use software that qualifies for capitalization within the investing cash flows section of the statement of cash flows.
• The proposal also would eliminate current guidance specific to website development costs and incorporate accounting for these costs within Subtopic 350-40.
• Importantly, the FASB expects more software development costs could be expensed as incurred under the proposed framework for cloud computing arrangements (CCAs) and software as a service (SaaS) arrangements. This could increase consistency with costs incurred to develop external-use software accounted for under Subtopic 985-20, under which fewer costs are typically capitalized.
• Comments on the proposal are due Jan. 27, 2025.

Subscribe to "Take Into Account" knowledge hub

Current accounting guidance for internal-use software costs centers around a project-stage-based framework that outlines three stages – preliminary, application development, and postimplementation – reflecting the former prevalence of a sequential “waterfall” software development methodology. In this framework, only costs incurred in the application development stage and enhancement costs incurred in the postimplementation stage are eligible for capitalization.

Stakeholders have criticized this stage-based framework, noting that it often does not reflect the reality of today’s dynamic and iterative software development environment. The prevalence of the agile development model (and similar nonlinear methodologies) often means developers do not follow a stage-based timeline. Because of this, entities might encounter difficulties determining which stage they are in and, consequently, which costs can be capitalized.

The FASB’s proposal aims to address these concerns by replacing the project-stage-based framework with a clarified capitalization threshold. Under the proposal, an entity would begin to capitalize internal-use software costs when management has authorized and committed to funding a project and when the “probable-to-complete” threshold is met.

Capitalization threshold

Under the proposed framework, an entity would begin to capitalize internal-use software development costs when both of the following conditions are met:

Management approval

Management approval as a condition to begin capitalizing costs would remain relatively unchanged from current guidance. Examples of indicators that management has authorized and committed to funding a project include approving a budget or other funding plan, executing a contract with a third party to implement and customize a system, or allocating an internal development team or other resources.

Probable-to-complete threshold

Under the proposal, the probable-to-complete threshold would not be met if there is “significant uncertainty associated with the development activities of the software.” The proposal states that the following factors may indicate that there is significant development uncertainty, and the probable-to-complete threshold has not been met:

Put differently, significant uncertainty could exist if management has not yet finalized the substantive performance requirements of the software, or if management is unsure whether the performance requirements will be feasible because they have not yet been achieved in practice. If significant development uncertainty is present, the entity cannot begin to capitalize development costs.

Novel or unproven software. The proposed amendments regarding significant development uncertainty align the language in Subtopic 350-40 with similar language in Subtopic 985-20 that calls for an entity to consider whether the software development involves “novel, unique, unproven functions and features or technological innovations.”

Significant performance requirements. The amendments define performance requirements as “what an entity needs the software to do (for example, functions or features).” In paragraph 35 of its Basis for Conclusions (BC35), the board acknowledged that an entity using a nonlinear methodology may continue to “revise the significant performance requirements throughout the project.” However, continued revision of performance requirements does not necessarily preclude an entity from beginning to capitalize development costs, depending on the nature of the revised requirements and the nature of the revisions. The board observed that “the proposed amendments would not require an entity to identify and cease revising all of the software’s performance requirements before it begins to capitalize its software development costs but, rather, to identify only those performance requirements that are significant and/or are significant and continue to be substantially revised.”

Management is often required to use judgment in determining the appropriate unit of account for an acquired asset that includes both software and tangible asset components. While the proposed amendments do not prescribe a specific assessment, they require an entity to use a “reasonable and consistent” method when assessing such assets. This method would include both how an entity determines the unit of account and whether the software component should be accounted for separately under Subtopic 350-40 or together with the tangible component under other GAAP. The board noted in BC37 that it does not expect that the proposal would “change how an entity determines whether software that is developed would be accounted for as software or as part of another asset.”

The proposal would require entities to separately classify cash outflows capitalized for internal-use software development (other than the implementation costs of a hosting arrangement that is a service contract, which generally are classified as operating cash flows under paragraph 350-40-45-3) in the statement of cash flows. Specifically, these cash flows would be classified as cash outflows from investing activities and would be presented separately from other investing cash outflows.

Guidance within Subtopic 350-50, which currently prescribes the appropriate accounting for website development costs, is also project stage-based and contains some stand-alone guidance as well as several references to the current Subtopic 350-40. The proposal would eliminate Subtopic 350-50 and subsume accounting for such costs – including some website-specific guidance – into Subtopic 350-40.

In BC72, the FASB noted stakeholder feedback indicating that website-specific guidance is not frequently applied or that any costs separately accounted for under Subtopic 350-50 are often immaterial. Therefore, this amendment is not expected to lead to a significant change in practice.

Entities would be allowed to apply the amended guidance prospectively or retrospectively. The board will consider stakeholder feedback in determining whether early adoption will be permitted. Comments on the proposal are due Jan. 27, 2025.

FASB materials reprinted with permission. Copyright 2024 by Financial Accounting Foundation, Norwalk, Connecticut. Copyright 1974-1980 by American Institute of Certified Public Accountants.