What to look for in a tech solution for revenue recognition

You’ve recognized the challenges in recognizing revenue under ASC 606, and are leaning toward an automated solution. So, what should you look for in a technology solution for revenue recognition?

First and foremost, make sure that any technology solution you are seriously considering will be compliant with ASC 606. Beyond that, there are some basic system requirements that must be present plus the ability to handle some of the more complex revenue recognition scenarios discussed in our last blog. In this post, we will discuss the four critical system requirements that any good revenue recognition system must have.

4 key system requirements

1. Tracking

Any technology solution must be able to track contracts based on the 5-step model.

• 1. Identify the contract with the customer – The software should be able to automate and track each individual contract within the context of the 5-step model. 
• 2. Identify Performance Obligations (POs) – The software should be able to track the performance obligations for each individual contract.
• 3. Determine the transaction price – The software should be able to identify and separately track both fixed and variable components of the transaction price.
• 4. Allocate the transaction price to each PO – Software must also be able to track and report on the amount of revenue allocated to each PO, the amount recognized for each PO and the amount remaining to be recognized for each PO.
• 5. Recognize revenue when (or as) POs are satisfied – Software must be able to recognize revenue for each PO according to the appropriate recognition trigger.   

2. Presentation

The software must also be able to report out net contract asset/liability balances AND any receivable balances (this may be more difficult than you anticipate).

3. Variable consideration and contract modifications

Any technology solution must be able to handle changes to variable consideration (refunds, bonuses, penalties, revenue as percentage of sales, right of return, etc.). Under ASC 606, variable consideration must be estimated and included in the transaction price that is allocated among the performance obligations.   Also, contract modifications will need to be continually monitored and assessed to determine the appropriate accounting.

This means ongoing changes to the transaction price as well as reversals of revenue or revenue catch-up adjustments which may be new for many organizations. For example, assume a building contract that stipulates the builder receives fixed consideration of $1,000,000 and a possible $100,000 bonus (variable consideration) if construction is completed within the year. At inception of the contract on 1/1, the builder does not expect to complete the structure by year end so the builder should not include the bonus of $100,000 in the transaction price. The builder would then recognize the $1,000,000 fixed transaction price over the completion of the building. Assume the building is 75% complete by 8/31 and the builder is confident they can complete the construction on time.

At this point, the builder has recognized $750,000 of revenue related to this contract based on the fixed consideration only. However, now the builder needs to include the $100,000 bonus in the transaction price (total transaction price is now $1,100,000) and recognize additional catch-up revenue at 8/31 of $75,000, reflecting 75% of the bonus.  With different circumstances, a company might need to recognize a revenue reversal due to changes in variable consideration or contract modifications. It gets complicated fast.

4. Billing, collections and revenue recognition

You will need to be able to disassociate revenue recognition from purchase orders and invoicing. The software can’t just be a revenue recognition engine, it must also be integrated with billing and collections. Under ASC 606, you must present the net contract asset and liability position for each contract, and to do this, you must incorporate cash collections (i.e., cash collected upfront, before the satisfaction of a PO, may result in a contract liability while cash collected later, subsequent to the satisfaction of a PO, may result in a contract asset).

Additionally, under 606, billing and revenue recognition may not go hand-in-hand. Generally, invoicing has kicked off the recognition of billed receivables but under 606, there may be situations where you need to recognize and record an unbilled receivable. A billed receivable under today’s guidance may not equate to a receivable under 606.

Conclusion

You are now armed with knowledge to talk to the CFO about the core system requirements related to ASC 606. In my next post, I’ll cover some of the more advanced functionality that will be required.