Contract Modification Life Cycle

Knowledge Center > Zuora RevPro > Contract Modifications > Contract Modification Life Cycle

Contract Modification Life Cycle

The Revenue Contract Life Cycle refers to processing a revenue contract from the start of the contract (contract creation) through all five steps (of ASC 606) of the revenue recognition process to the end of the contract (contract close). The period of time for a Revenue Contract to complete its life cycle is sometimes referred to, in the context of RevPro, as the Contract Timeline. Highlighted below is an illustration of a Contract Life Cycle as depicted by a Contract Timeline with a START DATE (creation) and END DATE (Close).

In the context of RevPro, the vocabulary term Contract Timeline is used to refer to the duration of a Contract Life Cycle.

seven.jpg

By default, Zuora RevPro does not automatically close contracts. For example, if sales orders (transaction lines with Line Type SO) were uploaded in January 2017. Then, the billing occurred and all the revenue for the contract is released in the remaining months in 2017. Three years later, an additional (new) sales order transaction line was upload with the assumption that the additional sales order transaction line met the RC Grouping Criteria of the Grouping Rule for the RC Grouping Template. Zuora RevPro would add the additional (new) sales order transaction line to the existing contract because RevPro’s default behavior is to never close a contract.

  • Revenue Users can manually close revenue contracts as not to allow any new transaction lines in the revenue contract overriding RevPro’s configured grouping rules. Revenue Users can manually close revenue contracts in the Revenue Workbench or by performing a Mass Action. 
  • To restrict and prevent transactions lines to be grouped into contracts, a time-based restriction can be set up or configured for an RC Grouping Rules to limit which transaction lines are grouped together into a revenue contract. For example, RC Creation Period can be configured as the time-based restriction for an RC Grouping Rule. It is important to note that the time-based restriction for an RC Grouping Rule only helps define which transactions are grouped together to create the contract. The time-based restriction for an RC Grouping Rule does not determine whether or not a transaction line that is grouped into a contract is part of the contract at creation or is processed as a contract modification. Instead, Zuora RevPro uses the business accounting processing logic as set up or configured for the Contract Modification Timeline (Initial Contract Timeline and Revision Timeline) to determine whether or not a transaction line that is grouped into a contract is part of the contract at creation or is processed as a contract modification. 

Contract (Modification) Timeline

At some point in the Revenue Contract’s Life Cycle, (somewhere along its Contract Timeline), a contract may undergo contract modifications and the Contract Timeline may be referred as a Contract Modification Timeline. The Contract Modification Timeline separates or divides the Contract Timeline into an Initial Contract Timeline and Revision Timelines. Highlighted below is an illustration of a Contract Modification Timeline (Initial Contract Timeline and Revision Timelines).

eight.jpg

It is important to note that any changes (updates) made to a contract during the Initial Contract Timeline are always processed as part of the original contract. In other words, contract modifications can only occur after the Initial Contract Timeline has ended.

The Initial Contract Timeline and Revision Timelines together are referred to as a Contract Modification Timeline. The vocabulary terms Contract Timeline and Contract Modification Timeline may be used interchangeably.

Only changes to a contract processed after the Initial Contract Timeline are processed as contract modifications. Suppose a company configures its RC Grouping Template based on a purchase order and a customer was to request an open purchase order (contract) for the month of January and made many changes to the purchase during January (the Initial Contract Timeline). The changes to the contract are not processed as contract modifications. If a customer were to request an open purchase order (contract) for the month of January and made many changes to the contract during January (the Initial Contract Timeline), any changes to the contract are processed as being present at the creation of the contract.

Initial Contract Timeline

A company, based on how it defines its contracts and how transactions are processed in the upstream systems, must define and document (in their accounting policies and the Zuora RevPro BRD) the duration of the Initial Contract Timeline within RevPro. The definition of the Initial Contract Timeline (is not a requirement of an ASC 606) but rather is determined as part of the company's operational policy. It is important to note that the duration of the Initial Contract Timeline is configured at the Zuora RevPro system/rule set level. All contracts that are processed in a revenue book that adheres to the ASC 606 rule set (in RevPro) will use the same Initial Contract Timeline (for example, RC Creation Period). In other words, it is not possible to configure different Initial Contract Timelines with different durations for different goods and/or services contracts. Zuora RevPro only allows the setup/configuration for one Initial Contract Timeline.

Duration Type

