Purchase approval process flowchart (approval matrix by threshold)

What the purchase approval process flowchart (approval matrix by threshold) process is

A purchase approval is the decision that a spend commitment may go ahead, made before a purchase order exists rather than after. The trigger is a purchase need with a rough value and category attached, and the chart follows one request from that point to the moment it either becomes a purchase order or is formally declined: budget availability, capital versus operating treatment, a delegation-of-authority matrix that routes by value, a check on whether competitive quotes or a preferred supplier apply, and a specialist review for categories that need one. The point of drawing it is to make a matrix that usually lives across several policy documents into one route anyone can follow.

This chart is the approval governance layer only, and it sits deliberately between two other processes rather than duplicating either of them. It does not cover how a requisition is specified, coded or returned for correction: that document mechanics belongs to the purchase requisition process, and this chart assumes a request with a value and a category already exists. It also does not continue past the purchase order into goods receipt, invoice matching or payment: that transactional chain belongs to the purchase order process, which this chart hands off to at the same step. And it is not the wider sourcing decision of make-or-buy, tender versus call-off or contract negotiation, which is the territory of the procurement process. What this chart owns is narrower and easy to skip past in a written policy: who has to sign, at what value, for what category, and what happens when a purchase does not clear one of those gates. Treat it as a starting point to adapt under your own delegation-of-authority schedule, chart of accounts and finance controls, not as a substitute for them.

Three decisions carry the process. The capex-or-opex decision sits at the very start because capital spend usually runs on a different threshold table and a slower appraisal cycle than operating spend, and collapsing the two into one chain is the most common fault in an approval matrix. The line manager decision sits in the Budget holder / line manager lane with three branches rather than two: approve, decline, or escalate to the Senior approver lane when the value is above what the manager may sign, which is what makes the chart a genuine delegation-of-authority matrix instead of a single threshold gate. The specialist-review decision sits late, in the Procurement lane, because it depends on the category recorded at the very first step, and it is the gate that keeps a purchase with a data, security or legal dimension from reaching a purchase order on a value sign-off alone.

What this flowchart covers

In this template

• Five swimlanes (Requester, Budget holder / line manager, Procurement, Finance and Senior approver (by threshold)) across six phases: request and classify, budget check, approval matrix, sourcing controls, specialist review, and decision and PO issue.
• A "Capex or opex purchase?" decision at the very start, so capital spend is logged for capital appraisal with finance before the budget check while operating spend goes straight into it, rather than both being treated as one path.
• A "Line manager approves within authority?" decision with three branches, not two: approve outright, decline outright, or escalate to the Senior approver (by threshold) lane once the value sits above what the manager may sign, which is what makes this a delegation-of-authority matrix rather than a single yes/no gate.
• Sourcing controls sitting inside the approval itself: a "Competitive quotes required above threshold?" decision and a "Preferred supplier on file?" decision, with a new supplier's risk assessment recorded before the request reaches the specialist-review gate.
• A "Specialist review required for category?" decision that routes certain categories to IT, security or legal before the request can proceed, with the sign-off recorded as its own step rather than assumed from a verbal yes.
• A "Reduce scope or cancel the request?" loop when budget is unavailable, and a single decline-recording step that every rejection path, from budget, the line manager or the senior approver, passes through before "Purchase request cancelled", so the record shows why a request stopped and not just that it did.

When to use this template

• You are documenting who has to approve a purchase before it commits spend, and want the value and category thresholds agreed once rather than argued over on every request.
• Purchase requests keep stalling because nobody agrees whether a line manager, a senior approver or a specialist reviewer has to sign next.
• You are setting or resetting a delegation-of-authority schedule and need one picture of who approves what, at which value, in which category.
• Finance or an auditor has asked how capital and operating purchases are told apart and approved differently before any commitment is made.
• You are configuring a procurement or ERP approval workflow and need the governance rules agreed on paper before anyone builds them into the tool.

How it works

1. Rename the lanes to your roles

   Replace Requester, Budget holder / line manager, Procurement, Finance and Senior approver (by threshold) with the roles that genuinely exist in your organisation. On a small team the line manager and the budget holder are usually the same person: merge those lanes rather than drawing a hand-off that never happens. Use one lane per decision-maker, not per named individual, so the chart survives someone changing job.

2. Set the capex and opex threshold tables

   Write your own figures onto the "Capex or opex purchase?" branch: what counts as capital under your accounting policy, who in finance signs the capital appraisal, and how long that appraisal typically takes. If the two threshold tables genuinely converge at some value, say so; otherwise keep them separate so a capital request is not silently approved on an operating limit.

