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:
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 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.
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:
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:
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.
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:
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.
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:
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?
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.
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:
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.
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:
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.
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:
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.
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.