The Value of Custom Software as an Asset

For established businesses looking to introduce a new piece of software to their operations, one of the most challenging aspects to wrap their heads around is calculating the long-term value of the software and how it impacts their procurement decision making.

It’s a fairly straightforward question from a high-level: how much is this software project worth to my business? But once we start breaking down the nuance of this topic, challenging new questions start to arise:

• How is the software classified from an accounting perspective?
• How long will the software remain relevant as technology continues to advance?
• How can you impact the value of the software effectively throughout its useful life?

Once you open this particular can of worms, you’ll probably just end up with more questions than answers.

With that in mind, we’ve donned our technology consultant caps and have broken down an approach to evaluating a new piece of software, how it functions as a business asset, and the implications for how software depreciates over time.

Why Understanding the Long-Term Value of Software Matters

There are a few important reasons why it’s worth taking the time to understand the long-term value of custom software before investing in its development. From our perspective, this includes:

1. Establishing the useful life of the product and its relevance to your organization’s needs
2. Making educated decisions about when and how to upgrade, replace or retire your software

Depending on how integral your software is to normal business operations, it can have a significant impact on how you assign value to it, both before and after development. Your approach when determining the value of your software is dependent on the role it plays as an asset within your organization.

Developing a piece of software for internal use that won’t directly generate revenue (e.g. a scheduling tool for your employees), is inherently different from a mobile app released to the App Store for $0.99 per download, at least to the Financial Accounting Standards Board (FASB).

FASB is an independent non-profit that provides guidance for financial accounting and reporting standards following Generally Accepted Accounting Principles (GAAP), and is a respected body of knowledge when it comes to classification and accounting best practices for software. To that end, FASB recognizes three types of software assets that an organization may own:

1. Internal Use Software
2. Software to be sold, leased, or marketed
3. Software to be used in research and development

In this article, we’ll be focusing on evaluating internal use software, or a piece of software that has been acquired or custom-built to meet the internal needs of a business, and is not intended to directly generate revenue through external sales or licensing.

Software as an Asset

Before we can jump into determining the long-term value of a particular piece software, it’s important to assign it an accurate classification following accounting principles.

Assets fall into one of two categories: tangible and intangible. A tangible asset is a physical item that adds value to your business, which encompasses everything from cash holdings to your land, buildings and equipment. Conversely, intangible assets are non-physical items that creates value, including patents, copyrights, and yes, software.

To get down to the nuts and bolts of it, a piece of software must meet the following criteria to be considered an intangible asset:

1. Be identifiable: The asset must have commercial value that can be reported on a company’s balance sheet.
2. Be owned and controlled by your company: For software, this means that the company either owns the codebase outright, or is licensing the software from a third-party.
3. Have future economic benefit: For internal-use software, this would be through a demonstrable impact to the company’s bottom line (e.g. the reduction of 1,000 man hours associated with administrative staff that the software is replacing).

The distinction between a tangible and intangible asset is an important one, because it demonstrates the difference between depreciation and amortization. A tangible asset (e.g. an office building) will depreciate throughout the course of its life until it reaches its salvage or resale value. For software as an intangible asset, the cost is amortized equally over its useful life until it reaches obsolescence and is retired – which means it has resale benefit to your organization. As we discuss later in this article, the lifespan of a piece of software is fairly short, and will rapidly age unless there is a concerted effort to enhance, maintain, and upgrade the asset to stay relevant.

Software Value Drivers

As a software project moves along its early planning stages, it’s important to take a step back and examine the specific value that it can bring to your business. Particularly for internal use software, it can be challenging to assign a dollar value to the benefits an intangible asset will provide, since there often isn’t a clear line to financial growth or profit gains. In these cases, long-term value can be derived from one or more software value drivers that are specific to the problem that the software is solving for your business.

A value driver is a guiding principle – something that quite literally can “drive value”. It can be applied to any project (and yes, that includes software) to support a broad business objective. These value drivers can further serve as a framework to determine which functions of your business that your software is contributing to, for translation into specific metrics.

Some examples of potential value drivers include:

Product/Service Differentiation
Does the software support or enhance the unique characteristics of your product/service offering? Can this be linked to a potential growth in your customer base, and measured through customer lifetime value?

Staff Efficiency
Does the software automate or reduce the workload, effort or man-hours associated with administrative or operational tasks? Can this be quantified as cost savings to your business? For example, 2,080 hours saved on administrative tasks annually is the equivalent of the salary for one full-time staff member.

Enhancing Customer Service
Does the software improve existing customer service solutions for your clients? An example may be introducing an application to allow users to request technical support online rather than in-person or over telephone, which could be measured by the number of call requests diverted by the app over a given period.

Be creative and think tactically when taking stock of value drivers. If your proposed software project doesn’t include a clear correlation between your key value drivers and overarching business objectives, it may not be a project that you want to prioritize in the short-term.

Determining Software Purchase Cost