Zuora RevPro uses Duration Type and Duration to set the Initial Contract Timeline. The two available Duration Types for the Initial Contract Timeline are RC Creation Period and RC Creation Quarter. RC Creation refers to the Zuora RevPro accounting period or quarter that was open when the Revenue Contract was first created in Zuora RevPro. This means that the open accounting period in which the source data lines were input into Zuora RevPro for processing. If a sales order date for a line was 1/1/2016, but the line was input into Zuora RevPro on 2/1/2017, the duration of the initial timeline would start from 2/1/2017.

Navigate to Policies > Contract Modification

Nine.jpg

In a different example, if a new sales order transaction line (Line Type SO) was processed (in RevPro) on February 15, 2017, and created a new Revenue Contract, the RC Creation Period would be February 2017 (and the RC Creation Qtr would be Q1-17). Continuing with this example, there could be 20 different changes to the contract during the RC Creation Period. However, all 20 changes would be processed as being part of the original contract at the creation of the contract. Because all changes occurred during the Initial Contract Timeline as defined as the RC Creation Period.

Duration

When a company chooses a Duration Type of RC Creation Period, it may also choose to include additional periods following the RC Creation Period as part of the Initial Contract Timeline (Original Contract Timeline). Continuing with the example above, if the Duration were set as 2, Zuora RevPro would then set the Initial Contract Timeline as Feb-17 through Apr-17 (the RC Creation Period plus two additional periods).

ten.jpg

Derive SSP/RSSP Date

Zuora RevPro performs an initial allocation for the revenue contract during the Initial Contract Timeline with the assumption that allocations are enabled for that revenue book and that the goods and services sold in the revenue contracts have been flagged as eligible for allocation. The Allocation Eligible Flag attribute is mapped in the transaction upload template, and each applicable line of transaction source data of Line Type SO has the Allocation Eligible Flag attribute set to Y.

For all changes that occur to the revenue contract during the Initial Contract Timeline, Zuora RevPro will repeatedly perform the initial allocation to recalculate allocations for the revenue contract. In order to perform allocations (including the ‘initial’ allocation calculation), Zuora RevPro must be able to derive the correct SSP/RSSP values. Deriving the correct SSP/RSSP values can pose a challenge because SSPs values may change during the course of a contract’s lifecycle as SSPs values also have effective dates. To ensure that a consistent approach is used to determine which SSPs to use, Zuora RevPro includes the Derive SSP/RSSP Date logic which is applied both during the Initial Contract Timeline and applied when contract modifications occur during the Revision Timelines.

Zuora RevPro uses the SSP date as a set or configured for the Derive SSP/RSSP Date. This sets which date Zuora RevPro will use for each transaction line in its comparison to SSP batch effective dates.

The available values are as follows:

  • Min. SO Book Date - Zuora RevPro sets the SSP allocation date for all transaction lines in the revenue contract to the oldest sales order book date in the contract.
  • Min Invoice Date - Zuora RevPro sets the SSP allocation date for all transaction lines in the revenue contract oldest invoice date in the contract. Before invoicing, Zuora RevPro will perform initial allocations based on the minimum sales order book date.
  • Line SO Book Date - Zuora RevPro sets the SSP allocation date for each transaction line in the revenue contract based on the sales order book date of that line.

ten.jpg

Revision Timeline

Any changes that occur to a contract after creation (after the Initial Contract Timeline) are considered Contract Modifications. Zuora RevPro is an automated solution and there can be multiple changes for a contract during a month or quarter. The system has the concept of a Revision Timeline (Period). After the Initial Contract Timeline (Period), Zuora RevPro uses the Revision Timeline (Period), to determine the transaction price balance for the remaining unsatisfied or partially unsatisfied performance obligations when the contract modification is treated as a prospective change. It also groups all modifications occurring in a Revision Timeline together to determine the order in which they will be processed.

Duration Type

Zuora RevPro also uses Duration Type to set each Revision Timeline (Period). The two available Duration Types for Revision Timeline are RC Modified Period and RC Modified Quarter. Zuora RevPro derives the start of the first Revision Timeline from the end of the Initial Contract Timeline. All follow-on Revision Timelines are based on the end of the period or quarter of the previous Revision Timeline.

Example:

  • Order Booked 2/15/17
  • Initial Contract Timeline Duration Type: RC Creation Quarter
  • Revision Timeline Duration Type: RC Modified Quarter

For the above example, the revenue contract is initially created in February 2017 that is in Q1’17. Any changes to the contract that occur through March 31, 2017 (the end date of Q1’17) will be considered part of the original contract. The first Revision Timeline will be Q2’17 or April 1, 2017 through June 30, 2017. Zuora RevPro will determine the transaction price balance for the remaining unsatisfied and/or partially unsatisfied performance obligations for prospective re-allocations as of March 31, 2017. All modifications that occur in Q2’17 will be looked at as having occurred at the same time. This process will repeat for the next Revision Timeline in Q3’17.