3. Fix the delegation-of-authority values

   Replace "within authority" and "by threshold" with the actual figures from your delegation-of-authority schedule, stated in one currency. Name who the senior approver is at each band, and add a further tier only if you genuinely operate one, since every extra tier adds a hand-off and an incentive to split a request to stay under a limit.

4. State your quote and preferred-supplier rules

   Turn "Competitive quotes required above threshold?" into a stated value and quote count from your procurement policy, and list what counts as a preferred supplier on file so the branch is not a judgement call. Decide whether a new supplier's risk assessment can run in parallel with quoting or must finish first, and draw whichever is actually true.

5. Define what triggers specialist review

   Name the categories that must route to IT, security or legal: typically new software or SaaS, anything touching customer or employee data, and a contract with non-standard terms. State who signs each type of review and how long it is expected to take, so "Specialist review required for category?" is answered from a list, not from memory.

6. Decide what a decline has to record

   Set what "Record decline reason and notify requester" must capture: which gate declined it, the stated reason, and whether the requester may resubmit with changes or must raise a new request. A decline with no recorded reason is indistinguishable from a request nobody got round to, and that is what makes cycle-time and rejection-rate reporting unreliable.

7. Walk it against a real request

   Take two or three recent purchases, one that sailed through and one that stalled or was declined, and trace them through the chart. Any approver people describe that is not drawn, or a step drawn here but skipped in practice, is the finding to fix before you publish the chart as the agreed process.

Frequently asked questions

What are the steps in the purchase approval process?

A purchase need is identified and logged with a spend category and cost centre, then classified as capex or opex; capital spend is logged for capital appraisal with finance before continuing, while operating spend goes straight to the budget check. If budget is unavailable, the requester either reduces scope and resubmits or cancels the request. If budget is available, the line manager reviews it and either approves it outright, declines it, or escalates it to the senior approver when the value is above their authority; the senior approver then approves or declines. An approved request moves to procurement, which checks whether competitive quotes are required above the value threshold, obtains them if so, and checks whether a preferred supplier is on file, recording a risk assessment first if not. A decision then routes certain categories to a specialist review by IT, security or legal, with the sign-off recorded. Finance records the budget commitment and audit trail, and procurement issues the purchase order. Any decline, at budget, the line manager or the senior approver, is recorded with a reason before the request is closed.

What is the difference between a purchase approval and a purchase requisition?

A purchase requisition is the internal document: the specification, the cost centre and GL coding, and procurement's check that it is specified well enough to buy from. A purchase approval is the governance decision layered on top of it: whether the value and category clear a delegation-of-authority matrix, whether the purchase is capital or operating, whether it needs competitive quotes or a specialist review, and who ultimately signs. In practice the two run together, with the requisition carrying the data the approval matrix reads. This chart assumes a requisition with a stated value and category already exists and focuses on the approval decision itself; the requisition's own specification and coding steps are covered separately in the purchase requisition process.

How many approval tiers should a delegation-of-authority matrix have?

Fewer than most organisations start with. Two tiers cover most spend: the budget holder or line manager for everything within their signed authority, and a senior approver above a value threshold taken from your delegation-of-authority schedule. A third tier for very high value or capital spend is common, but each additional tier adds cycle time and creates an incentive to split a purchase into smaller requests to stay under a limit, which the review of the matrix itself should watch for. The figures belong in your own schedule; this template leaves them as a placeholder for you to set and review periodically rather than stating a figure that fits every organisation.

Which purchases need IT, security or legal review before approval?

The category recorded at the start of the request is what should decide it, not a judgement call made later. Typical triggers are new software or a SaaS subscription, anything that will process customer or employee data, a purchase that connects to existing systems or infrastructure, and a contract with terms that differ from your standard template. Not every purchase in those categories needs the same depth of review: a low-value tool with no data access might get a short security checklist, while a system handling personal data warrants a fuller review and legal sign-off on the contract. List your own categories and the review each one triggers, and record the sign-off as its own step so a purchase cannot reach a purchase order on a value approval alone.

How should capital and operating purchases be approved differently?

Capital purchases, generally an asset with a useful life beyond one accounting period, typically follow a separate threshold table, a finance-led appraisal, and a slower cycle than routine operating spend, because they affect the balance sheet and depreciation schedule rather than a single period's costs. Operating purchases are usually approved faster against a departmental budget. The specific line between the two, and the exact thresholds and approval bands for each, come from your organisation's accounting policy and delegation-of-authority schedule, so state them on the chart rather than assuming that generic figures apply. What matters for the process is that the split happens early, before either path reaches the shared budget check, so a capital request is never approved on an operating limit by mistake.