Equipment has already been ordered and received when finance first sees the budget overrun in the invoice. Changing the purchasing decision is now harder. The controller should check available funds when a requisition is submitted and define a separately approved route for urgent expenses that exceed the limit.
The Cost of Post-Invoice Budget Checks
Uncontrolled requisitioning allows operational teams to make financial commitments before the finance department has visibility into the transaction. Consider an illustrative scenario: a maintenance manager needs a replacement motor for a packaging line. The manager contacts a supplier, agrees on a quote for $45,000, and requests immediate delivery. The supplier ships the part, and fourteen days later, the invoice enters the accounts payable queue.
In this scenario, the purchasing decision has already been carried out before the budget check. Payment terms and the legal basis of the obligation require separate checks against the contract and delivery records. The operating problem is that finance learned of the expense too late to compare it with other requests. The controller must now seek budget reallocation or reconsider the timing of other spending.
Accounts payable faces a choice: delay payment and strain the supplier relationship, or process it and violate financial controls. Post-invoice checks transform budget control into a reactive accounting exercise. When budget consumption is recorded only after the liability is recognized, the organization loses the ability to prevent cash flow disruptions. The controller manages the consequences of spending decisions rather than governing the decisions themselves.
Shifting Control to the Requisition Stage
To regain control over cash flow, the budget check must move to the earliest point of operational intent: the purchase requisition. When a manager submits a requisition, the financial system evaluates the available budget funds and records the request as a preencumbrance. This calculation temporarily reserves the funds in the budget control module before any external document is generated.
The formula for available funds subtracts actual expenditures, existing encumbrances (approved purchase orders), and preencumbrances (pending requisitions) from the total allocated budget. If the new $45,000 requisition exceeds the remaining available budget, the system blocks the submission. The manager cannot generate a purchase order, and the procurement team cannot contact the supplier until the financial control is satisfied.
The time span used to evaluate available funds affects the strictness of the control. If an organization creates budgets by fiscal period and requires detailed control, it configures the system to evaluate funds on a fiscal-period-to-date or quarterly basis. Using an annualized amount might hide short-term overspending. Furthermore, when purchase requisitions are configured to automatically create purchase orders upon approval, the system must run this creation as an asynchronous batch job. Otherwise, the preencumbrance budget check during requisition release can trigger a loop that degrades system performance.
Sources: [1]
Configuring Hard Limits and Tolerances
Organizations must decide how strictly to enforce these limits within their financial systems. A system can be configured to allow processing with a warning, allow processing up to a specific threshold percentage, or strictly prevent over-budget processing. For standard operational expenses and capital expenditures, strict prevention provides the most reliable control.
When the available budget is exceeded under a strict prevention rule, the system displays an error message and halts the transaction. No tolerance or grace percentage is applied. This forces the department to reduce the scope of the request, delay the purchase to the next fiscal period, or formally seek additional funding. Budget control rules use specific financial dimensions, such as department or cost center, to apply these settings selectively.
Alternatively, the system can prevent processing only at an owner-defined over-budget threshold. For illustrative purposes, if a budget amount is $100,000 and the threshold is set to 110%, a spending amount of $109,000 is allowed, but $111,000 is blocked. Tolerances accommodate freight or utility accounts where minor price fluctuations are expected, but they weaken CAPEX control. Allowing over-budget processing with only a warning relies on manual internal audit processes to track overrides.
| Configuration Option | System Behavior | Operational Use Case |
|---|---|---|
| Allow over budget processing | Displays a warning but allows the transaction to continue based on user permissions | Controlled exceptions for specific executive user groups |
| Prevent processing at threshold | Blocks processing only after a defined tolerance percentage is exceeded | Accounts with predictable minor price fluctuations, like freight |
| Prevent over budget processing | Blocks any transaction that exceeds available funds | Strict departmental budget enforcement and CAPEX control |
Sources: [1]
Managing Exceptions and Budget Transfers
Implementing a strict block creates an operational challenge: handling broken production equipment that requires emergency capital expenditure. The solution is not to bypass the budget check or grant override permissions to operational managers. Instead, the organization uses documented budget transfers.
In the illustrative scenario, the manager whose $45,000 requisition was blocked initiates a budget transfer request to move funds from a surplus maintenance account. Budget transfer rules dictate that such movements require specific workflow approvals based on the budget code. If a user creates a document using a transfer budget code, the budget balances are not updated if the transfer rules are violated or the workflow is incomplete.
The requisition remains blocked until the executive override is granted, the transfer is completed, and the budget balances are officially updated in the system. This maintains the integrity of the automated control while providing an auditable path for business emergencies. The system enforces the rule that no commitment can be made without corresponding available funds, even if those funds must be moved from a different cost center.
Sources: [2]
Automating the Requisition Workflow
Implementing this control requires a structured interface between the operational team and the core financial system. Intecracy Group's Scriptum, a low-code platform designed for automating processes, forms, and integrations, can orchestrate the purchase requisition workflow before the data reaches the ERP.
A pilot can implement this proposed scenario: the manager selects items and cost centers in a form, and a configured integration requests available funds from the ERP. A negative result stops submission and offers a revised amount or a budget-transfer approval route. This is a requirement for the specific implementation: API availability, operation support and failure behavior must be verified rather than assumed to be ready-made Scriptum functionality.
Keeping the form outside the ERP can simplify routing changes when the required operations are available through an agreed interface. The finance system remains the source of budget data. Disconnect the integration during acceptance testing: submission should remain blocked until the current balance is confirmed. Also test concurrent requisitions so they cannot consume the same available balance.
Sources: [3]
Separation of Duties and Auditability
Enforcing budget limits at the requisition stage strengthens the separation of duties. The person requesting the purchase cannot be the same person who authorizes a budget transfer or approves an emergency override. By locking the budget control at the system level, finance ensures that operational managers cannot unilaterally increase their spending power.
Every time a requisition is blocked, the system generates a log entry. If the manager proceeds with a budget transfer, the workflow captures the timestamp, the justification provided, and the digital record of the executive who approved the transfer. Furthermore, completed budget register entries cannot be reopened for edits. If budget data must be adjusted, a new budget register entry must be created, preserving the historical record of the original allocation and the subsequent transfer.
Auditors can verify that no purchase orders were generated without sufficient available funds, and that all exceptions followed the documented corporate policy. The controller's next step is to map all purchasing channels, ensure no commitments bypass the preencumbrance check, and configure the financial system to prevent over-budget processing for capital expenditure accounts.
Sources: [2]
Action checklist
- Map all operational purchasing channels to ensure no commitments bypass the requisition stage.
- Configure the financial system to calculate available funds including draft preencumbrances.
- Set the budget control rule to 'Prevent over budget processing' for standard departmental accounts.
- Define budget transfer rules and routing for emergency capital expenditure approvals.
- Test the API integration to ensure the system fails closed and blocks submission if the connection drops.
Questions and answers
Does a preencumbrance permanently reduce the budget?
No. A preencumbrance temporarily reserves the funds during the requisition stage. Once the purchase order is created, it converts to an encumbrance, and finally to an actual expenditure when invoiced.
Can we apply strict limits to some departments and tolerances to others?
Yes. Budget control rules can be defined using specific financial dimensions, allowing you to set different thresholds or strict prevention rules for different departments or cost centers.
What happens if a budget transfer request is rejected during the executive override?
The budget transfer is not executed, and the original purchase requisition remains blocked from submission.