Understanding Variance Pricing

Variance pricing is used to capture and process price variances for a particular set of rates. Variance pricing, or retroactive rate adjustments, are required when contractors retroactively apply new rates to transactions that were previously processed. Transactions that have previously been processed are those that have been billed or sent to the general ledger.

You can apply variance pricing to all contract types and all rate set types. In addition, the Pricing summarization feature can be used, which reduces the number of transaction rows that are processed, in turn reducing the amount of time that it takes to run the Variance Pricing process. The Pricing summarization feature can also be used to reduce the number of transaction rows that result from the Variance Pricing process, which are ultimately posted to the Project Transaction table (PROJ_RESOURCE).

You can enable variance pricing on a standard or contract-specific rate set by selecting the Enable Variance check box. When using this option, you can enter, track, and process variance rates on the Rate Variance History page.

You cannon inactive variance pricing on a rate set if a variance rate exists on one or more target rows in an effective-dated rate set.

Through its integration with Project Costing, Contracts enables you to capture and process any rate changed for indirect costs that are associated with the contract. The rate changes generally impact a certain period of time within the contract. For a transaction to be eligible for variance pricing, at least one of its source or target rows must have been sent to the billing worksheet, passed to PeopleSoft Billing for invoicing, passed to PeopleSoft General Ledger for revenue recognition, sent to Asset Management for capitalization, or have been used for fee calculations.

When rate changes occur, the system verifies whether the transaction rows are eligible to be repriced. If they are, then those transaction rows are repriced by the Pricing engine and are ineligible for variance pricing.

New indirect costs are generated by the system for the difference in the old and new rates, and the new rates are used to calculate indirect costs against any current or future transactions going forward. When a rate change is made to an eligible rate set that is associated with a rate plan, after the new transaction row is created, the system prices the new row using any applicable remaining rate sets contained in the rate plan.

PeopleSoft Project Costing maintains a history of these rate changes for audit and reporting purposes.

To enable the system to calculate and produce transaction rows for rate changes, you must complete the following tasks:

• Define a rate set with a rate definition type of Cost, Billing, or Cost/Billing.

  Your costing and cost/billing rate sets contain your provisional and forward pricing rates, and enable you to calculate indirect costs. Variance pricing is only applicable to active rates where associated transactions have been billed, recognized as revenue or used for fee calculations for cost-plus contracts lines. Any rate changes that occur are tracked and managed using the rate sets that you define for the contract.

  When rate changes are processed by the Variance Pricing process, the system generates transaction rows for the difference between the old indirect cost row and the new indirect cost row, prices the new row, and assigns a system source of PRV (variance pricing), and the analysis type that was defined for the original target costing row.

• Select an optional Rate Set Category that indicates that the rate set category can be selected on the Variance Pricing run control page.

• Associate the rate set or a rate plan that contains a cost, billing, or cost/billing rate set, to the contract lines.

• When a rate change has occurred, select the Enable Variance check box on the rate set and enter the new target rate amount using the history link.

Before entering retroactive rate changes for your contract lines, you must first complete the following steps required by the variance pricing process:

1. Assign rate-based contract lines to the contract.

2. (Optional) Create a rate set category that is used during the Variance Pricing process.

3. Create a standard or contract-specific rate set or rate plan.

   Optionally assign a rate set category to the rate set.

   Assign the rate set or rate plan to the applicable contract lines.

   Enable Variance check box selected. To bill and recognize revenue for contract-related direct and indirect costs, you must create a billing rate set (if not using the cost/billing rate set) and a revenue rate set if you have selected the Separate As Incurred Billing and Revenue check box on the contracts.

   Because you can assign only one rate set or rate plan to a rate-based contract line at one time, you will most likely combine your cost, billing, and revenue rate sets onto a rate plan in a manner that meets your pricing needs, and assign the rate plan to your rate-based contract lines.

   Note: Rate sets that are eligible for variance pricing cannot have the same field values for analysis type, source type, category, or subcategory for both the source and target definition criteria. At least one value must be different between the source and target row.

4. Assign active projects and activities to your rate-based contract lines.

   Transactions for rate-based contract lines are tracked using projects and activities associated with the contract line, and stored in the PROJ_RESOURCE table.

5. Set the contract to an active processing status and process transactions.

   Transactions that are eligible for variance pricing are project-related transactions associated with rate-based contract lines that are processed through Project Costing. To process transactions for contract and rate-based contract lines you must also define as-incurred billing and revenue plans and assign them to the applicable rate-based contract lines for billing and revenue processing for your transaction.

After a contract has been activated and transactions have been processed, any rate changes that occur over the life of the contract can be applied using the Variance Pricing feature.

This feature enables you to apply rate changes as needed by performing the steps described in this process flow diagram:

These steps illustrate a high level example of using variance pricing to distribute transactions at a new rate that you previously distributed at a different rate:

1. Access the active rate set to enter the new rates for the target definition.

   Variance rates are generally applied retroactively, over a specified period of time. When accessing the rate set, you must use Correction mode to open the page for the appropriate effective date. To access the Rate Variance History page, navigate to the Target page and enter the new rates for the target definition. Variance rates are tracked and processed using the Rate Variance History page.

2. Define the variance pricing run control parameters.

   The Variance Pricing process selects the data to process based on the criteria that you specify on the Variance Pricing run control page such as business unit, project ID, activity, ID, accounting or transaction date range, contract information, rate set, rate plan, and rate category.

   The Variance Pricing process applies this logic:

   • Selects rate sets based on the parameters specified on the Variance Pricing run control page.

   • Selects active contracts and projects associated with the rate set specified on the Variance Pricing run control page.

   • Projects associated with the rate set must be active, and contracts associated with the rate set cannot have a closed processing status.

