The FASB fields feedback and works to keep pace with agile software development and other dynamic forces.
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 services 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.