Restaurant purchase approval matrix: define authority without losing evidence

The matrix is the bridge between a purchasing policy and the decisions staff make during a busy service. Start by naming the distinct actions rather than creating one generic approver field. A request can be valid while a supplier choice needs another review; an order can be approved while receipt acceptance remains with the receiving role; an invoice can be mathematically correct while the goods receipt is unresolved. GOV.UK procure-to-pay guidance is useful for thinking about linked records and control evidence. The February 2026 procurement policy is a public example of formal authorization and governance. Neither source should be copied as a restaurant-specific legal rule. Your owner, finance lead, adviser, and system permissions define the workable matrix.

Separate the actions before assigning the people

Write the purchase lifecycle as decisions: request, specification check, supplier or alternative review, budget or account check, approval, order issue, receipt acceptance, invoice review, payment release, and exception closure. Then map each decision to a role rather than only a named employee. In a small restaurant, one person may hold several roles on ordinary low-risk purchases; if so, add a compensating review that is realistic to perform. In a multi-site operation, the matrix can distinguish site authority from central procurement or finance. Never assume that system access equals approval authority. Record the actual decision and the evidence that supported it.

• Use role names that survive staff changes, with a current person or delegate recorded for each approval.
• Keep requester, approver, buyer, receiver, invoice reviewer, and payment releaser as separate columns even when one person fills more than one.
• State whether an approval covers one line, a request bundle, a supplier, a site, a period, or a defined change.
• Require a reason when an approver edits quantity, specification, supplier, price basis, delivery point, or budget account.
• Block silent self-approval in the procedure, and record the compensating review when staffing makes full separation impossible.

Use value and risk bands that operators can explain

Value is one signal, not the whole decision. Define the value basis: line amount, total request, expected commitment, recurring period, or another measure your policy can explain. Define risk independently. A low-cost item with a critical specification, unfamiliar supplier, unusual payment route, sensitive data, or continuity impact may need more review than a routine item. A higher-value routine purchase may follow a different path. Write the band definitions in plain language, state whether tax and delivery are included in the value basis, and record the source of the price. The matrix becomes useful when a shift leader can identify the route without guessing and a reviewer can reconstruct why it was chosen.

Clearly labeled illustrative example: a two-axis decision

A repeatable purchase approval process

1. 1Capture the request. Record requester, site, product identity and specification, quantity, unit, need, required point, proposed supplier, and supporting source.
2. 2Classify value and risk. Apply the restaurant’s own value basis and risk questions. Record assumptions, price source, tax or delivery treatment, and any unusual exposure.
3. 3Route the approval. Send the request to the role required by the matrix. Record approve, amend, defer, reject, or question with person, role, date, and reason.
4. 4Issue and receive. Only the authorized ordering role issues the purchase. The receiver compares what arrived with the approved lines and records accepted, held, substituted, or missing quantities.
5. 5Review invoice and evidence. Link order, receipt, invoice, credits, and exception notes. A separate reviewer checks the commercial and documentary record before payment release.
6. 6Close or retrospect. Close resolved items, assign follow-up for open exceptions, and review emergency or compensating approvals within the local timeframe recorded by the matrix.