Software capitalization

Agile development techniques

To understand the issues associated with agile development, consider that the accounting standard for software capitalization was written for the way organizations historically developed software. Older, so-called waterfall development methods were linear. They had clear delineations between phases, from up-front planning to release and ongoing maintenance, which internal accounting policies and systems could readily reflect.

Then companies shifted to more agile methods of software development. Agile development teams are organized by product and task rather than by overall project. In addition, the teams themselves can be highly fluid, with people often staying only as long as their skills are required. These and other process innovations help software developers produce functionality in a faster, nimbler way.

But the same processes that make agile development teams more efficient can also make it harder to identify costs for capitalization. More specifically, because agile efforts are fluid, it can be difficult to differentiate development from planning and maintenance since agile teams often go through all three phases very quickly during a sprint. Further, it can be difficult to identify sprints that include efforts that qualify for capitalization.

It helps if an entire product team is dedicated to application development. However, if the product team or scrum is multidisciplinary (not unusual in the world of agile), the accounting team should learn what individual team members customarily do, then allocate the costs accordingly (say, by capitalizing a percentage of the team’s cost during a specific time frame).

And then there’s story abandonment. One of the criteria to capitalize costs is that management has approved the project and the funds have been committed to complete development. But if the organization has a history of abandoning sprints or stories before releasing them into production, it calls into question whether those costs are really for development and therefore eligible to be capitalized at all.

Organizations can also hit a snag when determining costs related to identified enhancements. When an agile team develops functionality into production, they may or may not have created a new asset that the organization should start amortizing. It depends on whether the team intends to build on their work in a subsequent sprint. If the new asset really is complete, that means other costs may have to be abandoned or impaired, and it’s not always clear which costs get what kind of treatment. All of this can make it hard to properly identify and capitalize costs in an agile environment.

Cloud delivery models

The shift to cloud delivery models means companies are developing software to provide a service versus software to be marketed or sold as a product (like a traditional software license sold as an on-premises solution).

The distinction is important because software capitalization requirements are different between the two. For software that the organization aims to sell or market, most (if not all) of the development cost is expensed as incurred. For software that the organization will deliver as a service, on the other hand, much of the development cost will likely have to be capitalized. Although these guidelines seem straightforward enough, the timing of a shift from on-premises to cloud delivery may not always be clear.

The accounting gets especially complicated when the organization delivers software through a hybrid of cloud and on-premises infrastructure. This is because an entity will need to identify development activities that are dedicated to the cloud environment, which may need to be accounted for differently from the activities that enhance the on-premises technology. On top of that, the accounting team may lack visibility into a few vital pieces of information needed to properly identify and account for development costs. One of those pieces is when functionality is no longer available for on-premises deployment (which could be the case when new functionality is only available in the cloud). Another is which planning, application development, and maintenance costs are unique to the cloud functionality and which costs relate to on-premises functionality.

A common language between finance and IT

The takeaway is that cloud delivery models and agile development techniques each have unique accounting considerations and impacts. Together, they can significantly increase process complexity for the organizations that adopt them.

So where can finance, accounting, and IT leaders go from here? Start by taking the following steps:

• Understand what information the development team produces, and to what level of detail.
• Compare the development team’s information with the information necessary to appropriately account for the organization’s technology spend.
• Collaborate with developers to identify starting and stopping points for stories, epics, or other units of account consistent with their development discipline (see sidebar).
• Close the information gap in a way that’s meaningful to both development and accounting (such as tagging the activities and creating a process to extract the tags for determining costs eligible for capitalization).
• Evaluate the utility of the information in making decisions about technology spend, and work with stakeholders to close any gaps there.

Cloud computing and agile development lie at the heart of many digital transformation efforts, offering organizations speed and flexibility alongside the potential for continuous innovation. The flipside is that they can also make the accounting for software development costs significantly more complex. By working together, IT and finance can craft a common language that brings insight and control to the application development phase of a product development life cycle

This article touches on the broader challenges of capitalizing software in an agile or cloud environment. However, every organization has its own complexities to consider. With help from Deloitte, you can create an approach that’s effective and practical for both accounting and development. Please contact the authors listed below or your local Deloitte office representative if you’d like to discuss further.