Posted by & filed under Revenue Recognition, Software.

I’m looking forward to the day when revenue recognition falls under one overarching model. The FASB and the IASB are working on a converged model for customer contracts that will completely revamp the revenue recognition rules and replace much of the guidance currently in place. As of this writing, the effective date for the guidance would be January 1, 2017. That may shift was the deliberation process continues. Until then we have ASC 985-605 to guide us through software revenue recognition.

What follows is a summary of the current accounting guidance. There is much nuance in software revenue accounting which will be addressed in future posts. So, use what follows with that caveat in mind.

In an arrangement with a single deliverable, software revenue recognition is not difficult. It’s just a matter of selecting the correct method for the deliverable. Here’s a chart of the most common software deliverables and related revenue recognition methods:

Deliverable Revenue recognition method
Tangible software product (e.g., CD, download) Upon 1) physical delivery or download, as applicable and 2) delivery of access code or keys, if applicable for access by the customer
Software license On date license period begins
Post-Contract Services (PCS) Ratably over the PCS term
Software services Depends upon the nature of the services. Available methods include: Specific Performance (use if the services involve a single act); Upon Completion (use if the services have little to no value to the customer until completion); Proportional Performance (use if the services are provided over a period of time and have value to the customer as provided; performance should be measured using either an input method, an output method or ratably over the services period, as applicable); Subscription (use if the services are made available to the customer for consumption over a specified period of time and for certain discounts on future purchases)
Development, modification and customization services Use Contract Account under ASC 605-35
Software hosting (must meet specific requirements to be considered a software element) Subscription

An arrangement with multiple deliverables offers much more complexity due to 1) the need to allocate arrangement consideration (the fee) to the various deliverables, including deliverables that may not fall within the software guidance, 2) the concept of vendor-specific objective evidence (VSOE) of fair value as the basis of allocation, 3) the treatment of incremental discounts on future purchases, 4) the impact on revenue recognition amount, timing and methods if VSOE is not available for one or more of the deliverables, and 5) the multiple revenue recognition methods that may arise out of one arrangement.


The starting point in most allocation situations is selling price. The term selling price can have many meanings, but in revenue recognition it is the price that the entity would transact a sale of the deliverable on a stand-alone basis. Thus, selling price is frequently not list price or rate card price. In fact, selling price for a deliverable on a stand-alone basis may not be easy to determine if the deliverable has never been sold separately. Selling price may then be either the selling price of a third party for a substantially similar deliverable, or a management’s estimate. A full discussion of the hierarchy of evidence of selling price follows in the “Selling Price” section.

If the arrangement includes both software and non-software elements, then the allocation process must first start with allocating the arrangement consideration to the software and non-software elements as groups then proceed to allocating the amount allocated to each group to the individual elements within each group. This group-level allocation process is governed primarily by ASC 605-25, but can be impacted by the GAAP guidance applicable to each type of deliverable in the arrangement. This is a subject worthy of separate coverage and will be addressed in a later post.

Once you have the amount of arrangement allocation applicable to the software elements, or if the arrangement contains only software elements, allocation of consideration to individual software elements is based on relative selling price. There are a few important exceptions to this general rule as follows:

  • Specified upgrade right – If the arrangement includes a “specified upgrade” right, the right should be an amount equal to its selling price. The theory here is that it is difficult to know whether the customer is purchasing the current version or the upgraded version, so the guidance presumes that it is the latter. The effect is that any discount in the arrangement, express or inherent, is allocated to the other elements and away from the specified upgrade right.
  • Discount on a future purchase – An incremental and “significant” discount on a future purchase must be allocated among the arrangement elements. The discount allocation process depends upon the nature of the discount and is address in the “Discounts” section below.of
  • Reallocation of consideration – The general rule that the allocation of proceeds occurs at inception of the arrangement and does change subsequently (see Selling Price below)  is broken when the only undelivered elements remaining from the arrangement have a selling price evidenced by VSOE. In this situation, two things happen. First, revenue on the delivered elements, including those that do not have VSOE (see Selling Price and Timing discussions below), can be recognized. Secondly, arrangement consideration is reallocated so that all undelivered elements are reflected at full selling price as evidenced by VSOE instead of at the original allocated amount based on relative selling price. This is called the “Residual Method” and has the effect of allocated any discount in the arrangement, express or inherent, to the delivered elements.

Selling Price

