Commitment Control Summary for Colleges
Purpose: Use this document to control expenditures actively against predefined, authorized budgets in ctcLink.
Commitment Control enables you to control expenditures actively against predefined, authorized budgets. In particular, Commitment Control enables you to:
- Create and maintain control budgets (ENTERING BUDGET JOURNAL).
- Check actual transactions (such as actual expenditures and revenues) against control budgets (BUDGET CHECK JOURNALS AND VOUCHERS).
- Check imminent future financial obligations against control budgets (BUDGET CHECK PURCHASE REQUISITIONS AND PURCHASE ORDERS).
- Check control budget versus actual expenditures that determine residual spending authority (BUDGET OVERVIEW).
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 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.
TIP: The roles of Budget Manager and Budget Administrator can adjust a transaction that fails budget checking or adjust the budgets that the transaction failed against and budget-check the transaction again. Budget Administrators can override budget checking and allow a transaction to exceed the budget. However, a budget must exist. If the ChartField does not exist in Commitment Control, the transaction cannot pass budget check or be overridden (unless the control level is set at “Track without Budget”).
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||Remaining spending authority (RSA) less than expenditure|
|No Budget exists||ChartField string does not exist in Budget|
|Spending authority over Budget||Credit Transactions caused RSA to exceed original Budget|
- 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.
Note: Your actuals ledger does not store pre-encumbrance, and encumbrance amounts, and recognized revenue amounts. The Commitment Control ledgers and activity logs store pre-encumbrance amounts, encumbrance amounts, and recognized revenue amounts.
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:
- 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.
- 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).
- 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.
Note: The remaining available budget balance is not a stored amount, but is calculated when you run budget checking.
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.
Warning! Just enabling applications and Business Units (BU) for Commitment Control is not necessarily enough to use the functionality, because many applications have dependencies with other applications that require you to maintain integration points between those applications for valid budget checking and notification.
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.
Note: A special scenario applies when you choose this option. If the ruleset ChartField is changed between the current document and its predecessor and the two ruleset ChartFields belong to different rulesets that have different budget period calendars, the budget period of the liquidation entry does not use the budget period of the current document. Instead, the system uses the predecessor's ruleset ChartField to get the corresponding budget period calendar, and derives the liquidation budget period based on the calendar and the current document's budget date.
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:
|Control Options||Tracking with Budget: Track transaction amounts against a budget, but do not issue error exceptions unless no corresponding budget row exists. Pass if budget row exists, even for a zero amount, but issue warnings when transactions exceed the budgeted amount.|
|Budget Status||Indicates whether the budget is open, closed or on hold:
Open: The budget can still accept transactions.
Closed: The budget is closed to transactions.
You cannot enter budget journals and the budget Processor fails all transactions that affect the budget.
Hold: The budget is on hold.
The Budget Process fails any transaction that reduces the available balance, but you can enter and post budget journals.
|Budget Tolerance||The percentage variance over budget that you allow for a transaction to pass budget checking.|
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.
Important! The system performs a validation each time you post a budget journal to ensure that the total across all child budget amounts in the child budget ledger does not exceed the parent budget amount. However, if more than one child definition is associated with a parent budget definition, the system does not add child budget amounts across child budget definitions to arrive at a total child budget amount to validate against the parent budget. Rather, the system views each child budget definition as the "same money" in "different slices," and it only validates the child budget amounts within the child budget definition for the budget journal. Therefore, if you have more than one child budget definition associated with a parent budget definition, and those child budget definitions do not represent the "same money," your child budgets can exceed your parent budget.
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.