FASB Proposes Modernized Guidance for Internal-Use Software: Implications for Statutory Accounting

What the FASB is proposing

The FASB has been exploring a modernization of software accounting rules to better align GAAP with current business practices. In March, the Board unanimously voted to advance a proposal addressing internally used but not licensed (i.e., sold, leased, or marketed) software, specifically focusing on the criteria for capitalizing related costs.

Currently, GAAP requires companies to capitalize software costs based on the project’s stage, which is divided into three phases: the preliminary project stage, the application development stage, and the post-implementation/operational stage. During the preliminary project stage, costs are expensed as incurred. Capitalization begins in the application development stage once management has committed to funding the project and the project is deemed probable to be completed. Once the software is ready for use, amortization is applied during the post-implementation/operational stage. However, this framework has created ambiguity, particularly with the rise of modern, iterative software development methodologies. These approaches blur the lines between project stages, making it less clear when capitalization should occur. This has led companies to try to apply this guidance based on the nature of costs incurred rather than the project stages themselves, as agile methodologies do not follow a sequential stage project path. The typical costs included in the second capitalized project stage were design of the chosen path, coding, installation of hardware, and testing. However, this approach is less precise and can create improper handling of these expenses. The proposed update aims to provide more straightforward guidance for companies navigating accounting for these modern development processes.

The new proposal would require an entity to start capitalizing when two criteria are met:

• Management has greenlighted the project and is committed to funding it.
• The project should be able to be completed and used for its intended purpose. This is referred to as the “probable-to-complete recognition threshold.”

These criteria should be familiar as they are included in the previous guidance as an accompaniment to the project stage guidelines. Essentially, FASB is proposing to do away with project stages when assessing the appropriate timing to capitalize internal-use software. For cash flow presentation, GAAP requires reporting capitalized disbursements (paid) for internal-use software separately within the investing cash flow section of the cash flow statement. This ensures transparency in reporting and provides stakeholders with a clearer picture of cash outflows related to software development. This proposal does not impact the ultimate outcome of capitalizing software costs but instead focuses on clarifying the process for determining when capitalization begins. The proposal aims to reduce uncertainty and align practices with contemporary software development methods by providing more precise criteria.

Statutory Impact

It is expected that the Statutory Accounting Principles Working Group (SAPWG) may adopt similar improvements to enhance clarity in accounting for internal-use software costs as it does not impact the conservativeness of the current approach.

The statutory approach is outlined in SSAP 16, where an entity is guided to capitalize and amortize software expenses over its estimated useful life. The standards for when to capitalize are currently tied to project stages and aligned with GAAP’s existing approach. However, SAP’s overall accounting treatment remains conservative, and non-operating software (which would likely include internal-use software) is considered non-admitted for SAP reporting purposes. Additionally, SSAP 16, paragraph 6, specifies that R&D costs are to be fully expensed, reinforcing the conservative nature of statutory accounting. Furthermore, statutory depreciation of software is subject to certain limitation ranges. Non-operating software, generally internal-use software, is to be depreciated over the lesser of its useful life or 5 years, per SSAP 16.

We will wait and see how the FASB proceeds as they continue with redeliberation.