Revisiting accounting for software development costs

Point of view Oct 10, 2016

US investment in intangible assets surpasses investment in tangible assets. Do current accounting rules make sense?

First, the broader issue

  • In the US, investment in intangible assets has surpassed investment in tangible assets since the late 1990’s. However, if those intangible assets are generated within an ongoing business, they generally do not appear on a company’s balance sheet. But when companies are acquired, a significant portion of the value is attributable to intangible assets such as software, patented technology, trademarks, brand names, and the like. The fact that some companies’ most vital assets do not appear on their balance sheets is a criticism of US GAAP.
  • In August 2016, the FASB requested feedback on whether to undertake a project on the recognition of internally-generated intangible assets. If such a project proceeds, given the wide range and diversity of intangible assets, there are likely to be challenges to the development of a new accounting model for them. As such, we recommend a phased approach – focusing first on a subset of intangible assets, specifically software, which is arguably one of the more “tangible” intangible assets.
  • Since there are currently three different accounting models under US GAAP that can be applied to software development (two software-specific models and another for R&D), revisiting the accounting for software development is a logical first step in the overall reassessment of intangible asset accounting.

First step - disrupting software accounting guidance

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.

Intangible investment: Investment rates in assets, as a percentage of private-sector GDP (graph)

The FASB’s agenda request

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.

Today’s models

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.

  Capitalization treshold
Internal-use software After the end of the preliminary project stage
Software for sale/lease/marketing After technological feasibility is attained

Assessing feasibility

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.

What’s changed?

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.

Moving beyond software - what are the alternatives?

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 vs. other technology

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.

Are different models still justified?

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:

  • Is it still reasonable to differentiate between internal-use software (which includes software provided to customers as a service) and software sold or licensed to customers?
  • Are the differences between software and other types of technology sufficient to justify different accounting models?
  • Is technological feasibility an appropriate threshold for capitalizing development costs or is another threshold, such as completion of the project being more likely than not or probable, more appropriate.

Is there a single-model solution?

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.

In summary

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.


S&P Capital IQ McGraw Hill Financial

Contact us

Beth Paul
Strategic Thought Leader, US National Professional Services Group

Pat Durbin
Partner, National Professional Services Group

Follow us