Setting Purchase Limits by Department: Preventing Purchases Outside the Budget
Configuring purchase limits by department: how to build the request–limit–approval–order flow, fix rules and stop purchases that bypass the budget.

What “outside the budget” means and why it happens
“Outside the budget” is when a purchase goes through without being tied to an agreed spending plan. The available limit wasn’t checked, the cost center wasn’t assigned, existing requests weren’t taken into account, or a payment was made “urgently” and appeared in the system afterwards. Formally the money is spent, but it’s too late to manage it.
Often it seems enough to get a manager’s signature. But a signature answers “is it needed?” not “is it allowed within the budget?” A manager may not see the remaining limit for the department, future commitments from already approved requests, or that the expense should be posted to a different cost item. Without budgetary purchase control and clear rules, a signature becomes an excuse rather than control.
The process usually breaks at typical points:
- urgent purchases “for today” (replacements, breakdowns, unplanned tasks)
- services and subscriptions where payments are split and lost among small invoices
- “small” expenses that individually seem harmless but collectively blow the limit
- orders made through multiple channels (card, cash, invoice) that are not reconciled in one register
- purchases “by agreement” when the request is created after the fact
Losses are not always only financial. Deadlines slip because an invoice is stalled at payment. Conflicts arise between departments: finance “cuts”, procurement “saves urgent cases”, the department “presses because it was promised”. Trust in the rules suffers.
Short example: a department needs additional components for 1.2 million KZT. The manager approved it because the task is important. Later it turns out there are already approved requests for 900,000 KZT for the same department that are not yet paid. Together they exceed the limit and the order is frozen. So setting purchase limits by department must account not only for paid invoices but also for future commitments.
The "request-limit-approval-order" process in plain terms
To prevent purchases from going outside the budget, it helps to break the chain into four clear steps. The logic is simple: an employee states the need, the limit is checked, then approval happens, and only after that is the supplier order created.
Usually it looks like this:
- Request. The initiator describes what to buy and why. It’s important to record the amount and the department tie-in in the system, not agree verbally.
- Limit. The budget holder (CFO-equivalent or department budget owner) checks whether there is available balance in the right cost item. This is where the department purchase limits configuration does its work.
- Approval. Approvers (manager, finance, sometimes security or IT) confirm the purchase is acceptable under rules and documentation.
- Order. Procurement places the order: selects the supplier, agrees terms, monitors delivery and closing documents.
Roles should be strictly separated. The initiator is responsible for the correctness of the need and purpose. The budget owner is responsible for spending the limit. Finance is responsible for budget and cost items. Procurement is responsible for procedure and purchase terms.
Where control most often gets lost:
-
Before the request: agreed verbally, supplier already delivered, and then they try to figure out how to record it.
-
When splitting purchases: one purchase is split into several small ones to pass simplified approvals.
-
When choosing a supplier: the limit existed formally, but a change in item or price increase raises the sum and it’s noticed too late.
To make control work, requests should record at least:
- the amount (planned and, if needed, with VAT)
- cost item and cost center (department)
- purchase purpose (for whom and what for)
- required date
- justification or attachment (e.g., calculation, commercial proposal, specification)
Simple example: a department requests 20 laptops “urgently”. If the request lacks the cost item, department and purpose, the limit cannot be checked. If everything is filled, the budget owner instantly sees whether there is money for that department and item, and procurement will not place the order until control is passed.
Which limits to introduce: types and examples
Limits are not meant to "ban purchases" but to agree in advance how much and on what each department spends. Several simple types of limits work best, covering planned purchases, one-off large spends and mandatory payments.
1) Department limit (monthly or quarterly)
This is the department’s general “wallet” for the period. It covers most routine purchases: stationery, small services, equipment replacements, consumables.
Example: support has a limit of 6 million KZT per quarter. While approved/in-order requests do not exceed the limit, they follow the standard route. If they exceed it, the request is either rejected or goes to separate approval with finance.
2) Cost item (category) limit
A single departmental limit does not show what money is spent on. A limit by cost item helps keep balance: so IT doesn’t “eat” training budget, or contractor services don’t push out mandatory expenses.
Example categories: IT equipment, consumables, services (contractors), travel, training. A department has a quarterly limit of 6 million KZT, but within that: 2 million KZT for IT, 1 million KZT for services, 500,000 KZT for consumables, the rest for other items.
3) One-off purchase limit (threshold)
This rule defines “from what amount additional approvals are required.” It protects the budget from a large single purchase that can quietly consume a department’s limit.
Example thresholds: up to 200,000 KZT approved by the department manager, 200,000–1,000,000 KZT requires an added finance controller approval, above 1,000,000 KZT requires director approval and, if needed, a separate budget decision.
4) Reserve for contracts and regular payments
If services are under contract (telecom, maintenance, licenses, security, cleaning), it’s better to reserve funds in advance. Then that money won’t be spent on other requests and no surprise appears at the end of the period in the form of an obligatory invoice without a limit.
Example: a monthly payment of 450,000 KZT under a service contract. For a quarter reserve 1,350,000 KZT and this amount immediately reduces the department’s available limit.
5) Separate urgent-case limit
Urgent purchases happen to everyone: equipment breaks, critical replacements, emergency repairs. If “urgent” always breaks rules, the process stops working. The solution is a small separate urgent fund with clear conditions.
Example: 300,000 KZT per month for “urgent” needs per department. Requirements: short justification of reason, confirmation that it cannot be postponed, and mandatory post-fact assignment of a cost item (so urgent expenses don’t hide in “other”).
Preparation: data and rules without which limits won’t work
Limits often fail not because of the system but because of source data. If departments have different names, cost items are duplicated, or the budget period is unclear, any limits configuration will turn into manual fixes and disputes.
Start with a directory of departments and cost centers. Decide in advance how they are linked: one cost center per department or several (for example, IT may have separate centers for licenses, equipment and services). The main thing is one clear rule. Otherwise requests will start getting shifted between centers to bypass restrictions.
Next, standardize cost items. There should not be a situation where “stationery,” “office supplies” and “paper/cartridges” exist as different items with different limits. Fix boundaries: what belongs to the item and what does not. This reduces disputes during approval.
Agree on a budget calendar. Choose a period (month, quarter, year) and rules for carrying over balances: is unused limit transferable, who does it and when. If carryovers are done "on request", budgetary purchase control quickly becomes a series of exceptions.
It’s useful to predefine common request types and fields that must be filled. For example:
- goods (item, quantity, price, warehouse)
- services (term, result, contractor)
- travel (city, dates, basis)
- repairs (object, urgency, estimate)
Finally, define roles. One person approves the limit (usually the line manager or finance controller) and another may approve a specific purchase (for example, the department manager and procurement). Simple example: a department asks for repairs for 1.2 million KZT, quarterly limit is 1 million KZT. Without a pre-agreed rule on who can increase the limit and how, the request will hang and work will go "around" the process.
How to configure department limits: a step-by-step plan
Configuring purchase limits by department starts not with numbers but with rules: who can initiate spending, who confirms the need, and who is responsible for money. If roles are blurred, the limit will be bypassed via urgent requests or manual purchases.
-
Fix responsibilities. The initiator states the need and attaches justification. The department manager confirms the need. Procurement checks item correctness and supplier. Finance is responsible for budget and limits and for reservation rules.
-
Set limits: by department and cost items (e.g., IT, office, service, travel). Decide the period—usually month or quarter. Don’t mix one-off major projects with routine small expenses: give a project a separate item or limit.
-
Enable limit check at the request stage, not after the order. Then the employee immediately sees whether the amount passes and does not waste time on approvals that will not be paid.
-
Configure honest remaining-balance calculation: limit minus reserved requests and orders not yet paid. Otherwise an illusion of “free money” appears and the overrun is noticed too late.
-
Approve an approval matrix: who approves at which amounts and which purchase types require additional checks.
The matrix can be simple:
- within the item and limit - department manager approves
- amount above threshold - CFO or budget committee joins
- nonstandard purchase - procurement and finance must check
- urgent purchase - allowed only by exception with a reason
- project purchase - project owner approval required
Run a pilot for 1–2 departments. For example, procurement of servers or workstations: see where stop-factors appear often (wrong item, no reserve, wrong period) and fix rules before scaling company-wide.
Exception rules: so control doesn't hinder work
Hard blocking of requests when a limit is exceeded quickly breaks the process: people begin buying around the system to avoid waiting. Therefore set exception rules in advance: when the limit should block a request and when it should route the request for additional approvals.
Usually block what cannot be justified: wrong cost center, unconfirmed need, missing contract, or attempts to split one purchase into several. If the overrun is linked to a real need (price growth, emergency, new project), let the request go through an extended approval matrix with a clear reason and decision owner.
To keep exceptions manageable, add mandatory fields to the request form for “over-limit” cases:
- reason and type of exception (urgent, reallocation, one-off purchase)
- amount of overrun and the period it affects
- source of coverage (which limit is reduced or which budget is used)
- supporting document (memo, email, act)
- decision validity period (for one request or for a period)
Reallocating limits between departments should be a separate operation, not a manual edit. For example, IT transfers part of its limit to administration for new office workstations: record the amount, period, approvers and justification, then create the request.
Urgent purchases should follow an accelerated route: the initiator states reason and downtime risk, the finance controller confirms the funding source, the department manager takes responsibility, and procurement closes the documents afterwards.
Framework contracts and regular services are better handled by reserving the monthly or quarterly amount so requests don’t trigger approvals each time.
Returns, cancellations and partial deliveries should also adjust limits: a return restores available balance, a partial delivery frees the unused part, a cancellation releases the reservation and leaves an audit trail.
Control and reports: how to spot overruns in time
If limits are configured but no one regularly checks the numbers, purchases outside the budget will still occur. Good control starts with a concise set of indicators that a manager can understand in a minute.
Dashboard for managers: what to look at every time
In the department report show what helps make today’s decision:
- plan for the period (month or quarter) by cost items
- actuals: already paid or posted in accounting
- reserved: requests/orders that already consumed the limit but are not yet final
- remaining limit: how much can be spent without reapproval
- forecast to period end: actual + reserve + expected regular purchases
Show numbers in one place and one logic. Then budgetary purchase control becomes a habit, not just a one-off check in a fire.
How to catch fragmentation and other workarounds
A frequent problem is several small requests instead of one large one to pass a simplified route. To control fragmentation set detection rules: same supplier, same item, same department, short period (e.g., 7–10 days) and a final summed amount above the approval threshold.
Also maintain a set of risk signals to spot problems early:
- sharp growth of urgent purchases
- overruns in one cost item while others underspend (often a wrong item or goal swap)
- orders without a linked request or without reservation
- spikes of canceled and recreated requests (often a way to tweak amounts)
- unusually frequent small purchases from one supplier
Rhythm matters more than a “perfect” report: check overruns and reserves weekly, and close the period monthly. To trust data, assign responsibilities: initiator confirms request closure (what was received and in what volume), procurement confirms order status, finance confirms posting and cost items.
For example, if IT buys a batch of workstations for a training class, the manager should see not only payments but also reservations from approved requests. Otherwise the remaining limit will look larger than it really is.
Common mistakes and how to avoid them
The most common reason for purchases outside the budget is simple: limits exist on paper, but the system checks them too late. If control is applied only after the order is placed, managers face a fait accompli and finance has to resolve issues instead of preventing them.
Move the check to the request stage. A request should immediately show whether there is available balance, which cost center was chosen, and what happens to the limit after the purchase. Then disputed requests are stopped before commitments, not after.
Second pain point: overloaded approvals. When all requests go through the same long route, people seek shortcuts: “sign in chat”, buy “by invoice” or process through another company. Clear thresholds help: small sums approved by manager, medium by finance, large by the budget committee.
Limits also fail due to inconsistent cost items across departments. One writes “IT expenses,” another “equipment,” another “other,” and reports show different stories. You need a single item catalog and rules for who can create new items and how they map to the budget.
Another trap is lack of reservation for requests. If a request doesn’t “book” money, the available balance looks larger than reality and departments accumulate commitments simultaneously. Introduce reservation: a request reduces the available limit, and a rejection or closure returns the reservation.
Five quick checks so configuring department purchase limits doesn't become formal:
- control triggers before ordering, not after
- there are amount thresholds and short approval routes
- cost items are unified and clear across departments
- requests reserve the limit until purchase
- exceptions are documented and time-limited
And most important about “urgent”: if “urgent” always means “allowed” the process stops working. For urgent cases keep a fast but transparent path: separate reason, manager confirmation and a mandatory post-fact report the next business day.
Short checklist: are limits working or not
You can tell that purchase limits by department are working by a few signs. If 2–3 items below are not met, purchases usually start going “outside the budget” again, only later and quieter.
Quick 10-minute check
- Each request has basic fields filled: department (or cost center), cost item, amount and a clear purchase purpose. If the purpose reads “need urgently,” that’s not a purpose.
- The limit check fires twice: when submitting the request and when creating the supplier order. If the check happens only at the end, money is usually already spent.
- The remaining balance shows the real picture: it is reduced not only by paid invoices but also by reservations for active requests that are in approval or already approved.
- The approval matrix does not cause disputes: employees know who approves by amounts and items and why. If they ask each time “who should sign,” the rules are not fixed.
- There is a clear process for exceptions: urgent purchases, emergency cases, and transfers or reallocations of limits between departments are formal decisions, not chat threads.
If all items are met, add a regular control rhythm: at least once a month reconcile plan and actuals by department and top cost items. A sign of maturity is managers checking these figures themselves, not only when someone asks “when will the overrun be fixed?”.
Mini-test: find a request that is “near the limit” and follow it from submission to order. If anywhere you can skip the balance check, the limit exists only on paper.
Practical example: purchase near the limit
Finance sees that IT has 180,000 KZT left this quarter for “computer equipment.” Meanwhile the service desk urgently requests two workstations and quotes total 220,000 KZT. The limit is nearly used up, but the need is real.
A correct request is not “buy urgently” but a document that can be checked. It usually includes:
- purpose and justification (who is being hired, what tasks, what happens if not purchased)
- budget item and cost center (which department and for which item)
- amount and currency, VAT included or excluded (to avoid surprises at invoicing)
- delivery terms and desired start date
- confirmation of price comparison (at least 2–3 offers)
Then budget control kicks in: the system shows a 40,000 KZT shortfall and prevents pushing the order through. Instead of bypassing, there are two practical options. First, change the specification to a cheaper one if it does not affect work. Second, request a limit reallocation.
A reallocation is recorded as a separate decision: from which item we transfer (e.g., from IT “consumables” where savings are expected), where to, for what amount and period. Usually IT manager and finance controller approve it, and if the amount is above the threshold the CFO also signs. This is practical configuration of department purchase limits: money moves transparently, not around the rules.
Result: the request is approved, the order is placed, the needed cost item limit updates immediately, and reports show why the change happened and who approved it. This reduces conflicts and removes purchases outside the budget without extra bureaucracy.
Next steps: how to implement and sustain the process
Start with reality: map how purchases happen today. Who submits requests, who habitually approves, where urgent purchases appear, and at what stage budget control is lost. It helps to analyze the last 20–30 purchases and break down their routes, including bypasses (corporate card, “we’ll formalize it later”).
Then choose 1–2 problem areas and apply changes there. Often these are services (hard to compare prices), urgent purchases and small buys that together create a big hole in limits.
To lock the process in, agree the limits matrix and authorities with finance and department heads. It’s important to agree not only on numbers but on rules: which cost center is chosen, what counts as mandatory justification, who can raise a limit and for how long.
A pilot plan for 2–4 weeks works well:
- assign a process owner (finance-control or procurement) and a responsible person from each department
- decide who tests scenarios (normal request, urgent, over-limit, adjustment)
- run short training for requesters and approvers (15–20 minutes with examples)
- record who approves pilot changes and in what timeframe
After the pilot, formalize the rules: update the regulations, include the limit check in approvers’ daily routine and hold a regular review of deviations (e.g., weekly for 30 minutes).
If procurement volume is large or you need to link limits with accounting, requests and systems, consider automation with a system integrator. For example, GSE.kz as a technology vendor and system integrator can help integrate corporate systems and infrastructure (workstations, servers) so control is based on stable processes and transparent data rather than manual reconciliations.
FAQ
What does “purchase outside the budget” mean in practice?
Usually it means the commitment appeared before checks were made: a payment was made “urgently,” an order was placed without a request, or documents were entered into the system retroactively. As a result, the budget is already spent and the limit and cost item could not be verified in time.
Why doesn't a manager's signature prevent overspending?
A signature confirms that the purchase is necessary, but it doesn't guarantee there is available budget in the right cost item or department. Often the approver does not see already approved but unpaid requests, so a “yes” now can lead to an overrun later.
At which stage should the limit be checked?
It's best to check limits at the request stage and then again when creating the supplier order. If control happens only before payment, the obligation is usually already created and the system becomes a brake rather than a management tool.
Which fields in a request are mandatory for limits to work?
At minimum: department or cost center, cost item, amount (clearly indicated whether VAT is included), purpose of the purchase and the required date. If any of these fields are missing, the limit either cannot be checked or someone will guess and fix it manually.
How should the remaining limit be calculated: by payments or including reservations?
Use the principle “limit minus reserved”: count not only paid invoices but also requests/orders in statuses where money is effectively reserved. Then the remaining limit shows the real picture and there are fewer surprises at month or quarter end.
Which types of limits are usually enough at first?
Start with a simple set: an overall departmental limit for the period, limits for key cost items and approval thresholds by amount. Also set aside reserves for recurring contracts and a small emergency fund so crises do not break the rules.
How to handle an urgent purchase without bypassing limits?
Create a short accelerated route: record the reason for urgency and the risk of downtime, and have finance confirm the funding source. After the purchase, finalize the documents and link the expense to the correct cost item so urgent spending does not disappear into “other.”
How to spot fragmentation of purchases into small amounts?
Detect patterns: same supplier, same department, same cost item within a short period where total exceeds the threshold. The goal isn't punishment but to move such needs to the correct approval route and combine them into a single clear procurement.
How to safely reallocate limits between departments?
Treat it as a separate operation with justification, amount, period and approvers, not as an edit in a request card. That way there is a record of who moved the money and why, and requests stop getting stuck because someone tried to “fit” them into an available balance.
Where to start implementing limits if everything is manual now?
Start with a pilot on 1–2 departments and fix simple rules: unified directories of cost items and cost centers, an approval matrix by amount, reservation of funds for requests and a clear process for exceptions. If you need to connect limits, requests, payments and accounting into a single flow, consider involving a system integrator so control is based on data, not manual reconciliations.