Accounting for Internal Use Software

As a finance and accounting guy, my general bent is towards certainty.  It’s great when everything fits into nice, intuitive buckets that can be labeled and accounted for.  But, that’s not always possible.  Especially as more and more companies are making a dramatic shift from project-based software delivery to more product-based management.  All of these changes are with the intent to improve business outcomes.  In other words, companies are wanting, striving, and becoming—more Agile.  So, what’s an organization, who’s been capitalizing costs in a Waterfall environment for say 10, 20, or even 30 years, supposed to do?

Well, these changes in organizational design, development approach, team funding, and operations are a great opportunity for those aspirational Agilists to reevaluate their organization’s accounting for internal-use software and related capitalization policy.  But, they may face some interesting accounting challenges along the way.  For example:

• Accounting for internal-use software under ASC350-40 was originally predicated on Waterfall methodologies, so what happens when implementing these new software development processes?
• Uncertainty created among internal accounting brethren on how to capitalize costs in an Agile environment. How do you manage that?
• As teams become more efficient and produce software more rapidly, tracking of their costs becomes even more important. What options exist?

Solving for The Historical Approach

In the past, the approach to software development—within an IT software project framework—can become a point of contention due to the following factors:

• Formal annual funding of projects
• Certain projects can involve duplicated efforts within organizations due to acquisitions, legacy systems not being retired, etc.
• Organizations moving to a bimodal approach where certain projects require predictable evolution and completion while others need constant exploration and speed is critical

The historical fixed and project-driven approach to funding generally led to a growing level of dissatisfaction because the whole funding process takes way too long – especially for multi-year waterfall projects.  It may take years to finally solve the needed business issue by using this legacy funding approach, and—in a competitive, rapidly changing, business environment—that’s unacceptable.

The pitfall in this older approach is that organizations that have been built up through silos or from mergers and acquisitions have software applications that support the same or portions of the same business process. Obviously, this results in unneeded technical debt that burdens IT organizations to the point where they cannot invest in any new endeavors.

What’s the solution?  Product and capability-focused management.  Moving from focusing on individual projects to a higher overall product vantage point will allow your business to move away from individual project costing to a higher level of analysis—either at the product level or even an overall organization/department view. Expanding the relevant cost pool and those involved in the corresponding processes will enable your organization the ability to capitalize more operating costs—so long as they fall in the appropriate categories of capitalization within the relevant accounting guidance.

The guidance for accounting for internal-use software in the FASB’s Accounting Standards Codification (ASC) 350-40, Accounting for Internal-Use Software, outlines how companies should capitalize or expense internal-use software, based on achieving two key objectives. The first objective includes ensuring that the Preliminary Project Stage has been completed and the second one being the type of work being completed within the Application Development Stage qualifies as capitalizable activities.

The original accounting guidance stems from the 1998 AICPA Statement of Position (SOP) 98-1 Accounting for the Costs of Computer Software Developed or Obtained for Internal Use. This SOP was issued three years before the Agile Manifesto was written, so you can imagine that it heavily relies on the software development methodology that was in vogue at that time—Waterfall.  And, the accounting standard followed along with Waterfall’s tight structure of laid out activities as detailed in the image below.

While there may be a perception of a grey area in the language used in the ASC guidelines, there is no ambiguity on one key requirement.  And that requirement is that the Preliminary Project Stage must be completed and documented appropriately.  Ultimately this gating item means that until this stage is completed no expenses can be capitalized, even if you are truly creating usable software code. ASC350-40-25-12 states—and I paraphrase—the Preliminary Project Stage must be completed and that management intends to fund a software project that will be completed and used for its intended purpose before capitalization can commence.

So, the accountants want to ensure that the appropriate level of diligence has been completed.  They want documentation that’s been well formulated and those involved have evaluated each alternative solution for the business problem at hand.  A key step in completing this stage will be obtaining funding and authorization from management that has the appropriate level of authorization for such a project. Unless that has been obtained, you will remain forever in the Preliminary Project Stage.  Therefore, completing these steps are incredibly important to your internal accounting department colleagues and your external auditors and should be well-documented before capitalization of costs can ensue.

