Step-by-Step - Step 4: Differences in ASC 605 / SAB 104 and ASC 606
Step-by-Step-Step-4-Differences-in-ASC-605-SAB-104-and-ASC-606

Step-by-Step - Step 4: Differences in ASC 605 / SAB 104 and ASC 606

Are you ready for the new revenue recognition standard? Do you know how transitioning from ASC 605 / SAB 104 to ASC 606, Revenue from Contracts with Customers, will affect your organization? If not, you’re in luck! In our new series of blog posts, we walk through the new five-step model, step-by-step, to get you prepared!

ASC Topic 606 prescribes a new five-step model for entities to follow when recognizing revenue. These five steps are:

  1. Identify the contract(s) with a customer.
  2. Identify the performance obligations in the contract.
  3. Determine the transaction price.
  4. Allocate the transaction price to the performance obligations in the contract.
  5. Recognize revenue when (or as) the entity satisfied the performance obligations.

In this post, we will focus on step 4: Allocate the transaction price to the performance obligations in the contract, including potential changes to existing guidance.

The whole objective of Step 4 is to break the transaction price apart in order to recognize a reasonable amount of revenue when satisfying a contract’s individual performance obligations. The method prescribed in the new standard to accomplish this objective is the relative standalone selling price approach.

From a basic standpoint, the standalone selling price is the price at which an entity would sell a promised good or service separately to a customer. The best evidence of this standalone price is the observable price of a good or service when the entity actually sells that good or service separately in similar transactions. Contract prices may represent the standalone selling price of that good or service, but it is important to remember that this is not always the case.

Oftentimes, actual standalone selling prices do not exist and entities will need to use an estimation method in order to properly allocate the transaction price. This estimation should always seek to maximize observable inputs, and estimation methods may include:

  1. An adjusted market assessment approach,
  2. An expected cost plus a margin approach or
  3. A residual approach.

The residual approach is only allowed if either of the following is met:

  1. The entity sells the same good or service to different customers (at or near the same time) for a broad range of amounts (i.e., the selling price is highly variable because they cannot determine a representative standalone selling price from past transactions or other observable evidence), or
  2. The entity has not yet established a price for that good or service, and they have not previously sold the good or service on a standalone basis (i.e., the selling price is uncertain).

When using estimated selling prices, it is important for entities to continually update their estimates; however, the standard does not prescribe a specific timeframe for updating such estimates. Therefore, the frequency of updates should be based on the facts and circumstances of the situation, and new estimates should be made for each transaction.

So how would entities apply the relative standalone selling price approach in practice? Let’s take a look at an example.

Practical Example

Bolton Technologies is a software developer that enters into a contract with Lumbergh Inc. to transfer a software license for their TPS-report–writing program, perform an installation service, and provide unspecified software updates and technical support (online and telephone) for a two-year period. The total contract cost is $100,000.

Bolton sells the license and installation service separately for $55,000 and $10,000. The standalone prices for the software updates and technical support are not directly observable and vary significantly in other bundled arrangements due to individual customer negotiations as well as scope of the related software updates.

Question 1: How much of the transaction price should be allocated to the software updates and technical support under current revenue recognition guidance?

Question 2: Would the answer change under the new standard (ASC 606)?

Answer to the first question: Existing Guidance

You would be unable to allocate any of the transaction price to the software updates and technical support under current revenue recognition guidance. For software arrangements, ASC 985-605 requires entities to determine whether they can separately account for the different elements in the arrangement. This is determined by whether the entity has vendor-specific objective evidence of fair value for the different elements (which does not exist in our example). If not, all revenue for the arrangement is generally deferred until all elements in the arrangement have been delivered or vendor objective evidence of fair value subsequently is available.

Under current revenue recognition guidance, Bolton would defer revenue recognition until the remaining undelivered elements (software updates and technical support) are delivered or vendor-specific objective evidence of fair value can be determined, if earlier).

Answer to the second question: New Guidance (ASC 606)

Yes, the answer changes under the new standard. ASC 606 allows for the residual approach to be used when estimating the standalone selling price for a bundle of products/services with highly variable selling prices (software updates and technical support in our example). This would allow Bolton to allocate the transaction price to the different performance obligations and recognize revenue for them separately as they satisfy the respective obligations.

But how would you do this for two (or more) performance obligations with highly variable selling prices?

You can use different methods, but one option might be to consider the average residual selling price for each product or service over a period of time (determined based on other contracts).

For example, assume the average residual selling prices attributed to the software updates and technical support are $40,000 and $20,000, respectively. The residual amount to be allocated could be calculated as follows:

  • Software updates = 23,333 (40,000/60,000 * 35,000)
  • Technical Support = 11,667 (20,000/60,000 * 35,000)

One thing to consider when applying the residual approach is whether this method results in the allocation of no (or very little) consideration to a performance obligation or bundle of performance obligations. If so, using this approach may not be appropriate. Such results may also call into question whether this performance obligation was “distinct” since by definition, this means the performance obligation is providing value to a customer on a standalone basis.

Final Thoughts

Step 4 in ASC 606 may seem similar to the current practice of using the relative selling price method for multiple-element arrangements. However, entities are no longer required to follow the hierarchy in ASC 605-25 (vendor-specific objective evidence, then third-party evidence, then estimated selling price) or the guidance in ASC 985-605, which generally requires vendor-specific objective evidence of fair value. This will result in changes in current practice and require entities to develop updated or new processes and controls to apply the relative standalone selling price approach discussed in ASC 606. While this process may seem easier than current practice, it is important for entities to always maximize observable inputs. They should also consider whether to allocate contract discounts or variable consideration to specific contract performance obligations versus on a pro-rata basis as is done in current practice.

New call-to-action
 
New Revenue Standard

Comments (0)


Add a Comment




Allowed tags: <b><i><br>Add a new comment:


Ready To Make a Change?

Cookies on the GAAP Dynamics website

To give you the best possible experience, this website uses cookies. By continuing to browse this website you are agreeing to our use of cookies. For more details about cookies and how to manage them, please see our privacy policy.