Reporting Guidance Changes Ahead

The Financial Accounting Standards Board (FASB), which sets U.S. Generally Accepted Accounting Principles (GAAP), is revisiting existing guidance on accounting for software development costs. There are several reasons the board is undertaking this project. First, there’s a concern that current accounting results in confusing information for investors. Additionally, there have been significant changes to the way companies develop software since the original guidance was issued.

Consider the diversity of software development projects today. In order to attract and retain clients, financial ser­vices companies are building and offering customers access to platforms that pull data from their transactional systems. These customer-facing applications are improved regularly with new features, such as access to external data from banks and investment funds. 

Car and heavy equipment manufacturers are building systems that track end customer interactions from the date of purchase, through maintenance over ownership years, to the end customer’s next purchase along with trade-in or resale. The application may allow end customers to update their personal data, report service dates, or indicate interest in a new car. While these applications may be free to outside users, aspects of the systems may become fee-based for specific user groups (such as dealers) as new functionality capabilities are developed.

WATERFALL DEVELOPMENT MODEL

The current accounting guidance, for the most part, was developed based on a waterfall development model that assumes software development through a linear process that begins with planning and design, moves to coding and development, and reaches readiness for use. But while some development projects today still follow this method, processes have largely moved to an agile approach that sets shorter sprints toward an eventual goal of delivering a product to users. 

In each shorter sprint, the process and progress are reassessed. Information learned during one sprint informs the direction of the next sprints. While some development points appear directly related to an ultimate product, blunders along the way benefit an ultimate delivery. In short, these new agile methods don’t have a clear delineation between development phases.

NEW METHODS AND THEIR CHALLENGES

These newer methods of development create accounting challenges. Reporting teams must interpret the existing guidance to apply it to modernized processes. They also need to communicate with their technology teams so the appropriate data, including time allocation, is gathered to account for costs.

Today, there are two sets of guidelines for software development costs. First, FASB Accounting Standards Codification (ASC) Subtopic 985-20, Software—Costs of Software to Be Sold, Leased, or Marketed, originally issued in the mid-1980s, applies if an entity is developing software that it plans to market to external users. Like the waterfall approach, the entity accounts for the earliest parts of projects as research and development until a point called “technological feasibility” is reached. Then, it capitalizes the costs of bringing the developed prototype to market. But this guidance is inapplicable to many present-day Software as a Service (SaaS) arrangements for which the accounting depends on whether the customer takes possession or runs the underlying software.  The key benefit of SaaS arrangements is that users don’t need the underlying infrastructure for the application.

The second set of guidance is ASC Subtopic 350-40, Intangibles—Goodwill and Other—Internal-Use Software, which applies if the entity isn’t planning to sell the software but use it for its own purposes. This accounting results in a similar outcome to an entity’s accounting for other fixed assets. Once the application costs are capitalized, the entity generally follows a depreciation method that’s similar to the accounting for facilities, equipment, and vehicles.

NEW MODELS

During the FASB’s 2021 agenda consultation process, stakeholders urged the FASB to add an agenda project to address the issues. Some users find this accounting, which rests on assumptions about eventual use and separate phases of development, challenging to follow and understand. 

After formally adding the project to its technical agenda in mid-2022, the FASB has been conducting research to consider a new model. Through feedback from various preparers and users, the FASB is now focusing on two alternative approaches:

1. Initial development cost model: As currently sketched, the initial development cost model would require the capitalization of all software development costs beginning when it becomes probable that a project will be completed and deliver functioning software. 

2. Dual model: This proposal would require immediate expense of certain types of software costs, while other costs would follow the initial development cost model. The FASB is still considering the applicability of this model and the criteria that would differentiate between costs that are expensed vs. costs that are capitalized. One view of the dual model would segregate these expenditures based on whether the software will be commercialized. An alternative set of criteria would distinguish expenditures based on whether the planned software is internal facing or external facing.

Some observe that the initial development cost model, while replacing “technological feasibility” with “probable,” appears close to the current model. Other critiques question whether the proposed improvements, particularly the dual model, would continue the complexity of characterizing software costs based on assumptions that, in practice, may be challenging to differentiate—and may change during agile development or an ongoing improvement process.