Creating a Procurement Approval Matrix: Thresholds, Roles and Delegation

Procurement often stalls not because finding a supplier is difficult, but because it is unclear who can authorize the expenditure. Is the line manager’s approval sufficient? Does finance need to be involved? What happens if the person responsible is on leave? If these questions have to be answered separately for every requisition, the process becomes slow and dependent on individuals.

A procurement approval matrix translates these questions into predefined decision rules. A well-designed matrix, however, is more than a table of thresholds: it connects the amount, cost center, type of purchase and areas of responsibility. The template below helps turn this into a workflow that can also be executed in procurement software.

1. First, define what is being approved

Before setting thresholds, clarify exactly what each participant is approving. The justification for a business need, budget availability, supplier suitability and authorization to commit funds are not the same decision. If they are all hidden behind a single “Approve” button, it becomes difficult to establish later who took responsibility for what.

• Requisition approval: is the product or service necessary for the business task?
• Budget check: is sufficient budget available?
• Specialist review: does the selection meet requirements such as IT, legal or quality standards?
• Commitment authorization: who may authorize the purchase order or entry into a contract?

Confirming receipt and approving the invoice are related but separate process steps. Authorizing a purchase order does not, in itself, confirm that delivery has been completed satisfactorily. The scope of the matrix should therefore be defined at the very start of the design process.

Reviewing a few actual procurement cases is a useful starting point. An office supplies order, an annual software subscription and an investment in machinery typically require different decision paths, even when their amounts are similar.

2. Thresholds: simple bands, clear calculations

A threshold only works reliably if everyone understands the amount in the same way. Specify whether values are net or gross, the currency, the currency conversion rule and the aggregation method. For multi-year contracts, it is particularly important that the decision level is not determined by a single monthly invoice.

Illustrative threshold template

The bands below are planning examples only, not general recommendations. They must be tailored to the company’s size, risks and internal rules for authorizing commitments. All amounts in this example are net values in Hungarian forints.

• Above 0 HUF, up to 100 000 HUF: the cost center owner decides; the result of the budget check must be recorded.
• Above 100 000 HUF, up to 500 000 HUF: after approval by the cost center owner, the procurement owner checks the purchasing terms.
• Above 500 000 HUF, up to 2 000 000 HUF: the preceding controls are followed by approval from the head of finance.
• Above 2 000 000 HUF: additional approval is required from a senior executive designated in the internal policy.

The bands should neither overlap nor leave room for ambiguity between them. Exactly 500 000 forints, for example, falls into the second band in this template. Set separate rules for handling zero-value items and special contracts.

Related purchases must be aggregated in accordance with internal policy. Splitting a project into several smaller requisitions must not bypass a higher decision level. For subscriptions, classification may be based on the total fee for the committed period; for foreign-currency requisitions, it may be based on a forint value tied to a specified date and exchange-rate source.

In addition to the amount, define overriding conditions. An out-of-budget purchase, a new supplier, an advance payment or a service with access to sensitive data may warrant additional controls even at a low value.

3. Roles and multi-level approvals

Where possible, build the procurement approval matrix around roles, not individual names. The rule specifies that the owner of the relevant cost center makes the decision, while the organizational assignment identifies the current individual. This means a change of manager does not require rewriting the entire process logic.

At each decision point, specify what the decision covers, the required data, the permitted outcomes and the conditions for proceeding. “Return for clarification” should not be the same as rejection: the former allows the requisition to be corrected, while the latter may close the request.

Sequential or parallel approval?

Sequential approval is required when one decision is a prerequisite for another. For example, final authorization to commit funds may follow acceptance of the business justification. Parallel review can be used when legal and IT reviews can be conducted independently. In such cases, clarify whether approval from every designated participant is required.

Preventing self-approval should be a fundamental rule. If the requester is also the cost center owner, the task should be routed to another authorized person designated in advance. Rules must also specify whether two decision steps can be combined when the same person holds both roles. Where independent oversight is required, having the same person click twice is not sufficient.

4. Delegation: tasks can be handed over, but controls must remain

Delegation is not simply forwarding an email; it is granting authority limited in duration and scope. Define who can configure it, when it takes effect, which tasks it covers and when it expires. Planned leave and unexpected absences can be handled separately.

• Duration: start and end dates, with automatic reversion on expiry.
• Scope: the organizational units, procurement categories and decision steps covered.
• Spending threshold: delegates should only make decisions with appropriately delegated authority.
• Conflict of interest: delegates must not approve their own requests.
• Audit trail: record who made the decision, on whose behalf and under what authority.

Decide in advance what happens to tasks already in progress. Will they be transferred to the delegate, or will the delegate only receive new requests? Either approach can work, but no task should be left unassigned. If no delegate has the appropriate authority, the designated fallback decision path should be triggered, rather than automatic approval.

5. Deadlines and escalation: requesters should not have to chase decisions

Approval deadlines must also specify how time is calculated. Is it measured in working hours or calendar hours? When does the clock start? Does it pause when the requester is asked to provide missing information? Without these details, the same deadline can be interpreted differently.

One illustrative rule could allow two working days for a decision. A reminder is sent after one working day, and the process owner is notified when the deadline expires. If necessary, the task can then be reassigned to another predefined decision-maker with the appropriate authority.

Escalation notifications and the transfer of decision-making authority are two separate events. Receiving an overdue notification does not make someone an approver. Nor should exceeding a deadline constitute tacit approval.

Urgent requests should have a separate route that requires justification. This may involve shorter deadlines or parallel reviews, but not an unrestricted exemption from controls. If the amount or subject of the purchase changes materially in the meantime, the system must reassess the required approval level.

6. From the matrix to a working procurement workflow

When selecting procurement software, checking whether it has an approval feature is not enough. The question is whether the company's specific rules can be modeled, tested and subsequently maintained. These business decisions should also be the starting point for designing an xFLOWer-based process, rather than just the fields on the requisition form.

1. Data model: amount, currency, cost center, category, budget status, supplier and justification.
2. Decision rules: spending thresholds, overriding conditions, roles and approval sequence.
3. Exception handling: delegation, requests for missing information, urgency, rejection and changes.
4. Auditability: retention of decisions, timestamps, comments and the rule version applied.

Before going live, test threshold boundaries, foreign-currency requests, missing approvers and self-approval conflicts. Also test cases where a change moves a request into a higher spending band. Do not just examine the standard scenario: bottlenecks typically arise in exceptional cases.

The matrix should have a designated owner and version-controlled change management. When rules change, decide whether cases already in progress will continue under the previous rules or require reassessment. The process can later be refined based on turnaround times, returned requests and escalations.

Summary and next step

An effective procurement approval matrix clarifies who can decide on what, up to which spending threshold and under which conditions. Delegation ensures continuity, escalation addresses delays, and audit trails make accountability traceable.

Would you like to turn your approval rules into a working workflow? Consult the xFLOWer team and bring a few typical procurement cases, along with some problematic ones. These provide a useful foundation for developing decision rules and test scenarios tailored to your company.

This article is part of our comprehensive guide: Procurement Software: A Complete Guide from Selection to Efficient Operations