FASB’s proposed updates on software development accounting

ARTICLE | December 03, 2024

As companies pour resources into developing software for internal use, the need for clear and relevant accounting guidance becomes paramount. Recognizing this, the Financial Accounting Standards Board (FASB) has proposed significant updates to how companies should account for software development costs. 

The current accounting standards for software development costs 

To appreciate the significance of the proposed changes, it's essential to understand the existing accounting standards. The current guidance, primarily outlined in Accounting Standards Codification (ASC) 350-40, was established over three decades ago. It was designed around the “waterfall” software development methodology, which is linear and sequential, with distinct phases.

The existing standards divide software development into three key stages:

1. Preliminary project stage: this phase involves activities like conceptual formulation, evaluation of alternatives, and final selection of the project. Costs incurred during this stage are expensed as incurred.
2. Application development stage: this stage includes designing the chosen path, coding, installation to hardware, and testing. Costs incurred during this phase are capitalized and amortized over the software's useful life.
3. Post-implementation/operation stage: activities in this final phase involve training, maintenance, and enhancements. Under current guidance, costs incurred during this stage are generally expensed as incurred. However, there’s some ambiguity regarding when to capitalize certain costs versus when to expense them. This ambiguity has been a point of contention and is one of the reasons for the proposed changes.

Challenges with the existing model

The current standards aren’t as compatible with modern development methodologies, like agile practices. Agile development is characterized by iterative and incremental processes where stages overlap and evolve continuously. This fluid approach makes it difficult to apply the rigid, stage-based model effectively, as delineated phases are less distinguishable. 

There’s also significant ambiguity in distinguishing between capitalizable enhancements and routine maintenance during the post-implementation/operation stage. The evolving nature of software necessitates continuous updates and improvements, blurring the lines between what constitutes an enhancement (which may be capitalized) and maintenance (which should be expensed). The current standards lack clear criteria for this differentiation, forcing companies to rely heavily on subjective judgment. This reliance on interpretation leads to inconsistencies in accounting practices across the industry, making it challenging for stakeholders to compare financial statements meaningfully. 

This ambiguity can also affect key metrics such as assets and expenses - which can potentially mislead stakeholders about a company’s financial position and performance. The difficulty in aligning the stage-based model with modern development practices not only contributes to inconsistent accounting treatments but also complicates financial reporting and analysis. 

Overview of FASB's proposed updates

Removal of references to project stages

One of the most significant changes is the elimination of references to specific project stages. By removing these stage-based references, the proposed guidance becomes more adaptable. Companies can apply the accounting standards regardless of whether they use agile, waterfall, or a hybrid development methodology. This change aims to reduce confusion and promote consistency in determining when to capitalize software costs.

New criteria for capitalization of software costs

Under the proposed updates, companies would begin capitalizing software development costs when two key criteria are met:

1. Management authorization and funding commitment: the project has received formal approval, and the company is committed to funding its completion.
2. Probable completion and intended use: it's probable that the software will be completed and used as intended.

This approach provides a clearer framework for capitalization that aligns with how businesses plan and execute software projects today. The proposed guidance also requires companies to assess any significant uncertainties that might affect the project's completion. For instance, if a business is developing software with novel or untested features, or there are ongoing substantial revisions to performance requirements, the costs will likely be expensed as incurred rather than capitalized. 

By factoring in these uncertainties, companies can make more informed decisions about when to capitalize costs, ensuring they only do so when the project is likely to result in a usable asset.

Impacts on cash flow statements

Reclassifying capitalized software costs

A notable change in the proposed updates is the requirement to classify cash payments for capitalized software costs as cash outflows from investing activities in the cash flow statement. This aligns software development costs with other capital expenditures like purchasing equipment or facilities. It reflects the investment nature of these costs, as companies expect the software to provide future economic benefits.

Previously, some companies might have included these costs under operating activities, leading to inconsistencies and potentially obscuring investment levels in software development.

Separate presentation of software costs

The proposed guidance also calls for presenting cash flows related to capitalized software costs separately from other investing activities. This separate disclosure enables stakeholders to see precisely how much is being invested in software development. For investors and analysts, this information is crucial for assessing a company's commitment to technological advancement.

What this means for your business

If these proposals become standards, companies will need to revisit their accounting policies related to software development. This might involve:

• Enhancing documentation: keeping detailed records of project approvals, funding commitments., and assessments of project probabilities.
• Assessing project probabilities: implementing processes to evaluate the likelihood of project completion and intended use, including regular reviews of project status and risks.
• Updating internal processes and systems: modifying accounting systems and internal controls to capture and report the necessary data under the new standards.
• Training accounting teams: ensuring staff understand the new criteria and how to apply them consistently. Extending training to development and project management teams to prompt cross-functional understanding.
• Considering tax implications: assessing the potential tax effects of changes in capitalization and consulting with tax professionals to plan accordingly.

Financial reporting and stakeholder communication

The changes in classification and presentation of software costs could affect key financial metrics and ratios, such as operating cash flows and return on investment calculations. Companies should prepare to communicate these impacts to stakeholders, explaining how the new accounting treatment provides a clearer picture of investment activities. Additionally, re-evaluating financial covenants and updating financial forecasts may be necessary to reflect the new accounting approach.

Aligning with development teams

The proposed updates offer an opportunity for better alignment between accounting and development teams. Understanding the accounting implications can influence project management practices, budgeting, and strategic decision-making. Collaborative efforts can ensure that both teams are on the same page regarding project statuses, capitalization criteria, and financial reporting.

Next steps

FASB is accepting feedback on the proposed updates until January 27, 2025. It's crucial for companies, especially those heavily invested in software development, to review the proposal and provide input. Your feedback can help shape the final standards, ensuring they are practical and beneficial for businesses and stakeholders alike.