Accounting for external-use software development costs in an agile environment

Failure to take this initial action could make it difficult to correctly separate costs between those that should be capitalized and those that should be expensed. This could lead to errors in the application of GAAP as well as errors in the amount of net income or loss entities report. This article is designed to help readers answer this question: Which software costs should be capitalized and which costs should be expensed when an entity builds external-use software using an agile development environment?

The trend toward agile development

The software development method known as agile has become popular in the software industry in recent years. Because the agile approach (see the “Agile Approach” chart) is widely perceived to be faster and more responsive to rapidly changing requirements, many companies now use it as a preferred alternative to the traditional waterfall development approach.

The conventional waterfall development approach involves organizing a project into a series of traditional phases, such as conception, initiation, analysis, design, construction, testing, production and implementation, and maintenance. These phases are marked by activities, which the guidance uses as a framework to make a conclusion on when technological feasibility is achieved and software development project costs can be capitalized.

Under an agile model, on the other hand, a project is organized into separate modules, and the development and testing work on these modules is done in short sprints. Identifying when the traditional activities of the waterfall approach occur requires significant analysis and judgment in agile development, which can make it more difficult to apply GAAP guidance for capitalizing expenses.

Ultimately, both the agile and waterfall models can produce a successful project; however, determining the point in the software development process to begin and end capitalizing costs can be more challenging with the agile model.

2 sets of software capitalization rules

As a starting point to appropriately capitalize software development costs, it is important to determine the proper guidance. Under U.S. GAAP, two potential sets of major rules may apply when determining whether software development costs should be capitalized or expensed.

One set of rules (FASB Accounting Standards Codification (ASC) Topic 985, Software) is designed for software costs that the entity intends to sell or lease. These rules, commonly referred to as the software capitalization rules for external-use software, are the primary focus of this article. The other set of rules (ASC Topic 350, Intangibles – Goodwill and Other) governs software that the entity does not intend to sell or lease. These rules commonly are referred to as the software capitalization rules for internal-use software.

It is important to note that the threshold for capitalization is lower for internal-use software. Under the internal-use software rules, development costs generally can be capitalized after the end of the preliminary project stage. The threshold for software development costs for external sale or licensing – the focus of this article – is more stringent, which means more analysis is required to determine which development costs should be capitalized.

Where GAAP and agile don’t align

Under Topic 985, the critical issue in determining whether external-use software development costs should be capitalized revolves around the term “technological feasibility.” Any software development costs that are incurred prior to the point where the project has demonstrated technological feasibility should be expensed as they are incurred.

Once technological feasibility has been established, most (but not all) development costs can be capitalized. Finally, once development is complete and the software is made available for release to customers, capitalization no longer is appropriate because any remaining costs are considered ongoing maintenance and support. These costs always must be expensed as they are incurred.

The definition of “technological feasibility” is therefore the critical factor in determining when a company should begin capitalizing its development costs. Topic 985 says, “the technological feasibility of a computer software product is established when the entity has completed all planning, designing, coding, and testing activities that are necessary to establish that the product can be produced to meet its design specifications including functions, features, and technical performance requirements.” It is also important to note that software development costs are subject to these rules regardless of whether the costs were generated internally (such as employee time) or externally (such as vendor fees).

In conventional software development projects with well-defined, consecutive phases, technological feasibility generally is demonstrated through either a detailed program design or, when a detailed program design is absent, a working model that is ready for customer testing. These are familiar milestones for projects using the waterfall approach.

In an agile project environment, however, individual functions and features are developed separately in a series of sprints. Each sprint or module is envisioned, planned, funded, developed, and tested individually to be incorporated into the overall project when ready.

In such an environment, comprehensive program designs or working models often are impractical or irrelevant. Companies using an agile approach to develop software might conclude inappropriately that technological feasibility has not been met significantly before the software enhancement is available to customers, resulting in costs being expensed as incurred rather than being capitalized. If significant costs accrue between when technological feasibility actually was reached and when the software is available to customers, the resulting accounting could be inconsistent with GAAP.