The hierarchy of evidence of selling price is as follows:

  1.  Vendor-specific objective evidence (VSOE) – VSOE is defined as the price of the deliverable when sold separately and is evidenced by actual sales of the deliverable on a stand-alone basis. If the deliverable is not yet sold separately, then price of the deliverable  established by management with relevant authority may be used. If this price is subsequently proved wrong by actual sale transactions, then the company will have to consider whether the original price was used in error and correct the previously-issued financial statements.
  2. Third party evidence – Third party evidence includes prices charged by competitors on a stand-alone basis for products and/or services, as applicable, with substantially similar features. Since many software elements are by nature unique, third party evidence of selling price is infrequently available.
  3. Management estimate – If neither VSOE or third party evidence is available, then the company should use management’s estimate of selling price on a stand-alone basis.

The selling prices used for allocation should be as of the contract date and should not change subsequently, even of the changed price is based on subsequently available VSOE. Additionally, if VSOE is subsequently available and supports the selling price originally used in the allocation, the availability of VSOE should impact the revenue recognition analysis in the period the VSOE becomes available in a manner similar to a subsequent event.

As noted above, selling price is defined as the price at which entity would transact a sale of the deliverable on a stand-alone basis. Selling price may or may not be objectively determinable and this will have a significant impact on revenue recognition. Unlike for other deliverables, the availability of VSOE of selling price for software elements will affect the timing, and potentially the amount, of revenue recognition. Here’s how. If VSOE is available for ALL elements, then revenue may be recognized as delivery occurs assuming all other conditions for revenue recognition are met. If VSOE does not exist for all software elements, then revenue must generally be deferred until all elements have been delivered (except under the Residual Method as noted above). Since many software elements, such as post-contract services (PCS), are not sold separately, there is frequently VSOE lacking for at least some of the software elements in the arrangement. So, while VSOE is not an absolute requirement for purposes of allocating arrangement consideration, lack of VSOE for one or more software elements will retard revenue recognition for all software elements, including those with VSOE.

Incremental Discounts

Generally, an incremental discount on a future purchase, if significant, must be allocated to each of the arrangement elements. The type of discount, however, will significantly affect the allocation process.

  • Discount on a specified future purchase – A discount on a future purchase for which the monetary amount of the discount is known or can be computed should be treated as a separate element and allocated to the other software elements in the arrangement based on relative selling price ONLY IF VSOE exists for all software elements. If VSOE is available for all elements except the future purchase element, then the consideration allocated to the discount as well as all other elements may need to be deferred and recognized upon the earlier of (assuming all other conditions for revenue recognition have been met) 1) VSOE becomes available, 2) the customer makes the future purchase and uses the discount or 3) the discount period expires. Finally, if VSOE is not available for one or more of the current elements, then all arrangement consideration, including that allocated to the discount, should be deferred and recognized as revenue when either VSOE becomes available for all arrangement elements, or all elements have been delivered (assuming all other conditions have been met).
  • Discount on specified upgrade right – As noted previously, a discount on a specified upgrade right should not be allocated to the upgrade right. Instead, the discount should be allocated to the other software element such that the upgrade right is reflected at full selling price of the upgrade software.
  • Discount on an unspecified future purchase – If the arrangement is silent on the future product or services purchases to which the incremental discount applies, then a portion of the arrangement fee should be allocated to both the current and future elements based on relative selling price assuming the maximum discount will be taken. If the maximum discount amount is not determinable because either 1) the amount of the future purchases is not specified or capped and/or 2) VSOE is not available for the future purchase elements, then the consideration allocated to each software element should be reduced by the discount percentage. If this is the case, the portion of arrangement consideration allocated to the future purchases should be recognized over the discount period as a subscription. If no discount period is specified, then revenue should be recognized as delivery of the future purchases occur, assuming all other conditions for revenue recognition are met.


If all software elements have VSOE, then revenue is recognized as delivery occurs (assuming all other conditions have been met). If the VSOE is NOT available for all elements, then revenue for all elements, including those with VSOE, is deferred and recognized when 1) VSOE for all elements becomes available (and all other conditions, including delivery, are met) or 2) all elements have been delivered. Here are two additional special cases that affect the timing of revenue recognition:

  • Last deliverable is PCS – If the last deliverable under the arrangement is PCS, then the entire arrangement fee should be recognized ratably over the PCS term, including any expected renewal period(s) is renewal is probable.
  • Last deliverable is services – Similarly, if the last deliverable under the arrangement is services, then the entire arrangement fee should be recognized as the services are performed based on the revenue recognition method applicable to the services performance pattern (i.e., based on inputs, outputs or ratably over the service period).

Comments are closed.