It is undeniable that intangible assets are critical to the economy. However, despite the prevalence of intangible assets, some do not appear on companies’ books. Generally, intangible assets are only recognized on the balance sheet when acquired from third parties. On average, the companies in the S&P 500 trade at a 2x to 3x multiple of book value, largely as a result of unrecognized intangible assets1.
Change may be on the horizon. In August 2016, the FASB requested comments on whether their future agenda should include a project on the accounting for intangible assets, including research and development. The FASB also inquired as to whether the potential project should address all intangible assets or instead start with a defined subset.
Because US GAAP requires research and development to be expensed, many internally-generated intangible assets are not reflected on a company’s balance sheet.
This “expense-as-incurred” model, which has been in place for over 40 years, was adopted because—unlike constructing a building or manufacturing inventory—there can be uncertainty as to whether an asset exists at the time the cost is incurred. Further, even if an asset exists, there were concerns about whether it could be reliably measured and whether any value was correlated to the cost to develop the asset.
As software development became more prevalent in the 1980s and 1990s, accounting models were developed that permit research and development costs in connection with the creation of software to be capitalized in certain circumstances.
The threshold for capitalization depends on whether the software is intended for internal use or is to be sold or licensed to others.
|Internal-use software||After the end of the preliminary project stage
|Software for sale/lease/marketing||After technological feasibility is attained|
Development costs associated with software to be sold, leased, or marketed to customers are capitalized only after technological feasibility of the software is established. Determining whether the software is feasible typically involves the completion of a working model that is ready for customer testing.
Today, many developers use a modular programming strategy in which programs are divided into components that each perform a specific function, often developed concurrently.
The technological feasibility of each component or function may be established long before they are integrated into a working model, which often occurs late in the development timeline. As such, while the existing accounting model allows for software development costs to be capitalized, in practice, often little or none actually are.
In the past, internal-use software primarily related to back-office functions such as inventory management and accounting. These in-house platforms were distinct from the software the company sold or licensed to customers. However, with the evolution of cloud computing, the lines have blurred between software intended for internal use and software to be sold to customers. The use of software-as-a-service and other cloud-based computing models such as infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) has increased substantially in recent years and is expected to continue growing at nearly 30% per year.
Today, customers may have the option to purchase software that they can download and run on their computer hardware or they can access it in the cloud. While the options might be viewed as equivalent from a customer perspective, the accounting for development costs by the seller differ between software that a customer can, or does, take possession of, and software that is offered as a service. Given the significant changes in the technology industry, a question arises as to whether maintaining two different models for software is justified and, more holistically, whether software should be accounted for differently than other technology or intellectual property.
Software and other technologies often involve very similar development processes. Whether developing new software, or a new semiconductor chip needed to run that software, companies go through planning and design, development, and testing phases for new technologies.
Many new technologies even integrate software and hardware into a single end product, such as a mobile telephone, where the physical handset is virtually inseparable from its underlying operating system and apps. Ultimately, the development of any type of technology involves similar processes, resources, and risks. However, under today’s accounting framework, the resulting intangible asset may or may not be recognized.
With the evolution of software and technology more broadly, and the FASB considering how to address intangibles, we believe now is the time to reexamine whether accounting for software should continue to utilize different models.
We believe the FASB should revisit the accounting for research and development activities, including:
Simplification has been a significant focus for the FASB in recent years. Aligning development costs associated with internal-use software, software for sale, and other technologies into a single accounting model could be a significant simplification.
One possible single-model solution is the IFRS model for accounting for research and development costs. Under IFRS, research costs are expensed as incurred, but costs associated with the development of any type of intangible asset are capitalized when completion is feasible, management intends to and has the resources available to complete the project, and there is a market to sell or use the intangible asset.
A single model like the one used under IFRS may be feasible in the US. However, additional clarity may be needed in certain areas, such as whether feasibility of completion differs from achieving technological feasibility, and whether software should continue to be distinguished from other technologies.
Despite changes in the software industry, the accounting for software development costs has remained relatively constant, with different accounting models for internal-use software, and software to be sold, leased, or marketed to customers.
Given the increasing importance of software to the US economy, the accounting for software intangibles, is an area ripe for reconsideration and a logical place to start when considering the accounting for internally-generated intangible assets.
Ultimately, it may be appropriate to account for all internally-generated intangible assets under a single model, but that model may not necessarily be one of the three models currently used in US GAAP.
We believe revisiting this accounting would go a long way toward addressing the criticism of US GAAP that many companies’ most critical assets do not appear on their balance sheets. We acknowledge there are some intangibles, such as brand names, that would not be addressed by this project; however, experience shows that stakeholders have differing views on both the recognition of intangibles and the measurement method (cost or fair value). As such, we believe starting with a narrowly scoped project to help identify unintended consequences and obtain stakeholder input would be more fruitful.
1 S&P Capital IQ McGraw Hill Financial