When control budgets are set up, they are associated with a particular Budget Period, Business Unit (BU), Operating Unit (OU), Appropriation Index (FUND), Program Code (CLASS), Organization Code (DEPT), and General Ledger Account.

TIP: When filling out the Budget Header, the Alternate Description field should contain either; Permanent, Temporary, or Earmark.  This will distinguish the type of budget for reporting purposes. See Entering or Adjusting a Budget in Commitment Control (KK).

Once the budgets are established, transactions are budget checked, the passing or failing of the transactions depend on the remaining available budget amount and the degree of budgetary control that was set up.

The Difference between Budget Pre-Check OR Budget Check:

• Budget Pre-Check is to check transactions and budget journals online or in batch without committing transactions or budgets (posting) to the budget ledgers. Note this is an optional step but a helpful one.
• Budget Checking is done on source transactions, such as Purchasing, Accounts Payable, General Ledger, and Travel/Expense. It checks transactions and budget journals online or in batch with committing transactions or budgets (posting) to the budget ledgers. It checks against the control budgets to ensure sufficient budget amounts exist. This is a required step to continue to the next step in a process.

The following diagram provides a simplified view of Commitment Control budget checking of source transactions showing warning and error exception handling through the update of Commitment Control ledgers.

• Exceeds Budget and is over tolerance  Simply put, there is not enough money in the budget to cover the expense.
• No Budget exists  This means either the roll up level budget does not exist in the project or the expenditure coding is not correct.
• Spending authority over Budget  This occurs when a credit to expenses is posted, causing the remaining budget to be greater than the budget posted.

Commitment accounting is an integral part of budgetary control.  By establishing and tracking commitments to spend and receive amounts and by checking these amounts against budgets and organization can readily report on and control future spending and revenue.

In Commitment Control, there are two expenditure commitment types and one revenue commitment type:

• Pre-encumbrance: Amount that you expect to spend, but which you have no legal obligation to spend.  A purchase requisition is a typical pre-encumbrance transaction.
• Encumbrance: Amount that you have a legal obligation to spend in the future.  Issuance of a purchase order to a supplier is a typical encumbrance transaction.
• Recognized Revenue: Revenue that is booked and expected to receive.

When you use Commitment Control, you check both commitments and actual transactions (expenditures), against control budgets. The following procedure is a typical example of budget checking from commitment through actual transaction:

1. When you generate a requisition, use Commitment Control with budget check, to check it against the appropriate budgets and post it as a pre-encumbrance in the Commitment Control ledger.
2. When a requisition becomes a purchase order, use Commitment Control, with budget check, to liquidate the pre-encumbrance and post the purchase order amount as an encumbrance (subject to liquidation rules).
3. When the purchased good or service is delivered and the purchase order becomes a voucher, use Commitment Control, with budget check, to liquidate the encumbrance and post the expenditure.

Commitment Control uses the ledger and ledger group structure of General Ledger to store control budgets in the Commitment Control Ledger Data table. Each control budget definition defined in the system as a Commitment Control ledger group consisting of Commitment Control ledgers, each of which stores a different amount type, such as pre-encumbrance, encumbrance, and expenditure.

A college has the following budget configuration:

• An expenditure Commitment Control ledger group (CC_ORG) consisting of a budget ledger, expenditure ledger, pre-encumbrance ledger and encumbrance ledger.

That is to say, it consists of a ledger for control budget amounts and a ledger for each transaction amount type you process against your control budgets.

• A revenue Commitment Control ledger group (CC_REV) consisting of a revenue estimate budget ledger, a revenue recognized ledger, and a revenue collected ledger.

In other words, within a control budget definition, each amount type has its own bucket, and this structure reflected in the ledger group and ledger structure.

Each time a budget-checked transaction updates the Commitment Control Ledger Data table, it updates the posted total amount.

Commitment Control must be enabled for the applications whose transactions you want to check against control budgets.

When you enable Commitment Control for an application, all transactions initiated from that application are presented to the Budget Processor Application Engine process; however, the transactions that actually undergo budget checking depend on your control budget definitions, source transaction type definitions, and other setup options.

If you disable Commitment Control for an application, the Budget Processor bypasses all transactions initiated from the application as well as all transactions sent from the application directly to General Ledger to process as journal entries, even if the General Ledger tab checked in Commitment Control. The only exception occurs when the transaction from a Commitment Control-disabled application are sent to a Commitment Control-enabled application other than General Ledger. In that case, the transaction can be budget-checked in the Commitment Control-enabled application or sent from that enabled application to a Commitment Control-enabled General Ledger.

You can enable and disable Commitment Control for specific applications at any time, but disabling Commitment Control for an application during a budget period might corrupt the consistency and integrity of your data.

Carefully consider processing relationships when you determine which applications to enable or disable for Commitment Control. For example, it is impractical to enable Commitment Control for Purchasing and not enable Commitment Control for Payables. This is because encumbrances in your ledgers are never liquidated in that situation unless you perform a manual journal adjustment in General Ledger.

The Commitment Control page accessed from the Installation Options page enables the selection of a default budget date; reversal date option; and budget period liquidation for requisitions, purchase orders, and vouchers. The values for these are as follows:

• Accounting Date Default: Select to supply by default the budget date to the document accounting date.
• Current Date: When you use the current date option, entries are backed out and rebooked in period 2, leaving period 1 unchanged. Period 2 then has the net change to the document.
• Current Document Budget period: Select to supply by default liquidation to the budget period of the document processed. For example, a purchase order originally recorded as an encumbrance for budget period 1 results in the liquidation of the encumbrance in the budget period of the expenditure that might have actually occurred in and been assigned to budget period 2.

The Budget Processor uses the budget date on a source transaction, with the budget period calendar to determine the budget period of the Commitment Control budget against which the transaction is to be processed.

Among the attributes that you apply when you define control budgets are:

In Commitment Control, you can build a hierarchy between budget definitions such that a parent budget (CC_SUM) has one or more child budgets (CC_ORG).  The children budgets together represent the amount in the parent budget's bucket.

The Commitment Control information is access through either Budget Overview or Budget Reports.  Budget Overview offers a quick snapshot of budget, pre-encumbrance, encumbrance and expenditures.  There are filters that drill down.  

See Quick Reference Guide (QRG) Budget Overview in Commitment Control for Grants/Contracts/Projects.

Budget Reports offer a wider view of budget to actual information.  There are filters that drill down.  

See Quick Reference Guide (QRG)  Commitment Control Budget Reports.

You can use the Associated Budgets component to define a relationship between revenue budgets and expense budgets. Its purpose is to increase budgeted expenditure limits automatically in relationship to budgeted, recognized, or collected revenue.

You have the following options when you associate budgets:

• You can designate one or more revenue budgets to increase the available spending for an expenditure budget.
• You can designate one or more expenditure budgets to have available spending increased by a revenue budget.
• You can make the revenue available for spending when it is budgeted, recognized, or collected, or you can increase the available spending for an expenditure budget by the greater of the collected or budgeted amount, the greater of the recognized or budgeted amount, or the lesser of either combination.
• You must assign a percentage of the revenue amount up to a maximum amount or cap to apply toward the spending balance.

The Budget Processor uses this data to determine whether a sufficient spending balance is available to pass a specific transaction. If an insufficient budget balance is available for a transaction in the expenditure budget, the Budget Processor looks up the related revenue budget activity to determine whether a sufficient amount by the revenue budget can increase the available spending for the associated expenditure budget to pass the transaction. The Budget Processor passes or fails the source transaction accordingly.