Software Development Cost Capitalization in an Agile World

Your CPA and engineering folks go about their own business most of the time, and that’s all well and good. But once in a while, their paths cross when the company needs to capitalize software development costs. 

While there are conflicting views on whether businesses should capitalize on software development costs, we aren’t in the position to provide guidance. These are business decisions influenced by an organization’s interpretation of tax law and reporting responsibilities.

But if your company decides to capitalize on software development costs, how can you maximize the gains without taking unnecessary risks?

We’ll show you the basic concepts of software development cost capitalization and how to generate accurate data-driven insights to inform capitalization decisions.

But Wait… What Is the Capitalization of Software Development Costs?

In accounting, capitalization expenses the costs of an asset over its lifetime instead of when the expenditure was incurred. The asset is added to the company’s balance sheet and depreciates over its useful life.

The Financial Accounting Standards Board (FSAB) issued guidance on the capitalization of software development costs in 1985. It recently published ASC 350 Intangibles – Goodwill and Others to address the expanding types of software and hosting arrangements.

Meanwhile, Statement No. 51 issued by the Governmental Accounting Standards Board (GASB) identifies computer software as an intangible asset. It can be recorded on a financial statement at its purchase price and amortized on a straight-line basis by a rational and systematic method over its estimated useful life.

Capitalizable software costs may include programmer compensation, testing costs, and other direct or indirect overhead expenses. The software must meet specific eligibility criteria under the Generally Accepted Accounting Principles (GAAP.)

There are two types of computer software capitalization allowed under the GAAP accounting standards:

Internal-Use Software

In general, you can capitalize the implementation costs, payroll-related costs, and interest costs associated with the development phase. But you can’t capitalize maintenance and overhead costs incurred post-implementation (e.g., training costs or data conversion costs.)

The FASB published an amendment to ASC 350-40 in 2018 for internal-use software. It updated capitalizable costs to include software or software license purchases, software development (e.g., coding, testing,) and external materials. 

Software For Sale

If you’re developing software to be sold or leased to external users (e.g., as a SaaS company,) the guidance becomes more granular. The costs aren’t capitalizable during the preliminary project stage (e.g., the research and development phase) until the new software is declared technologically feasible after planning, designing, coding, and testing. 

You can capitalize on the direct costs associated with the remaining development work (e.g., adding features, functionalities, and enhancements) after validating that you have a realistic and marketable software product.  

The Benefits of Capitalizing Software Development Costs

Now you may wonder, why would anyone jump through these financial reporting hoops?

Software development costs are amortized instead of expensed in a financial statement in capitalization. The amortization (or depreciation) results in lower reported expenses and higher net income (aka “bottom line”) for accounting purposes. 

Capitalizing expenses can help increase a company’s asset balance without affecting the liability balance. Additionally, if you expensed a high-cost long-term asset, the resulting accounting treatment could prevent a firm from getting new loans.

Agile Software Development and the Capitalization of Software Development Cost 

The delineation of the software development phases by the accounting rules maps well to a waterfall software project plan, with defined gates that move the process from one stage to the next.

While this makes reporting for capitalization easier, it’s often not how things work in today’s Agile world, where most of these development processes happen concurrently—often on multiple assets all at once.

For example, a team may move through planning, development, and maintenance quickly and fluidly throughout a sprint, making it hard to differentiate the capitalizable developer compensation from the non-capitalizable maintenance costs.

Meanwhile, a multidisciplinary product team could make the process even more complicated. It’s hard to determine whether the hours spent by each team member are capitalizable if you can’t assign the hours to each work item granularly.

Some companies may have to contend with story abandonment, where a software project has been approved but halted before it’s released into production. The impairment may put whether the costs can be capitalized into question. 

Additionally, it may be complicated to determine costs associated with identified enhancements. For instance, a functionality may not require a new asset that the company can start amortizing until the team builds on the work in subsequent sprints to complete the asset.

The complexity of tracking agile development cycles raises the risks of errors in financial statements or failing to capitalize on sufficient costs, thereby impacting reported net income.  

Capitalization of Software Development Costs Starts With Accurate Tracking and Reporting

To overcome the above challenges, we must have a solid grasp of how developers spend their time using granular tracking and reporting. Most Agile organizations use milestones or phases to track activities, determine cost allocation, and report capitalization.  

When you use milestones to track capitalization, you’d set “gates” at project kickoff and product release to mark the beginning and end of capitalization. While this method is easier to manage, it doesn’t address the often non-linear nature of sprints.

The phase approach is more nuanced. It considers what each team member did at any point in time to define what is capitalizable. 

Let’s say your organization decides to expense the costs associated with the discovery phase but capitalize on the costs of development, testing, and documentation. You’d need the ability to associate each work item with one of those phases and accurately attribute the time spent by each team member.

Your Time Recording App May Not Be Enough For Accurate Capitalization of Software Development Costs

When you’re capitalizing or billing your time, every minute counts. The ability to track time and associate each entry to a work item is the key to gaining the information you need to support proper capitalization. 

But most time-tracking systems require developers to enter information after the fact (how granular can you get if you’re trying to remember what you did a week ago?) Also, they can’t track time spent at the work item level to associate it with the appropriate phase.

That’s why Agile organizations turn to 7pace Timetracker to improve the accuracy and granularity of how developers track their time.

Timetracker is the only productivity app that’s deeply integrated with Azure DevOps and GitHub. Developers can record their time (almost automatically) on the platform where they work and associate the hours spent on each work item while they work.

You don’t have to hunt for the data, attribute the time, or validate the time tracked. The accurate and granular information helps you remove guesswork and accounting risks while capitalizing on more of your costs.

But using 7pace Timetracker doesn’t mean that you have to give up your current time reporting system or enter time twice (yikes!) Our robust API integrates Timetracker with most platforms so you can get the data synched up effortlessly.

Learn more about Timetrack and see how it can give you the insights you need for software development costs capitalization.