Understanding Limits
Government contractors bill and recognize revenue for their contracts according to terms and conditions specified by the government. Once funding is received for a contact, the contractor may bill or recognize revenue for a specified amount over the duration of the contract within a specified date range (referred to as the Period of Performance, or POP). Although any costs incurred during the completion of the contract must be tracked and managed, the contractor may only be able to bill or recognize revenue for a portion of those costs depending on the terms of the contract. PeopleSoft Contracts uses limit processing to enable you to set limits on the amount billed, revenue recognized, or fees processed for a government contract, as well as to enable you to set limits on specific transactions (such as labor, materials, or travel) that occur against a government contract.
This section discusses:
Funding and revenue limits.
Transaction limits.
PeopleSoft Contracts enables you to define funded limits and revenue limits for your rate-based contract lines and fee limits for lines associated with a fee type (cost-plus). You can define period of performance controls and determine whether the system should enforce those controls for billing and limit processing by contract line.
The funded/billing limit is the maximum amount that you can bill on your rate-based contract lines. If the Separate As Incurred Billing and Revenue option is selected on the contract, then a separate revenue limit amount is defined that represents the maximum amount of revenue that can be recognized. Fee limits are also defined for contract lines associated with a fee type (cost-plus). After you define your limits and the contract is active, you perform limit changes using amendment processing.
Funded and revenue limit amounts are visible on the contract header and line, and you can also view and manage them using the Limits Review online inquiry page. Any changes made to the limits over the life of the contract must be made at the contract line level.
The funded and revenue limit amounts defined for a government contract line represent the maximum amounts that can be billed and recognized as revenue for that line. In addition, limits can be defined for a subset of transactions on the contract line such as travel, labor, or materials. PeopleSoft Contracts enables you to set up transaction-level limits, in addition to overall funded and revenue limits. Transaction limits enable you to apply limit amounts to one or multiple subsets of transactions on a contract line.
Transaction limits consist of the following main elements:
Transaction identifiers.
Transaction limit amounts and sequence numbers.
Transaction Identifiers
Transaction identifiers can be configured and allow you to identify a subset of transactions by applying specific criteria to one or more PeopleSoft Project Costing ChartField values (source type, category, and subcategory).
You associate the transaction identifier with a contract line and then establish the limit for that transaction identifier on the line. Multiple contract lines can use the same transaction identifier, but the limit is always specific to the contract line. Transaction Limits are applied when the PeopleSoft Project Costing ChartField values on the billing or revenue transaction match the criteria defined for the transaction identifier. Billing and revenue transactions must first pass the transaction limit before they can be checked against the contract line funded and revenue limit. Transactions not meeting the criteria for a transaction identifier are included in the contract line funded and revenue limits only. These amounts are entered on the Billing and Revenue Allocation pages.
Warning! After a transaction identifier is defined and associated with a transaction limit, it should not be modified, because data conflicts may occur for any transactions already processed using the transaction identifier.
Transaction Limit Amounts and Sequence Numbers
After you have defined transaction identifiers, you assign them to the contract line. A contract line can have multiple transaction limits, each with its own transaction identifier and limit enabling you to limit revenue and billing on multiple subsets of transactions. For more complex limit processing scenarios, you can create multiple transaction limits based on the types of transactions associated with the contract line and you can set up your transaction limits to overlap one another.
When assigning multiple transaction limits to one contract line, the system uses sequence numbers to determine the order in which a limit amount is applied to a transaction. These sequence numbers are defined by you and must be unique to the contract line. In the event that you set up overlapping limits, the system uses the sequence numbers to identify which transaction limit should be processed first.
Limits processing always considers transaction level limits first, and then funded and revenue limits defined at the contract line level, when determining whether a transaction can pass limit checking. Only transactions that pass transaction limits, or transactions for which transaction limits are not applicable, are checked against overall funded and revenue limits. Depending on your limit setup, when a transaction is processed, a portion of the transaction could be determined to be over-the-limit for the transaction level limit, even though it might have been within the available overall funded and revenue limit amount.
Note: When assigning multiple transaction limits to a contract line, sequencing defines the order in which limits are applied to transactions. Because the over-the-limit transactions generated can vary depending on the order of the transaction limits, you need to carefully consider your setup and any potentially negative results from overlapping limits.
Transaction Limit Processing Examples
Transaction limits enable you to define a limit on one or more subsets of transactions on single rate-based contract line. The following example describes the steps and processing for a multilimit overlapping scenario using a transaction limit for overall travel and a second transaction limit on air travel.
Note: This example assumes that the Split to Match Limit Exactly check box is selected and the Separate As Incurred Billing and Revenue check box is deselected (so that no revenue limits exist) on the Contract.
Similar processing will happen for revenue (REV) rows if Separate As Incurred Billing and revenue check box is selected on the Contract.
Define transaction identifiers to include limits for airfare and travel:
Transaction Identifier
Source Type
Category
Subcategory
AIRFARE
TRAVL
AIR
%
TRAVEL
TRAVL
%
%
Define two transaction limits for the rate-based contract line:
Transaction Identifier
Description
Limit Amount
Use Sequence
AIRFARE
AIRFARE
10,000 USD
1
TRAVEL
TRAVEL
15,000 USD
2
An expense transaction for airfare is submitted against the contract line, and contains the following details:
Source Type
Category
Amount
TRAVL
AIR
16,000 USD
When the transaction is priced, the Limits process (CA_LIMIT) is called.
The Limits process applies the transaction to the first transaction limit amount with Use Sequence number 1, splits the transaction into two, one for 10,000 USD that passes the first limit and a second for 6,000 USD that is over the limit, and passes the over-the-limit transaction to PeopleSoft Project Costing:
Transaction Identifier
Analysis Type
Source Type
Category
Quantity
Unit of Measure
Source Amount
Source Currency
AIRFARE
OLT
TRAVL
AIR
1
EA
6,000
USD
The system applies the passed transaction to the second transaction limit amount with Use Sequence number 2, and passes the following results to PeopleSoft Project Costing:
Transaction Identifier
Analysis Type
Source Type
Category
Quantity
Unit of Measure
Source Amount
Source Currency
AIRFARE
BIL
TRAVL
AIR
1
EA
10,000
USD
The billable (BIL) row is passed to PeopleSoft Billing, and the over-the-limit (OLT) row remains in PeopleSoft Project Costing for reporting and analysis.
If the Airfare travel limit amount is subsequently increased, the OLT transaction row can be reprocessed and a BIL row is created for it if the limit is sufficient to pass the transaction.
Because the system processes transaction limits in the order specified by the Use Sequence, the system produces different results if the Use Sequence of the transaction limits were reversed. In this example, if the Travel transaction limit is set to the first Use Sequence, and the Airfare transaction limit is set to the second Use Sequence, then when the 16,000 USD airfare expense is processed, the system produces the following results:
|
Transaction Identifier |
Analysis Type |
Source Type |
Category |
Quantity |
Unit of Measure |
Source Amount |
Source Currency |
|---|---|---|---|---|---|---|---|
|
TRAVEL |
OLT |
TRAVL |
1 |
EA |
1,000 |
USD |
|
|
AIRFARE |
OLT |
TRAVL |
AIR |
1 |
EA |
5,000 |
USD |
|
AIRFARE |
BIL |
TRAVL |
AIR |
1 |
EA |
10,000 |
USD |
Because the Travel limit is specified as the first limit, the system applies the 16,000 USD transaction to that limit, which results in the system creating a 15,000 USD BIL row and a 1,000 USD OLT row for the transaction identifier of Travel. Then, the system applies the 15,000 USD BIL transaction that passed the first limit to the Airfare limit, resulting in another OLT row for 5,000 USD for the transaction identifier of Airfare, and a final 10,000 USD billable row.
The system applies the transaction to both the Travel and Airfare limits because the transaction contains the PeopleSoft Project Costing ChartField values that match the limit definitions.