A PDF of the below Comment Letter can be downloaded here »
Mr. Jackson M. Day
Technical Director
Financial Accounting Standards Board
801 Main Avenue, PO Box 5116
Norwalk, CT 06856-5116
Re: File Reference No. 2024-ED400
Dear Mr. Day,
This letter is submitted by Financial Executives International’s (FEI) Committee on Corporate Reporting (CCR) in response to the Financial Accounting Standards Board’s (FASB or Board) Proposed Accounting Standards Update—Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software (Exposure Draft or proposed Update).
FEI is a leading international organization comprised of members who hold positions as Chief Financial Officers, Chief Accounting Officers, Controllers, Treasurers, and Tax Executives at companies in every major industry. CCR is FEI’s technical committee of approximately 50 Chief Accounting Officers and Corporate Controllers from Fortune 100 and other large public companies, representing more than $16 trillion in market capitalization. CCR reviews and responds to pronouncements, proposed rules and regulations, pending legislation, and other documents issued by domestic and international regulators and organizations such as the U.S. SEC, PCAOB, FASB, and IASB.
This letter represents the views of CCR and not necessarily the views of FEI or its members individually.
Executive Summary
We commend the Board for taking steps to modernize Subtopic 350-40, which was primarily written to provide guidance at a time when software development largely followed a linear approach. CCR is supportive of the proposed amendments and believe they will improve operability and remain relevant regardless of software development methodologies used in the future. We also appreciate the Board’s responsiveness to stakeholder feedback throughout the standard-setting process. Specifically, CCR prefers the targeted improvements approach in the proposed Update, as we believe the single model contemplated by the Board to account for both internal-use and external-use software using a single capitalization threshold could result in a significant increase in capitalization for certain companies. This increase in capitalization, particularly for external-use software, could result in significant costs to track development costs and increase the risk of potential impairments. As a result, we believe the benefits of implementing a single capitalization threshold would not outweigh the costs.
In our letter, we offer broad support for the proposed amendments as we believe they improve operability while maintaining management’s ability to apply judgment based on each company’s unique software development process. Specifically, CCR strongly supports the proposed amendments to remove all references to project stages throughout Subtopic 350-40. In addition, while judgment will be required, we generally believe the probable-to-complete recognition threshold is clear and operable. However, we suggest the Board make three changes to improve operability:
- Remove references to the terms “project” and “computer” throughout Subtopic 350-40
- Amend the second factor of the probable-to-complete recognition threshold to better reflect the qualitative management judgment required to determine whether there is significant development uncertainty and include additional related language in the Basis for Conclusions
- Amend the definition of “performance requirements” to remove functions and features as examples and include additional related language in the Basis for Conclusions
CCR generally believes the proposed requirement to classify cash paid for capitalized software costs accounted for under Subtopic 350-40 as investing cash outflows in the statement of cash flows and to present those cash outflows separately from other investing cash outflows, such as those related to property, plant and equipment (PP&E), is operable. We also believe it would be operable to either separately disclose the total internal-use software costs capitalized during the period from total external-use software costs capitalized during the period (first alternative proposed by the Board) or disclose a single number for the total internal-use and external-use software costs capitalized during the period (new alternative suggested).
Most companies do not expect a significant change in the level of capitalization or significant one-time or recurring costs as a result of implementing the proposed Update. We believe the proposed transition methods are operable and strongly support the option to elect early adoption. We believe it would be beneficial to provide preparers between 18 and 24 months to implement after a final standard is issued.
Removal of Project Stages and the terms “Project” and “Computer”
CCR strongly supports the proposed amendments to remove all references to project stages throughout Subtopic 350-40. We believe the removal of project stages will improve operability and better align the guidance with iterative methods more commonly used to develop software today. In addition to removing references to project stages, we suggest the Board remove references to projects. If companies are not required to identify project stages during development, the use of the term “project” is unnecessary. Furthermore, companies currently use judgment to determine the unit of account when applying the requirements in Subtopic 350-40, and as discussed in paragraph BC25 of the Basis for Conclusions, the amendments in the proposed Update are not intended to impact how companies define the unit of account. That said, the proposed Update may cause certain companies to revisit judgments around determining the unit of account. Removing references to projects will improve operability and clarity in the same way as removing references to project stages, as companies utilizing iterative development methods may not commonly use the term “project” when defining the unit of account. For example, companies may define the unit of account as a single feature or function developed during a sprint. Where the term “project” is currently used in Subtopic 350-40, we believe the Board can either remove the term altogether or replace “project” with “development,” depending on the context.
In addition, consistent with the Board’s objective to modernize the guidance in Subtopic 350-40, we also suggest removing the term “computer” to describe software throughout the guidance. We believe this update will better align with how companies characterize software today. For example, costs to develop certain thin-client mobile applications (apps) are accounted for in accordance with Subtopic 350-40. Companies may not characterize mobile apps as computer software.
Refer to the Appendix for examples illustrating our suggestions.
Probable-to-Complete Recognition Threshold
While judgment will be required, we generally believe the probable-to-complete recognition threshold is clear and operable. Specifically, we believe the first factor that may indicate there is significant development uncertainty is operable as written: “the computer software has novel, unique, unproven functions and features or technological innovations.” As this language is derived from Subtopic 985-20, we believe companies already have processes in place to make similar judgments. In addition, making changes to this language could have unintended consequences on the accounting for external-use software accounted for under Subtopic 985-20. However, when considering the second factor – “the significant performance requirements of the computer software have not been identified, or the significant performance requirements continue to be substantially revised” – we have two suggestions to improve operability.
Amend the Second Factor of the Probable-to-Complete Recognition Threshold and Include Additional Language in the Basis for Conclusions
First, we believe the second factor that may indicate there is significant development uncertainty should be amended as follows:
“The significant key performance requirements of the computersoftware have not been identified, or the entity expects the significant key performance requirements to continue to be substantially revised.”
We appreciate the Board including this factor to improve the operability of the guidance by acknowledging that an entity may develop software using a nonlinear method and may revise performance requirements throughout the period. However, we think the suggested amendments above better reflect the qualitative management judgment required to determine whether there is significant development uncertainty based on the performance requirements identified on a given date.
Specifically, we believe the term “key” is more appropriate as the guidance requires management to assess operational business requirements, as opposed to quantifiable financial information. In addition, the use of the term “key” in this instance would be consistent with the use of the term “key” in other similar areas of GAAP that require qualitative management assessments. For example, Topic 718, Compensation – Stock Compensation requires companies to determine the grant date of a share-based payment award. The grant date is defined as “the date at which a grantor and a grantee reach a mutual understanding of the key terms and conditions of a share-based payment award.” We believe the qualitative assessment to identify the key performance requirements in software development is similar to the qualitative assessments to identify the key terms and conditions of a share-based payment award. Furthermore, we believe it would be beneficial for the Board to include language in the Basis for Conclusions that further emphasizes that the assessment of the second factor is based on qualitative management judgment. Refer to the Appendix for example proposed language.
Amend the Definition of Performance Requirements to Remove Functions and Features as Examples and Include Additional Language in the Basis for Conclusions
Next, we believe the definition of performance requirements should be amended to remove references to the terms “features” and “functions.” As proposed, performance requirements are defined as “what an entity needs the software to do (for example, functions or features).” The terms “functions” and “features” may be used by software development teams in different ways, and as discussed above, companies may define the unit of account when applying Subtopic 350-40 as a single feature or function developed during a sprint. In addition, Subtopic 985-20 uses “functions,” “features,” and “performance requirements” as distinct terms (not synonyms). As a result, defining performance requirements in reference to features or functions may be confusing for companies who define the unit of account as a single feature or function. In addition to removing the terms “features and functions,” we believe the Board should clarify in the Basis for Conclusions that the identification of performance requirements requires judgment and may be impacted by how an entity identifies the unit of account in applying Subtopic 350-40. Refer to the Appendix for example proposed language.
Presentation and Disclosure
Cash Flow Presentation
CCR generally agrees that cash paid for capitalized internal-use software should be classified as an investing cash outflow, consistent with the proposed Update. We believe developing software for internal use is an investing activity as companies develop or acquire software that is a productive asset, similar to PP&E and consistent with the definition of “investing activities” in the Master Glossary. On the other hand, fees for hosting arrangements that represent service contracts are classified as operating cash outflows because companies are not paying for a productive asset, but rather paying for a service to operate their businesses.
We do not believe it is necessary for the Board to amend the guidance to change the current classification of costs incurred to implement a hosting arrangement from operating cash outflows to investing cash outflows to be consistent with the classification of other capitalized internal-use software costs in accordance with the proposed Update for several reasons. First, the cash flow presentation for costs to implement a hosting arrangement should be the same as the related fees because the implementation cost asset is recognized only as a result of enhancing the associated hosting service. Therefore, the underlying nature of the implementation costs are different than other internal-use software costs capitalized under Subtopic 350-40. Second, Subtopic 350-40 requires companies to present the amortization of capitalized implementation costs related to a hosting arrangement in the same income statement line item as the expense for fees for the associated hosting arrangement and to present the capitalized implementation costs in the same balance sheet line item that a prepayment of the hosting fees would be presented. As a result, it would be inconsistent to require different cash flow presentations for the hosting fees and the related implementation costs.
Operability of Disclosure Alternatives
Most CCR companies generally believe the proposed requirement to classify cash paid for capitalized software costs accounted for under Subtopic 350-40 as an investing cash outflow in the statement of cash flows separately from other investing cash outflows is operable. As most companies already track this information, we do not anticipate a need for significant system or process updates at most companies. However, when a portion of compensation capitalized is non-cash (e.g., stock-based compensation), the amount presented as cash paid for software costs accounted for under Subtopic 350-40 may have limited usefulness to investors. These situations are also expected to pose operability challenges for certain companies and require those companies to perform estimates and allocations (including the use of a standard capitalization rate in certain cases) to determine the cash paid for compensation related to software development. As a result, if the Board ultimately decides to adopt the presentation requirement as proposed, we suggest the Board include language in the Basis for Conclusions that acknowledges that estimates and allocations are appropriate when determining cash paid for capitalized software costs accounted for under Subtopic 350-40 – similar to the language included in the final Disaggregation of Income Statement Expenses (DISE) standard.
We believe the first alternative contemplated by the Board, which would have required companies to separately disclose the total internal-use software costs capitalized during the period from total external-use software costs capitalized during the period would also be operable. While some companies already disclose a single number for the total internal-use and external-use software costs capitalized during the period, some companies would need to complete additional work to separate internal-use software costs capitalized from external-use software costs capitalized.
While generally operable, we believe the second alternative contemplated by the Board, which would have required companies to provide a rollforward of the beginning to ending balance of net capitalized software costs (including additions, amortization, impairments, and disposals), could be significantly more costly for some companies to prepare than the proposed cash flow presentation. The requirement to disclose additional amounts would require companies to implement additional processes and controls around each amount disclosed, and certain companies would potentially need to make systems updates or manually collect the data required for the rollforward.
As a result, CCR would prefer the Board require companies to (a) classify cash paid for capitalized software costs accounted for under Subtopic 350-40 as investing cash outflows in the statement of cash flows separately from other investing cash outflows (as proposed), or (b) separately disclose the total internal-use software costs capitalized during the period from total external-use software costs capitalized during the period (first alternative proposed), or (c) disclose a single number for the total internal-use and external-use software costs capitalized during the period (new alternative suggested). CCR companies have differing preferences among these three options.
Website Development Costs
We support the proposed amendments to supersede the guidance in Subtopic 350-50 and incorporate the relevant website-specific development costs guidance into Subtopic 350-40. We believe the nature of website development costs are generally similar to the development of other types of internal-use software. We prefer the view selected by the Board and do not anticipate any significant changes in practice or operability concerns based on the proposed amendments.
Impact on Current Practice and Implementation Costs
Most companies do not expect a significant change in the level of capitalization as a result of implementing the proposed Update. However, certain companies expect a decrease in the level of capitalization primarily related to potential interpretations of the indicators in the probable-to-complete threshold. We believe this is generally consistent with the Board’s expectations and objective to modernize the guidance to better align with current software development practices. Other companies expect an increase in the level of capitalization.
CCR companies generally do not expect to incur significant one-time or recurring implementation costs, consistent with our expectation that, for most companies, the level of capitalization will remain the same post-implementation of the proposed Update. While most companies did not identify a need for large-scale system updates to implement the proposed amendments, companies expect to incur one-time costs to educate finance and accounting professionals on the new requirements, make changes to policies, processes, qualitative disclosures, and internal controls, and potentially gather additional data for disclosure. For example, companies will need to develop a framework and policy to assess the probable-to-complete recognition threshold. Companies will also incur additional audit fees related to the auditor’s review of the implementation. We do not anticipate an increase or decrease in recurring costs.
As discussed above, we generally believe the proposed amendments will improve the operability of the guidance in Subtopic 350-40 and better align the accounting with iterative software development approaches used today. Therefore, we believe the benefits outweigh the costs to implement.
Effective Date and Transition
We support allowing entities the option to apply the amendments in the proposed Update either prospectively to all software costs incurred after the effective date (including costs incurred after the effective date for in-process projects) or retrospectively through a cumulative-effect adjustment to the opening balance of retained earnings. CCR also strongly agrees that companies should have the option to elect early adoption.
We believe it would be beneficial to provide preparers between 18 and 24 months to implement after a final standard is issued. As discussed above, while most companies did not identify a need for large-scale system updates to implement the proposed amendments, companies will need time to educate finance and accounting professionals on the new requirements, assess the new guidance and document conclusions, make changes to policies, processes, and internal controls, and potentially gather additional data for disclosure. For example, companies will need to develop a framework and policy to assess the probable-to-complete recognition threshold. Additional time is also needed given the expected concurrent implementation of other standards. We would specifically request the Board not align the effective date of this proposed Update with the effective date of the final DISE standard, which will require significant time to implement.
Conclusion
We appreciate this opportunity to provide feedback on the proposed Update related to the accounting for internal-use software. We thank the Board for its consideration of our comments and welcome further discussion with the Board or staff at your convenience.
Sincerely,
Alice L. Jolla
Chair, Committee on Corporate Reporting
Financial Executives International