Was the asset developed internally by your team? Was it custom built by a vendor like Paper Leaf? Maybe it was a combination of both? When recording an intangible asset on your balance sheet, it’s important to fully understand how determine the purchase cost for the application. This would encompass the total cost of development from start to finish if it was developed by an external firm.

FASB recognizes that development costs for applications are split into three stages of work:

1. Phase 1: Discovery
   Preliminary Project Stage
   • Determine software requirements (i.e. the functionality for the software)
   • Identify if an existing piece of technology can achieve performance requirements, or if custom development is required
   • Select a vendor to develop the software
2. Phase 2: Design and Build
   Software Development Stage 
   • Visual Design
   • Development & Coding
   • Testing
   • Installation or Launch
3. Phase 3: Managed Web Services
   Post-Implementation Operation Stage 
   • Training
   • Ongoing Maintenance

Essentially, the expenditure that your organization invests in Phase 2 above encompasses the asset’s total cost to be amortized over its useful life following its deployment for use. Conversely, Phases 1 and 3 are treated as expenses during the period in which they take place and are not included in amortization.

The exception to this rule would be if significant improvements or enhancements are made to the software that introduce new functionality and/or extend its useful life following launch. In this case the costs are added to the book value of the software and amortized.

Useful Life for Software

There are a few schools of thought when it comes to determining the expected useful life for a piece of software, which can be impacted by ongoing enhancements, additions or upgrades to the software to allow it to perform new tasks.

From an accounting perspective, the general rule of thumb is that the useful life of most software is between 3 and (at most) 5 years. A piece of software will be amortized over this useful life until it reaches obsolescence, as software generally don’t have a resale value at their end of life. This is why it’s so important for software owners to decide if ongoing improvements to their software will extend the lifespan of their software asset, and ensure the potential tangible or intangible benefits of the software will outpace its depreciation rate.

It is also the responsibility of the software owner to periodically evaluate if there has been a significant change to the software’s useful life. FASB recommends taking the following factors into when evaluating useful life:

1. Obsolescence: Is the hardware or software required to access and operate the software no longer viable for the effective use of the asset? Think of CDs. Does anyone have a laptop with a disc drive anymore?
2. Technology: Have advances in alternative technologies reduced the perceived effectiveness of the asset (i.e. the alternatives are technologically superior), or offer lower-cost alternatives to the ongoing upkeep / upgrades to keep your existing software viable?
3. Competition: Have direct competitors introduced technologies, processes, or methodologies that have reduced or eliminated the competitive advantage your software enable earlier in its life?

The process of determining your software’s expected useful life is crucial when it comes to nailing down the amortization period for the asset. As you can see, this is a highly subjective process that requires ongoing monitoring by your business (and accountants), and can impact your decision to improve, replace or retire the software.

Amortization of Internal-Use Software

Now that we have gone through the ringer of determining our software’s purchase cost and its useful life, we’re able to complete a straight-line calculation to determine amortization for the asset.

As an example, let’s take a look at a hypothetical piece of time-tracking software developed for a mechanical engineering firm. Here are the salient details:

• This firm contracted a vendor to custom build the application, which cost $100,000 during Phase 2 to develop.
• Costs for Phase 1 and Phase 3 are to be expensed, and are not in play when it comes to calculating amortization.
• The application was built to be cutting edge, and the firm’s CTO has predicted that it will remain a competitive solution for at least 5 years.
• The company has no plans to enhance or significantly improve the software during those 5 years, and will therefore not benefit from extending the life of the software through the addition of new features and functionality to compete with new technology.
• Finally, this piece of software cannot be sold once it has become obsolete, and therefore will not have a residual value (or salvage cost) at the end of its life.

Using the information provided, we’re able to apply the following Amortization Formula to come up with the amortization expenses for the product throughout its lifetime.

Amortization Expense = (Purchase Costs – Salvage Cost) / Software Useful Life

($100,000 – $0) / 5 = $20,000

This means that every year, the asset value for the software will decrease by $20,000 until the value of its accumulated amortization becomes equal to its purchase price. At this point, the assumption is that the cost to maintain the software has outweighed its benefit to the company, and will be replaced or retired.

What does this mean for you?

If you’re in the process of planning, developing, or improving a piece of internal use software, it’s important to recognize the factors at play when it comes to the long term value of said asset. Accounting best practices for determining software useful life inherently place a 3-5 year timer on even the most advanced pieces of tech. Without a proactive strategy to introduce ongoing enhancements to the application, it will very rapidly decline to the point of obsolescence.

However, these early stage amortization calculations can be powerful decision making tools to help you evaluate the benefit of your product to your business. If you’re budgeting $100,000 for the development of your software, will the annual net benefit to your organization outweigh the $20,000 amortization expense? Would spending an additional $35,000 annually to ensure the software keeps pace with competitors and extend its useful life by 10 years bolster that net benefit?

These are questions that only you, and the fellow decision-makers in your organization, can answer – but they’re critical to the path you choose when it comes to pursuing custom software development.