Archive for category Revenue
Here we are again, back on the road to revenue. You’ll remember that we are working our way down the revenue road looking at ASC 606 (that’s accounting lingo for “Revenue from Contracts with Customers”). Up to this point we’ve covered the first three stops on our five stop journey, with the five stops on the road being:
- Is there a contract?
- What do we need to deliver under that contract?
- What is the selling price we’ll get?
- How do we allocate the selling price to different items we’ll deliver under the contract?
- How do we ultimately recognize revenue?
We’ve taken a deeper look into what a contract is, how to determine what our performance obligations are and how to determine the price we’ll end up getting as a result of entering into the contract. Now, it’s time to take a look at how we slice up, or allocate, the selling price between the different performance obligations or items we are selling to our customer.
How do we allocate our selling price? Why is it important?
Let’s look at each of these questions individually. Under our current guidance, which we call ASC 605-25, “Revenue Recognition, Multi-Element Arrangements”, we allocate revenue based upon relative selling price. This is very similar to the new guidance where we will be allocating revenue based upon relative standalone selling price. This is where things can get a little dicey and confusing. In its simplest form, it can be quite easy. The standalone selling price is basically what we would sell the product or service to by itself. When we only have to deliver one thing (whether that “thing” is a piece of hardware or a service we perform for our customer), the entire selling price is allocated to the one deliverable. There are often cases when we bundle items together for sale, and this is when it can become a bit complex. If we have to deliver more than one good and/or service to our customer under our agreement, we are then required to carve up our selling price into sections and allocate a piece of the selling price to each deliverable based upon their standalone selling price relative to the total of all standalone selling prices that we are delivering to our customer under the contract. Think of it like this:
|Contract Price||X||Product A’s Standalone Price||=||Allocation of Contract Price to Product A|
|Total Standalone Price for all Products Sold|
Let’s step through an example:
Say you developed a software product and you license it to companies in the automotive industry. You have sold this product to customers in this industry on a standalone basis for $50,000. You also offer software installation services for those customers that would like to use your professional services division to install the software on their servers. You typically sell these services for $250 per hour. In addition, you offer annual maintenance agreements that cover software updates and support. Customers can purchase these alone, but typically purchase them with the software and renew them on an annual basis for $10,000. Now, you’ve got a new customer that wants to purchase the software, 100 hours of implementation services and one year of annual maintenance. You decide to sell this bundle of products and services for $75,000. If you sold each of these items individually your selling price would be $85,000, but because you want to land this important deal, you offer your customer a $10,000 discount for the bundle. Your $75,000 contract price, and $10,000 discount, would be split up like this:
This post is not intended to be all encompassing, but to give you an idea of some of the complex issues you may encounter with the new revenue recognition rules. “Why does this matter?” you say. It matters, because you will recognize the revenue for each of these products at different times. That’ll be covered in the next post.
Thank you for traveling down the revenue recognition road with me to our fourth stop. At our next stop will be looking at how we recognize revenue. Stay tuned!
Please feel free to comment on my post or reach out to me with comments or questions.
Susan Nieland, CPA