3. Perform variance pricing.

   The Variance Pricing process performs these steps:

   1. Selects the eligible transactions that match the effective date and source criteria for the rate set.

      Eligible transactions include transaction rows that are not eligible for repricing and have a general ledger distribution status (GL_DISTRIB_STATUS) of G (generated) or D (distributed), a billing distribution status (BI_DISTRIB_STATUS) of W (worksheet) or D (distributed), and do not have a system source of PRR (priced for revenue) or PRP (priced for billing). Transactions with an asset management distribution status (AM_DISTRIB_STATUS) of D (distributed) and transactions with a contracts fee status (CA_FEE_STATUS) of 1 (one), where the transaction has been used for billing or revenue fee calculations for cost-plus contract lines, are also eligible for variance pricing, whether or not the actual transaction has been billed or posted to the general ledger for revenue recognition.

   2. Calculates the difference between the old rate and the new rate using this equation:

      Variance Amount = (original source) x (new rate) – (original source) x (old rate). This amount may be positive or negative.

   3. Creates the new transaction rows for the difference and posts them to the Project Transaction table (PROJ_RESOURCE).

      The new transaction rows are assigned the analysis type assigned to the original target row, stamped with a system source of PRV (variance pricing), assigned a cost, revenue, and billing distribution status of N to enable cost stacking, billing, and revenue recognition to occur for the new transactions, and assigned a general ledger distribution status of C. The accounting date is specified on the run control page and the transaction date is stamped with the source transaction date.

4. After the variance pricing process is complete, the system posts the new transaction rows one of two locations:

   1. If the Requires Variance Approval check box is selected on the Variance Pricing run control page, then the new transaction rows are posted to a staging table (PC_VP_REVIEW). You must access the Variance Pricing Review page to approve or delete transaction rows prior to sending the approved rows to the Project Transaction table (PROJ_RESOURCE).

   2. If the Requires Variance Approval check box is not selected on the Variance Pricing run control page, then the new transaction rows are posted to the Project Transaction table (PROJ_RESOUCE).

5. (Optional) Applies standard pricing.

   Based on the run control parameters, the Variance Pricing process calls the Pricing engine (PC_PRICING) to apply the new rate to all transaction rows that have been priced, but have not been billed or booked to the general ledger, or that have not been priced. It also prices any transactions that have not been priced, but are eligible for pricing.

When entering variance pricing rate changes, each row is assigned a status. The statuses are set and controlled by the system and control the type of action or processing that can occur against the variance rate row. The rate target sequence statuses are:

• Pending: Appears by default when a new variance rate row is added.

  Only one pending rate row may be entered at a time for a target definition. When a variance pricing rate row is in pending status:

  • The rate field is editable.

  • The rate cannot be selected and used for pricing.

  • The rate displays only on the Rate Variance History page and does not appear on the Target page for the rate set.

• Active: After the new variance pricing rate is entered, and the Variance Pricing process is run for the rate set, the system updates the status of the new rate to Active.

  Only one active rate row may exist at a time for a target definition. When a variance pricing rate row is in active status:

  • The rate field is display only and cannot be edited.

  • The new rate is selected and used for pricing by the Variance Pricing and the Pricing processes.

  • The new rate is displayed on the Target page for the rate set and is associated with a sequence number.

• Inactive: After the new variance pricing rate is active, the previous rate row is set to an inactive status by the Variance Pricing process.

  Multiple inactive rate rows can exist for a target definition. When a variance pricing rate row is in an inactive status:

  • The rate field for the inactive row is display only and cannot be edited.

  • The old rate cannot be selected and used for pricing.

  • Inactive rates are displayed only on the Rate Variance History page.

The Effective-Dated Rate Definitions topic, provides an example of using effective-dated rate sets. The example used a rate set with two active effective-dated rows as shown in this table:

In the example, a source transaction row contained a quantity and unit of measure of 8 MHR, with a transaction date, accounting date, and currency effective date of June 1, 2005. The Pricing process created an actual transaction row in the amount of 400.00 USD by using the rate set named SET1 with an effective date of January 1, 2005, and multiplying 8 MHR by a target rate of 50.00 USD.

Now assume that on July 1, 2005 you want to retroactively apply a new rate of 100.00 USD to existing actual transaction rows that were created after January 1, 2005. The target rate that was previously applied to these actual transactions was 50.00 USD, thus the Variance Pricing process needs to apply the net difference of 50.00 USD. You enter the new rate in a pending status on the Rate Variance History page for the SET1 rate set. When you run the Variance Pricing process, the system inactivates the existing active rate and changes the new rate to an active status, as shown in this table:

To run Variance Pricing on the transaction row that was originally priced at a rate of 50.00 USD, select the SET1 rate set with an effective date of January 1, 2005 on the Variance Pricing run control page. The process creates a new row against the original transaction based on the net difference of 50.00 USD. In this example, you select an accounting date of July 1, 2005 on the run control page that the system applies to the new transaction row, as shown in this table:

The Variance Pricing process ignores transactions that have an accounting date (or specified date type) that are outside of the effective date range of the selected rate set.

Now assume that later you add a new SET1 rate set row with an effective date of July 1, 2006. You discover that you need to calculate pricing variances again on the output rows from the original transaction dated June 1, 2005. Because the system matches the specified date type of the priced costing row to the effective date range of the rate set to determine eligible transactions, you select the rate set effective date of January 1, 2005 for this Variance Pricing run control.

For additional information relating to government contracts and variance pricing, see Understanding Variance Pricing