revrec trigger based revg

ASC 606 – RevRec Trigger Based on Activation / Provisioning

BACKGROUND:

RevRec Trigger Based on Activation/Provisioning –

Step#5 of the revenue recognition model requires the Company to recognize revenue when (or as) it satisfies a performance obligation, which is determined by the transfer of control to the customer. The good or service is considered transferred when the customer gains control of the good or service. Now, there can be scenarios where a contract has been entered but the control or usage of goods can’t start for a certain period in such cases Revenue can’t be recognized and requires withholding.

CASE

XYZ Inc, a US-based subscription company has Oracle as their ERP system and enters into a contract with a new customer in the US for the sale of certain Software and Support on 1st Jan-20XX in $ Currency. The contract is for a year (Jan to Dec). The services provided are as mentioned in the below table.

trigger based case

The below table layouts the details available at the time of Contract Signing– Order Number: – SO1001

name of products sold trigger

RevRec Expectation—

As the contract is entered on 01-Jan-20XX date and on that data the Software Access is not Activated or Instance is not Provisioned; XYZ Inc. can’t recognize the Revenue until the user gets the Access / Instance is provisioned.

Solution:

Zuora Revenue has the ability to withhold Revenue in such a scenario and the same can be achieved using various functionality and in multiple ways—

 

Option#1 – Using POB Expiry Feature—

To achieve the above requirement while setting up the Performance Obligation (POB); in addition to the release event POB Expiry also has to be set up based on Activation Date.

Now, in the example above- when the above data is received for the 1st time without the Activation Date; POB will not be released as POB Expiry (Activation Date) is being missed and Revenue Recognition will be on hold.

Later, once the update comes from Upstream System for the same transaction with details related to Activation (i.e. below data is being received)

using pob expiry feature

Now, as the POB Expiry Date (i.e. Activation Date) is being made available; post this update flowing to Zuora Revenue – POB Expiry Setup will trigger and will release POB after the Sales Order update is being consumed into Zuora Revenue.

Once the Performance Obligation (POB) is released Waterfall & Journal Entry Schedules will be generated based on the Ratable Methods being defined for respective POB.

 

Option#2 – Using HOLD Feature—

To achieve the above requirement, we can define a System Hold and Hold can be applied using criteria such as Activation Date being Null.

Now, in the example above- when the above data is received for 1st time without the Activation Date; System HOLD will get applied on the respective transaction line and accordingly Revenue Recognition will be on hold.

Later, once the update comes from Upstream System for the same transaction with details related to Activation (i.e. below data is being received)

using hold feature

Now, as the Activation Date is being made available; post this update flowing to Zuora Revenue – Hold will automatically get released on the respective transaction line and will release POB as well after the Sales Order update is consumed into Zuora Revenue.

Once the Performance Obligation (POB) is released Waterfall & Journal Entry Schedules will be generated based on the Ratable Methods being defined for respective POB.

This way we can automate withholding and release of Revenue without any human interaction in such business scenarios.

Did you find this article on ASC 606 case study helpful?

We will be happy to answer any questions/queries regarding this and any other topics regarding Revenue Recognition and ASC 606.