Commitment Control Summary for Grants/Contracts/Projects
Purpose: Use this document to control expenditures and budget checks in ctcLink.
Audience: Budget/Finance
Commitment Control enables you to control expenditures actively against predefined, authorized budgets. In particular, Commitment Control enables you to:
- Check actual transactions (such as actual expenditures) 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).
NOTE: Enter Control Budgets through the Grants/Projects/Contracts module. Budgets entered through Commitment Control do not appear in the Projects module. This creates a discrepancy between the Grants/Projects/Contracts and Commitment Control modules.
Refer to the QRG Establishing the Proposal Budget.
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 effective date. Establish control budgets at the roll-up (Object) level.
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.
However, a budget must exist. If the ChartField does not exist in Commitment Control, the transaction cannot pass budget check.
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.
| Description | Notes |
|---|---|
| Exceeds Budget and is over tolerance | Remaining spending authority (RSA) less than expenditure |
| No Budget exists | ChartField string does not exist in Budget |
| Budget date is out of bounds | Accounting date is not within project date range |
| Spending authority over Budget | Credit transaction 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.
- Budget date is out of bounds The accounting date on the transaction is before or after the project start and end date.
- 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 amounts and by checking these amounts against budgets an organization can readily report on and control future spending.
In Commitment Control, there are two expenditure commitment types:
- 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.
Note: Your actuals ledger does not store pre-encumbrance and encumbrance amounts. The Commitment Control ledgers and activity logs store pre-encumbrance and 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 Project ledger group (DETAIL_KK) 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.
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 transactions from a Commitment Control-disabled application is 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.
When defining the period for Grants/Contracts/Projects, you do not need to use a budget period calendar. The Begin Date and End Date is set up in the Grants/Contracts/Projects module.
Among the attributes that you apply when you define control budgets are:
| Control Options |
Control: Strictly control transactions against budgeted amount. Error exceptions are logged when transactions exceed the budgeted amount. Control Initial Document: Control expenditures against the initial document only. Transactions are stopped and error messages issued only if budget constraints are exceeded when the initial document is processed Transactions that pass budget checking on the initial document, such as a purchase requisition, are automatically passed on all subsequent documents, such as a purchase order or payment voucher, even if budget constraints are exceeded when they are processed. |
| 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 Processor 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 has one or more child budgets.
The project hierarchy is a grandparent (PROJECT_KK), parent (ACT_KK) and child (DETAIL_KK) relationship. 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. Refer to the QRG Budget Overview for Grants/Projects/Contracts.
Budget Reports offer a wider view of budget to actual information. There are filters that drill down. Refer to the QRG Commitment Control Budget Reports.
0 Comments
Add your comment