Contract Modification Rules

Knowledge Center > Zuora RevPro > Contract Modifications > Contract Modification Rules

Contract Modification Rules

Table of contents
No headers

A contract modification rule is designed to identify what type of change that has occurred and trigger a revenue allocation treatment for a revenue contract. Each contract modification rule can only trigger a specified allocation treatment. There are three different revenue allocation treatments: retrospective (cumulative catch-up), prospective, and no allocation. Each individual contract modification results in one revenue treatment either retrospective allocation or prospective allocation or a contract modification results in ‘no allocation’, which simply means that the contract modification rule does not require any revenue allocation treatment.

Any changes to a contract that impacts allocations re-compute your allocations. Depending on the change, these modifications can also impact revenue management (the timing of revenue recognition).

Based on the contract modification rule, the contract will either do a retrospective (cumulative catch up) or a prospective revenue allocation. Zuora RevPro will also highlight the revenue allocation treatment that was applied to a particular version of the contract in the versions tab of the Revenue Contract workbench. In the Details Version tab and the Contract modifications tab, users can see, at the transaction line level, which contract modification rule was triggered and the allocation treatment performed. The latest allocation treatment (initial, Prospective or Retrospective) will be displayed next to the RC number on the overall RC workbench tab. You can manually choose at any time to switch the allocation method. If you manually flip a contract from retrospective to prospective or vice versa, it will not create a contract version. You can only see a record that it was flipped and by whom. Because it does not create a version, you cannot see the value before it was flipped.

When Contract Modification Rule Is Trigger, Zuora RevPro Automatically Performs Allocation Treatment. Zuora RevPro automatically applies contract modification rules on a contract-by-contract basis at the transaction line level. It is important to remember that Zuora RevPro only applies contract modification rules to the revenue book(s) that have the functionality of ‘allocation’ enabled. Any time there is an adjustment (change) to a revenue contract within the Revenue Book (with ‘allocation’ enabled) that triggers a contract modification rule, Zuora RevPro software will automatically update the contract, determine what contract modification rule should be applied, re-process the contract based on the contract modification rule setups.

The contraction modification rule set is applicable across all (enabled) revenue books.

More than one contract modification rule can be triggered for a contract within a Revision Timeline. If there is both a retrospective and prospective change in the same Revision Timeline and the reason for the perspective change is not the addition of a new POB, Zuora RevPro will do a retrospective re-allocation (using the contract values that take into account the change that caused prospectively).

If the prospective change is the addition of a new POB, Zuora RevPro will exclude that POB from its retrospective re-allocation and then perform the new POB prospective.

Example 1: Retrospective and Prospective change on existing performance obligations
Within the revision window, there are two lines in the revenue contract that have been modified resulting in a contract modification. The change to the first line triggers a contract modification rule that is set to retrospective. The change to the second line triggers a contract modification rule that is set to prospective. As the prospective change is not the addition of a new performance obligation, Zuora RevPro will create a new version of the contract, update both lines with the changes and then perform a retrospective re-allocation. In this case, there will be one new version of the contract created.


Example 2: Retrospective change on an existing line and Prospective change due to new
performance obligation(s).

Within the revision window, there are two changes to a revenue contract. The first is a change to an existing line that triggers a contract modification rule that is set to retrospective. The second is the addition of new goods and services (new transaction lines) that represent a new performance obligation which is not sold at SSP and triggers a prospective rule. As the prospective change IS the addition of a new performance obligation, Zuora RevPro will create a new version of the contract, make the change on the existing line and perform the retrospective re-allocation. It will then create another version of the contract that includes the new performance obligation and perform a prospective re-allocation. In this example, there are two versions of the contract created - to show snapshots of the RC contract at each modification. It is possible to have 0, 1, or 2 new versions of a revenue contract created during the ‘Revision Period’. It is important to note that while it is possible that a revenue contract experiences one or a series of contract modifications resulting in one or a series of either ‘prospective’ and/or ‘retrospective’ revenue re-allocations for the revenue contract, it is not possible that a revenue contract experiences simultaneously a ‘prospective’ and ‘retrospective’ re-allocation of revenue, but it can experience based type of contract modifications, a ‘retrospective’ and then immediate ‘prospective’ re-allocation.

Each version of the revenue contract results in a full (complete) snapshot of the revenue contract at the point of revisioning enabling a Revenue Team member to compare versions of the revenue contract and understand the results of the contract modifications.

In RevPro, the contract version and contract modification functionality is a key differentiator and selling point of the Zuora RevPro Revenue Automation Software Solution.

Rule1.jpg

Rule2.jpg

Last modified

Tags

This page has no custom tags.

Classifications

(not set)