ASU 2009-14: Software Revenue Recognition Explained

The Financial Accounting Standards Board (FASB) issued Accounting Standards Update (ASU) 2009-14 to amend accounting rules for complex sales agreements that bundled software with other products or services. It addressed how companies should recognize revenue in these multi-element arrangements, a change from previous software revenue recognition standards often considered too rigid.

While ASU 2009-14 was intended to better reflect the economics of a sale, this guidance has been superseded by the comprehensive standard, ASC 606, Revenue from Contracts with Customers. Issued in 2014, ASC 606 became effective for public companies for annual periods after December 15, 2017, and for private companies one year later. This created a single framework for all customer contracts, making ASU 2009-14 obsolete. No entity should be applying this guidance today.

Scope and Applicability of the Guidance

ASU 2009-14 applied to arrangements where software was a key component of a tangible product. The guidance was triggered when the software element was considered “more than incidental” to the product or service package. This meant the standard applied if the software was essential to the functionality of the hardware, such as the operating system of a smartphone.

Conversely, if the software was not a fundamental component of the tangible product, the arrangement fell outside the scope of this update. An example is a basic utility program, like a simple calculator, included with a computer where the software is not essential to the hardware’s primary function. The update also excluded tangible products where software and non-software components worked together to deliver the product’s essential functionality.

This distinction determined which set of revenue recognition rules a company had to follow. For arrangements within its scope, ASU 2009-14 required a detailed analysis to separate the different parts of the sale. This ensured that revenue was recognized as each part of the obligation to the customer was fulfilled, rather than all at once.

Identifying Separate Deliverables

ASU 2009-14 guided companies in breaking down a contract into its distinct parts, known as “deliverables.” To be treated as a separate deliverable, an item or service needed to have value to the customer on a standalone basis. This meant the customer could use the item on its own or with other readily accessible resources.

Consider a company selling a package that includes a software license, an installation service, and one year of technical support. The company would analyze each of these three components. The software license has standalone value because the customer can use it without the other services. The installation service might be considered separate if the customer could hire another company to perform the installation.

The technical support also has standalone value, as it can be sold separately from the license. If each of these components meets the criteria for being a separate unit, the company would treat the single contract as if it were three distinct sales. This separation aligns revenue recognition with the actual delivery of value to the customer.

Establishing the Selling Price of Deliverables

A significant change from ASU 2009-14 was the method for assigning a selling price to each separate deliverable. It relaxed the previously strict requirement for “vendor-specific objective evidence” (VSOE) of fair value. The update established a three-tier hierarchy for estimating the selling price of each component, giving companies more flexibility in valuing the parts of a bundled arrangement.

The first level of the hierarchy was VSOE. This is the price of a deliverable when the company regularly sells it separately. For example, if a software company sells its one-year technical support contract on a standalone basis for $500 to a substantial portion of its customers, then $500 is the VSOE for that support service.

When VSOE was not available, companies could turn to the second tier: third-party evidence (TPE). TPE involves looking at the prices charged by other companies for similar deliverables in the marketplace. For instance, if a company’s new software module has no sales history, it could look at the standalone price of a competitor’s comparable module.

If neither VSOE nor TPE could be determined, the guidance permitted the use of the third tier: the best estimate of selling price (BESP). This is the price at which the company would sell the product or service if it were sold on a standalone basis. Developing a BESP involves management judgment and could incorporate factors such as market conditions, profit objectives, and internal cost structures.

Allocating Arrangement Consideration

Once the standalone selling price for each deliverable was established, the next step was to allocate the total contract price. ASU 2009-14 required companies to use the “relative selling price method” for this allocation. This method ensures that the total fee from the customer is distributed proportionally across all the separate deliverables based on their individual estimated values.

The calculation involves summing the standalone selling prices of all deliverables in the arrangement. Then, for each deliverable, you calculate the ratio of its individual selling price to the total sum. This ratio is then multiplied by the total arrangement fee to determine the portion of revenue allocated to that specific deliverable. This process ensures any discount is spread proportionately.

For example, imagine a company enters into a $1,500 contract that includes a software license and installation services. The company establishes a standalone selling price of $1,400 for the license and $350 for the installation. The sum of the standalone prices is $1,750. The license represents 80% of this total ($1,400 / $1,750), and the installation represents 20% ($350 / $1,750). Therefore, the $1,500 contract fee is allocated as $1,200 to the software license and $300 to the installation.

Required Financial Statement Disclosures

ASU 2009-14 also introduced new disclosure requirements to help investors and other financial statement users understand a company’s revenue recognition practices. The goal was to provide transparency into the judgments and estimates involved. Companies were required to describe their accounting policies for software revenue recognition in the notes to their financial statements.

The disclosures needed to detail the nature of their multiple-element arrangements, explaining the types of products and services that were bundled together. A requirement was to provide information about the judgments made, particularly in determining the selling price for deliverables. This included explaining how the company applied the estimation hierarchy of VSOE, TPE, and BESP.

For instance, a company would have to disclose when and why it used BESP for a deliverable. It would also need to describe the methods and assumptions used to develop that estimate. These qualitative and quantitative disclosures were intended to give a clearer picture of how a company derived its revenue figures.