Derive SSP/RSSP Date

During the Revision period, contract modifications may require Zuora RevPro to perform a re-allocation of the transaction price based on relative standalone selling prices. As in the Initial Contract Timeline, Zuora RevPro must be able to derive the correct SSP/RSSP values during the Revision Timeline. The Derive SSP/RSSP Date sets which date Zuora RevPro will use for each transaction line in its comparison to SSP batch effective dates. 

The available values are as follows:

  • Line Level SSP Date - Zuora RevPro sets the SSP allocation date for each transaction line in the revenue contract based on its SSP date. For existing transaction lines in the Revenue Contract, it will keep the SSP Date that was assigned from the Initial Contract timeline. For new transaction lines, it will set the SSP date based on the SO Book date of the new line.
  • Use Initial Contract Method - Zuora RevPro set the SSP allocation date for each transaction line in the revenue contract based on the same method used during the Initial Contract Timeline. For existing transaction lines in the Revenue Contract, it will keep the SSP Date that was assigned from the Initial Contract timeline. For new transaction lines, it will set the SSP date based on the Derive SSP/RSSP Date methodology used in the Initial Contract Timeline (Min SO Book Date, Min Invoice Date or Line Level SO Date).

twelve.jpg

Contract Modification Versions

In order to allow users to track the history of changes during the Initial Contract Timeline and contract modifications during the Revision Timelines, Zuora RevPro creates versions of the revenue contract. 

  • Initial Contract Timeline - Within the Initial Contract Timeline, if revenue has been recognized and posted (either within the same period or across fiscal periods), and there is a change (still within the initial period) Zuora RevPro will create a version but will continue to show the allocation treatment as Initial.
  • Revision Timeline - Zuora RevPro will always create a version for the first contract modification that occurs within a Revision Timeline (if revenue has been recognized on the revenue contract). It will also create revisions within a Revision Timeline when:
    • There are multiple contract modifications both within and across fiscal periods.
    • There are multiple contract modifications that happen at the same time in a fiscal period which would cause different allocations methods to be applied. For example, there is a contract modification to an existing performance obligation that is treated retrospectively as a cumulative catchup, and then new transaction lines that represent new distinct performance obligations are added to the revenue contract. Zuora RevPro would have a version for the retrospective change and then another version for the prospective addition of performance obligations.

Revenue Contract Versioning (RC Creation Period)

Initial Contract Timeline     = RC Creation Period

Revision Timeline              = RC Revision Period

thirteen.jpgfourteen.jpg

Revenue Contract Versioning (RC Creation Qtr)

Initial Contract Timeline = RC Creation Qtr
Revision Timeline          = RC Revision Period

fifteen.jpg

When Contract Modification Rule Is Trigger, Zuora RevPro Automatically Performs Allocation Treatment

RC Grouping Template

Re-assignment of Performance Obligation Assignment rules

During the Initial Contract Timeline, Zuora RevPro will review the Performance Obligation (POB) Assignment rules for all transaction lines in the revenue contract.

For New Transaction Lines Joining the Revenue Contract

After the Initial Contract Timeline, Zuora RevPro applies the POB Assignment rules for new transaction lines joining the Revenue Contract based on the following conditions:

  • If the new transaction line joins an existing performance obligation (non-leading line), Zuora RevPro will add the transaction line to the POB and release revenue for the new transaction line based on the percentage of revenue released on the leading line.
  • If the new transaction line requires existing transaction lines to be regrouped into a new POB template and revenue has NOT been recognized for any of the affected transaction lines, Zuora RevPro will regroup the transaction lines into the new performance obligations.
  • If the new transaction line requires existing transaction lines to be regrouped into a new POB template and revenue HAS BEEN RECOGNIZED for any of the affected transaction lines, Zuora RevPro will put a POB RULE exception hold on the RC (or transaction line ), and regroup the new transaction lines into performance obligations based on applying the POB assignment rules only to the new transaction line(s). This system limitation is due to how events may or may not need to be replayed on the adjusted performance obligation is revenue has already been released.
Series Distinct Performance Obligations And Contract Modifications

Series distinct performance obligations - On the POB Template, users define if a performance obligation represents a series of distinct performance obligations. They can be distinct based on time (such as a support services agreement) or by quantity (such as consulting hours). This is important for contract modifications because when a contract modification occurs in a contract and revenue for a series distinct POB is partially satisfied (recognized), Zuora RevPro will treat the remaining portion as distinct from the portion already satisfied. This is important as the accounting guidance outlines different modification treatments (prospective or retrospective (cumulative catch up)) if the remaining performance obligations are distinct from those that are satisfied or partially satisfied (recognized).

