An Overview of Oracle PeopleSoft Commitment Control

Oracle PeopleSoft Enterprise Financial Management 9.1 Implementation

An exhaustive resource for PeopleSoft Financials application practitioners to understand core concepts, configurations, and business processes       

Understanding commitment control

Before we proceed further, let’s take some time to understand the basic concepts of commitment control.

Commitment control can be used to track expenses against pre-defined control budgets as well as to track recognized revenue against revenue estimate budgets. In this article, we’ll concentrate more on the expense side of commitment control, as it is more widely used.

Defining control budgets

An organization may draw budgets for different countries in which it operates or for its various departments. Going further, it may then define budget amounts for different areas of spending, such as IT hardware, construction of buildings, and so on. Finally, it will also need to specify the time periods for which the budget applies, such as a month, a quarter, six months, or a year.

In other words, a budget needs the following components:

• Account, to specify expense areas such as hardware expenses, construction expense, and so on
• One or more chartfields to specify the level of budget such as Operating unit, Department, Product, and so on
• Time period to specify if the budgeted amount applies to a month quarter or year, and so on

Let’s take a simple example to understand how control budgets are defined. An organization defines budgets for each of its departments. Budgets are defined for different expense categories, such as the purchase of computers and purchase of office supplies such as notepads, pens, and so on. It sets up budgets for each month of the year.

Assume that following chartfield values are used by the organization:

DepartmentDescriptionAccountDescription700Sales135000Hardware expenses900Manufacturing335000Stationery expenses

Now, the budgets are defined for each period and a combination of chartfields as follows:

PeriodDepartmentAccountBudget amountJanuary 2012700135000$100,000January 2012700335000$10,000January 2012900135000$120,000January 2012900335000$15,000February 2012700135000$200,000February 2012700335000$40,000February 2012900135000$150,000February 2012900335000$30,000

Thus, $100,000 has been allocated for hardware purchases for the Sales department for January 2012. Purchases will be allowed until this budget is exhausted. If a purchase exceeds the available amount, it will be prevented from taking place.

Tracking expense transactions

Commitment control spending transactions are classified into Pre-encumbrance, Encumbrance, and Expenditure categories. To understand this, we’ll consider a simple procurement example. This involves the PeopleSoft Purchasing and Accounts Payable modules. In an organization, a department manager may decide that he/she needs three new computers for the newly recruited staff. A purchase requisition may be created by the manager to request purchase of these computers. Once it is approved by the appropriate authority, it is passed on to the procurement group. This group may refer to the procurement policies, inquire with various vendors about prices, and decide to buy these computers from a particular vendor. The procurement group then creates a purchase order containing the quantity, configuration, price, and so on and sends it to the vendor. Once the vendor delivers the computers, the organization receives the invoice and creates a voucher to process the vendor payment. Voucher creation takes place in the Accounts Payable module, while creation of requisition and purchase order takes place in the Purchasing module.

In commitment control terms, Pre-encumbrance is the amount that may be spent in future, but there is no obligation to spend it. In the previous example, the requisition constitutes the pre-encumbrance amount. Note that the requisition is an internal document which may or may not get approved, thus there is no obligation to spend the money to purchase computers.

Encumbrance is the amount for which there is a legal obligation to spend in future. In the previous example, the purchase order sent to the vendor constitutes the encumbrance amount, as we have asked the vendor to deliver the goods.

Finally, when a voucher is created, it indicates the Expenditure amount that is actually being spent. A voucher indicates that we have already received the goods and, in accounting terms, the expense has been recognized.

To understand how PeopleSoft handles this, think of four different buckets: Budget amount, Pre-encumbrance amount, Encumbrance amount, and Expenditure amount.

Step 1

Budget definition is the first step in commitment control. Let’s say that an organization has budgeted $50,000 for purchase of IT hardware at the beginning of the year 2011. At that time, these buckets will show the amounts as follows:

BudgetPre-encumbranceEncumbranceExpenditureAvailable budget amount$50,000000$50,000

Available budget amount is calculated using the following formula:

Available budget amount = Budget amount – (Pre-encumbrance + Encumbrance + Expenditure)

Step 2

Now when the requisition for three computers (costing a total of $3,000) is created, it is checked against the available budget. It will be approved, as the entire $50,000 budget amount is available. After getting approved, the requisition amount of $3,000 is recorded as pre-encumbrance and the available budget is accordingly reduced. Thus, the budget amounts are updated as shown next:

BudgetPre-encumbranceEncumbranceExpenditureAvailable budget amount$50,000$3,00000$47,000

Step 3