Now, while that is one key requirement for capitalization, the other is understanding the type of costs that can be capitalized once you’ve moved into the Application Development Stage.  Let’s consider the following. Based on the detailed guidance of ASC 350-40-55-4, there’s no requirement that each of the steps in the waterfall methodology occur in a specific stage.  To the contrary, the ASC states that, “…the development of internal-use software may not follow the order shown in the preceding list.  It is the nature of the cost, not entirely timing of their occurrence, that matters.”  This distinction is key in allowing us to capitalize the appropriate costs, even in an Agile environment.  So, it really doesn’t matter if a project is completed under Waterfall or Agile, it is the specific activities undertaken that is important for capitalization.

Capitalizing Costs

Okay, let’s assume that the Preliminary Process Stage has been completed and that we’ve acquired the appropriate authorizations and gotten the funding we need.  Now, the capitalization of software development costs can begin.

Most organizations use timecards due to the fact that they have been using Waterfall methodologies, and that’s okay.  You can still use these within in an Agile format.  Some things to consider before continuing down this path of using time cards or some other method of cost tracking include:

• Using existing time tracking systems will reduce need for additional training given current employees are already familiar with existing processes
• Completion of stories during a sprint may be impacted if time tracking is done with a focus of accuracy
• Alternatively, a lack of accuracy may occur if completing stories are the main area of focus as employees may have been forgotten what was truly accomplished during the week

With all of these issues, you will need evaluate the pros and cons of maintaining the existing time tracking system. As part of that evaluation you should consider several other alternative ways to track costs for capitalization.  A second way is you could use story points and assign a dollar value to each point completed during the sprint.  Note, there are considerations for this using this method, including:

• There may be a higher correlation between the team’s effort and the amount that you can capitalize when compared to timekeeping
• Story points are already used in Scrum, so it’s a natural way to track activities and costs
• Story points are subjective for each development team, so aligning consistently across all your development teams may prove quite challenging
• The use of story points may not pass the requirements of your auditors since they are an estimate of costs, so it is critical you get them on board at the outset

If there is a good amount of disparity among your development teams in using story points—which is not unusual or uncommon—a third way, and potentially the best for agile, is to capitalize costs based on the new functionality features completed in relation to all of the other work that each development team completes during a specified period of time such as a Release.  This methodology relies on evaluating each team’s effort of work completed including new functionality features—which are “capitalizable” —compared to bug fixes and enhancements—which would be expensed.  Because story point values within a team should be consistent and accurately reflect the amount of work completed during a particular Release or even an Epic, this should provide a defensible methodology for your internal accounting colleagues and external auditors.

Of course, with the appropriate rigor, any of these methods can work. It’ll come down to what your organization feels comfortable with and is supportable to your accounting teams.  Ultimately what’s most important is that you transform your development teams into cohesive, persistent teams that stay together and look to become high performing.

In our experience, organizations that have been able to achieve this have been able to capitalize 70% of their costs, on average. Some teams become so Agile that we’ve seen them able to capitalize up to 90% of their cost. 90% may be an extreme example, but it proves that high performing development teams can make a direct impact to a company’s operating results. 

Amortization

Once costs have been capitalized, they’ll need to be amortized over the useful life of the software—generally three to five years.

In Waterfall, the amortization begins once the project has been completed. This isn’t exactly the case in an Agile environment. Some companies who practice Agile begin to amortize costs every month with the release of each sprint. They can do this, because, in each sprint, they’ve produced working, tested software.  So, if a software solution is deemed to have a 48-month useful life, it’s first release will be amortized over 48 months. It’s second monthly release, amortized over 47 months. It’s third monthly release, over 46 months—so on, and so forth.

According to Gartner’s “Opex vs. Capex: CIOs Should Partner with CFOs” May 21, 2015, a good rule of thumb is that a company’s combined IT depreciation and amortization expenses should not exceed 20% of a company’s total IT budget.  You can expect to see a constant balancing act that the IT and Finance team members will have to work through together to ensure the appropriate level of investment is maintained.

Policies and Procedures

Creating the appropriate accounting policies and procedures will be necessary for your capitalization efforts.  It’s important that these policies and procedures be simple and scalable, so that they can grow with your organization.  You’ll reap the most benefits if you can use a mantra of simplicity and not create a too burdensome policy with related procedures.  Otherwise, you may impact some of the benefits you are attempting to achieve within an Agile environment.

If your accounting policies become overly complicated or burdensome, any cost savings you may have gained from capitalizing will surely be lost to the adverse impacts to productivity, the decline in associate morale, or even associate turn-over.

I wish you much success as you venture within the accounting element of the overall Agile equation.