Applying GAAP in an agile environment

Although current GAAP guidance for external-use software is not tailored to the agile environment, that does not mean that agile development costs cannot be capitalized at all. There are, after all, varying levels of agility. While a pure agile project might begin with just an idea and relatively little design work, some agile projects do have detailed program designs with in-depth storyboarding, market acceptance studies, and other design work documents put together before actual development begins. Such documents could be used to help assess technological feasibility.

The critical point to remember is that in order to assess the costs that should be capitalized, there needs to be sufficient project planning to demonstrate that the criteria for a “detailed program design” have been met. The risk is that project teams may not do enough front-end planning or retain adequate documentation to demonstrate they have met this threshold. Demonstrating technological feasibility is likely to require the project team to do more planning and compile more documentation than is typical in most agile projects.

Other important considerations when determining technological feasibility relate to high-risk development features. For example, is the project a completely new software platform, or is it an enhancement or re-creation of something that has been done before? Is the company developing software from the ground up, or is it piecing together various software components that already exist? High-risk development features may require additional analysis of when technological feasibility is reached and, in some cases, expensing of previously capitalized costs.

Product enhancements that are not considered maintenance activities sometimes can meet the technological feasibility threshold more easily because the developers are adding functions to an already successful product. Deciding factors in such instances include the type of software, the level of modification required, and the level of design work that was completed before the start of development.

Even when technological feasibility is established, not all agile development costs can be capitalized. In most cases, only some of the costs in each sprint can be capitalized. The costs that should not be capitalized include upfront analysis, knowledge acquisition, initial project planning, prototyping, and comparable design work that must be done to achieve an understanding of the product’s desired features and feasibility.

But large portions of the costs incurred to develop and test such features often should be capitalized if technological feasibility is achieved. These costs include the actual coding, testing, and associated labor costs.

Bear in mind, however, that any maintenance-related or error-correction costs that are incurred during the sprint may need to be expensed rather than capitalized, as many activities during the sprint may not be coding and testing but may be activities such as troubleshooting and discovery. Moreover, capitalization ends once the project is complete and the software is ready for use.

Distinguishing between costs that can be capitalized and those that cannot be capitalized can complicate the project accounting, reporting, and documentation steps within each sprint somewhat. But the additional administrative work does not have to be onerous. In most cases the various tasks and deliverables within each sprint can be segmented into broad categories, so that all costs associated with that task can be either expensed or capitalized.

Preparation and communication: The critical steps

Deciding which external-use software development costs can be capitalized in an agile project environment involves a certain amount of judgment. In many cases, the specific facts and circumstances surrounding the type of software being developed will drive the treatment of costs. Careful planning can aid in the analysis of which costs to capitalize versus expense.

For this reason, it usually is advisable to discuss the accounting treatment with the project management team and subject-matter experts before starting any large development project. It also is important to understand from the outset of a project the level of support and documentation that will be needed to enable the appropriate decisions regarding capitalization of costs. In addition, a clear understanding is required of the level of documentation that will need to be maintained for auditors to evaluate and affirm the capitalization and expensing decisions.

For example, the project team should thoroughly document each person’s role in the project so that accounting can distinguish between those individuals whose time and activities could potentially be subject to capitalization and those whose activities would never fall into this category. It also is important to maintain additional internal controls such as monthly reviews of activities, capitalized and expensed amounts, and communication templates that project managers can fill out to verify that employee time is coded correctly.

Although some industry discussion of updating the relevant standards to make them more applicable to the agile framework has occurred, such updates typically entail several years of planning, discussion, proposals, and industry feedback. That means that, for the foreseeable future, companies that use an agile model to develop software for external sale or licensing will need to continue coordinating closely with their accounting teams to apply the existing GAAP guidance and capitalize development costs appropriately.

– Ryan Bouray is an audit manager and Glenn Richards is a partner in audit services, both for Crowe Horwath LLP. To comment on this article or to suggest an idea for another article, contact Ken Tysiac, a JofA editorial director, at Kenneth.Tysiac@aicpa-cima.com.