Timing Of Allocation Adjustments

Allocation adjustments (carve in/outs) happen in full in Zuora RevPro at the earlier of the first billing or first revenue release on the revenue contract. These initial allocation adjustments always net to zero and are done in and out of the Adjustment Liability accounts. The Adjustment Liability accounts can be the same accounts as the Contract Liability/Deferred Revenue accounts used by the company and their balances are including in determining a revenue contract Net Contract Asset/Contract Liability balance.

Initial Allocation Treatment

The first version of a revenue contract (version 1) will display its allocation as initial next to the RC number on the tab in the Workbench. Initial, in this context, is always referring to retrospective revenue allocation treatment that a revenue contract experiences at the creation of the revenue contract. Version 1 of a revenue contract will always be initial (retrospective revenue allocation treatment). Only if the revenue contract were to experience a contract modification would then a new version of the contract be created (for example, version 2). The new version of the contract would receive retrospective and/or prospective revenue treatment (and the last revenue treatment applied to the revenue contract (retrospective or prospective) would be displayed on the revenue contact’s tab in the Workbench).

Contract Modification Allocation Treatment

The revenue treatment for a re-allocation of revenue for the revenue contract (due to a revenue contract modification) is either a retrospective re-allocation of revenue or a prospective re-allocation of revenue or no allocation.

  • Retrospective allocation treatment
  • Prospective allocation treatment
  • No Allocation (no allocation to be performed on the line)

Retrospective Allocation

A retrospective re-allocation of revenue re-allocates the complete transaction price of the revenue contract across all the performance obligations, regardless if the performance obligation has been satisfied. For example, if a revenue contract with partially recognized revenue experiences a revenue contract modification (that requires a ‘retrospective’ re-allocation of revenue), Zuora RevPro reverses the entire original allocation (for example, reverses the initial allocation adjustment and any adjustment revenue recognized to date) in the current open accounting period, applies the contract modification changes, re-performs the allocation, rebooks the new initial allocation entry and re-releases the revenue allocation with any catch-up allocation revenue. Zuora RevPro then posts the cumulative catch-up allocation revenue in the current open accounting period (effectively netting the impact in the current accounting period). If no revenue for an arrangement has been posted, then the re-allocation and adjustments are made to the Adjustment Liability accounts.