A purchase order can be created only after a requisition is successfully budget checked. When the purchase order i created (again for $3,000), it is once again checked against the available budget and will pass due to sufficient available budget. Thus, once approved, the purchase order amount of $3,000 is recorded as encumbrance, while the pre-encumbrance is eliminated. In other words, the pre-encumbrance amount is converted into an encumbrance amount, as now there is a legal obligation to spend it. A purchase order can be sent to the vendor only after it is successfully budget checked. Now, the amounts are updated as shown next:

Budget

Pre-encumbranceEncumbranceExpenditureAvailable budget amount$50,0000$3,0000$47,000

Step 4

When the voucher gets created (for $3,000), it is once again checked against the available budget and will pass, as the available budget is sufficient. Once approved, the voucher amount of $3,000 is recorded as expenditure, while the encumbrance is eliminated. In other words, the encumbrance amount is converted into actual expenditure amount. Now, the amounts are updated as shown next:

BudgetPre-encumbranceEncumbranceExpenditureAvailable budget amount$50,00000$3,000$47,000

The process of eliminating the previous encumbrance or pre-encumbrance amount is known as liquidation. Thus, whenever a document (purchase order or voucher) is budget checked, the amount for the previous document is liquidated.

Thus, a transaction will move successively through these three stages with the system checking if available budget is sufficient to process it. Whenever the transaction encounters insufficient budget, it is flagged as an exception.

So, now the obvious question is how do we implement this in PeopleSoft? To put it simply, we need the following building blocks at the minimum:

• Ledgers to record budget, pre-encumbrance, encumbrance, and expenditure amounts
• Batch processes to budget check various transactions

Of course, there are other configurations involved as well. We’ll discuss them in the upcoming section.

Commitment control configurations

In this section, we’ll go through the following important configurations needed to use the commitment control feature:

• Enabling commitment control
• Setting up the system-level commitment control options
• Defining the commitment control ledgers and ledger groups
• Defining the budget period calendar
• Configuring the control budget definition
• Linking the commitment control ledger group with the actual transaction ledger group
• Defining commitment control transactions

Enabling commitment control

Before using the commitment control feature for a PeopleSoft module, it needs to be enabled on the Installation Options page.

Follow this navigation to enable or disable commitment control for an individual module:

Setup Financials / Supply Chain | Install | Installation Options | Products

The following screenshot shows the Installation Options – Products page:

This page allows a system administrator to activate any installed PeopleSoft modules as well as to enable commitment control feature for a PeopleSoft module.

The PeopleSoft Products section lists all PeopleSoft modules. Select the checkbox next to a module that is implemented by the organization.

The Enable Commitment Control section shows the PeopleSoft modules for which commitment control can be enabled. Select the checkbox next to a module to activate commitment control and validate transactions in it against defined budgets.

Setting up system-level commitment control options

After enabling commitment control for desired modules, we need to set up some processing options at the system level.

Follow this navigation to set up these system level options:

Setup Financials / Supply Chain | Install | Installation Options | Commitment Control

The following screenshot shows the Installation Options – Commitment Control page:

• Default Budget Date: This field specifies the default budget date that is populated on the requisitions, purchase orders and vouchers. The available options are Accounting Date Default (to use the document accounting date as the budget date) and Predecessor Doc Date Default (to use the budget date from the predecessor document). For example, the purchase order inherits requisition’s budget date, and the voucher inherits the purchase order’s budget date.
• Reversal Date Option: There are situations when changes are made to an already budget-checked transaction. Whenever this happens, the document needs to be budget checked again. This field determines how the changed transactions are posted. Consider a case where a requisition for $1,000 is created and successfully budget checked in January. In February, the requisition has to be increased to $1,200. It will need to be budget checked again. The available options are Prior Date (this option completely reverses pre-encumbrance entries for January for $1,000 and creates new entries for $1,200 in February) and Current Date (this option creates additional entries for $200 for February, while leaving $1,000 entries for January unchanged).
• BP Liquidation Option: We already saw that system liquidates the pre-encumbrance and encumbrance amounts while budget checking purchase orders and vouchers. This field determines the period when the previous amount is liquidated, if the transactions occur in different periods. The available options are Current Document Budget period (liquidate the amounts in the current period) and Prior Document Budget period (liquidate the amounts in the period when the source document was created).
• Enable Budget Pre-Check: This is a useful option to test the expense transactions without actually committing the amounts (pre-encumbrance, encumbrance, and expenditure) in respective ledgers. We may budget check a transaction and find that it fails the validation. Rather than budget checking and then handling the exception, it is much more efficient to simply do a budget pre-check. The system shows all the potential error messages which can help us in correcting the transaction data appropriately. Select the checkbox next to a module to enable this feature.