A Revenue User, within the (Revenue) Workbench in RevPro, can manually override the most recently applied revenue treatment to a revenue contract. For example, a Revenue User many switch a revenue contract’s allocation treatment from prospective to retrospective. If allocations are not posted, Revenue users will see a Switch Allocation option at the Revenue contract level on the transactions tab of the Revenue Contract Workbench. For a revenue contract where revenue has been posted, the allocation method is determined as part of the Unfreeze option. Manual unfreezing is the same action that Zuora RevPro automatically performs as changes come into a revenue contract. Users choose whether to unfreeze retrospectively (all allocations are reversed) or prospectively (only current and future allocations are reversed (is posted) or deleted (if not posted).

Prospective Allocation

A prospective re-allocation of revenue only re-allocates the remaining transaction price for the unsatisfied or partially satisfied (for series distinct) performance obligations in a revenue contract. For example, if a revenue contract with partially recognized revenue experiences a revenue contract modification (that requires a prospective re-allocation of revenue), Zuora RevPro takes the remaining balance (remaining allocated amount) for those transaction lines that are not fully recognized, applies the contract modifications, re-performs the allocations (with the appropriate adjustments to SSP based on amount of revenue previously released) and updates current period and all future period allocations. It does not do a cumulative catch-up adjustment of allocation revenue. In other words, a ‘prospective’ re-allocation makes changes to the scheduling of revenue based on the revenue contract modification and what will likely happen in the future as a direct result of the contract modification while any previously released revenue ‘in the past’ for the revenue contract remains unaffected.

A prospective allocation with cumulative catch-up occurs when there is a contract modification that triggers a prospective re-allocation, but there is a series non-distinct performance obligation in the revenue contract that has been partially satisfied. In this case, Zuora RevPro Zuora RevPro takes the remaining balance (remaining allocated amount) for those transaction lines that are not fully recognized, AND the full value of the applies the contract modifications, re-performs the allocations (with the appropriate adjustments to SSP based on amount of revenue previously released) and updates current period and all future unaffected performance obligation and means that any changes to the timing of revenue recognition for the POB will occur in the future. If a transaction is posted to the G/L the transaction is frozen. To make any changes to a previously posted transaction, the revenue contract must be ‘unfrozen.’

No Allocation

Zuora RevPro does not apply a revenue allocation treatment. The previous allocation is still applied. For example, retrospective allocation. 

Configuration Requirements of Using Contract Modification

Th following configuration requirements must met for contract modification:

  • The contract must be processed within a revenue book that adheres to ASC 606.
  • Revenue book must be configured to have allocations enabled.
  • The contract must be within a Revision Timeline period.
  • The contract must have more than one POB.
  • Contract must require revenue allocation SSP/RSSP/ASSP values.
  • Contract Modifications Documented in the company’s accounting policies and occurs at application level.
  • Only applicable for Revenue Books adhering to ASC 606 standard.
  • 22 Contract Mod Rules (may add more rules as needs develop).
  • The version of Contracts due to Contract Modification (as opposed to version of templates).
  • Audit Trail of contract modifications.

It is not necessary for the old GAAP to treat contract modifications the same way as new GAPP (ASC 606). During the Zuora RevPro BRD creation process, the Professional Services Zuora RevPro Implementation team and the technical financial accountants will review the accounting policies to obtain the necessary business logic to configure the contract modification rules (contract modification policy) in RevPro. GAAP did not have the same level of guidance on contract modifications as New GAAP (ASC 606). It is important to note that companies (that adhered to Old GAAP) may not have accounting policies that fully address the issue of contract modification and how to appropriately handle contract modifications. For example, as companies begin to adopt New GAAP, companies may need to document new contract modification rules in their accounting policies. It is interesting to note that during the Zuora RevPro BRD creation process, the Professional Services Zuora RevPro Implementation team and the technical financial accountants will review the accounting policies to obtain the necessary business logic to configure the contract modification rules (contract modification policy) in RevPro.

Reviewing Contract Versions and Contract Modifications

  • Each version of the revenue contract is a snapshot of the revenue contract. Either before a contract modification or after modification.
  • All zero versions of a contract will be flagged with an indicator ‘I’ for initial.
  • The Revenue Contract workbench includes both a POB level summary and line level detail tab that allows the Revenue User to compare two versions of a revenue contract. By default, the tab will initially load showing a comparison of the current version and the previous version.
  • The Revenue Contract workbench includes a tab showing the lines triggering a contract modification and the contract modification rule used by Zuora RevPro in processing the contract modification.
  • The Contract Modification report includes the same information across multiple revenue contracts.

Contract Modification Rules

There are over 20 different out-of-the-box Zuora RevPro contract modification rules. These 20+ rules can be sorted (toggled) into six different groups based on the type of contract modification.

  • Cancellations / Returns
  • New POB
  • New Transactions
  • Price Modification
  • Quantity Modification
  • Term Modification

Auto-apply Contract Modification Rules

Zuora RevPro is coded with the logic to process the various Line Types and based on the information of the lines and/or the sequence in which the lines are processed, the contract modifications rules are triggered. There are no separate flags or anything the company is required to input as source data to use the contract modification functionality within RevPro. Zuora RevPro software knows automatically how to apply the contract modification rules.

  • All open contracts are subject to contract modifications.
  • Any contracts not played out in Zuora RevPro will not show the versions due to contract modifications.
  • You cannot force modifications to occur in Zuora RevPro (allocation you can force).

Contract Modification Allocation Treatment

Some companies (for example, subscription-based companies) choose to set all the allocation treatments for all contract modification rules to be ‘prospective.’ Other companies may choose to set all the allocation treatments for all contract modification rules to be ‘retrospective.’ Some companies choose a mix of allocation treatments for the contract modification rules. The company must determine the contract modification operational policies.

Comparing Contract Versions (Snapshot) Using Reporting

Each version of the revenue contract is a snapshot of the revenue contract either before a contract modification or after modification.

Any changes that a contract undergoes after the initial formation (creation) of the contract will result in a contract modification. For a company that adheres to the new GAAP guidance (ASC 606), it is possible that a contract modification may result in a new contract. Although not always the case, the terms of the contract must be examined to determine the impact of the contract modification. For example, a contract modification occurs, the company may or may not be required to terminate the initial contract and then create a new contract based on the details of contract modification and the details of the contract that is being modified.

Revenue contracts are accounted for in an accounting book. It is important to note that a company may have more that one revenue accounting book configured in RevPro. However, a company typically does not move revenue contracts between revenue accounting books.

Last modified

Tags

This page has no custom tags.

Classifications

(not set)