How to set up a purchase approval process
Someone asks for a new laptop on Monday. By Thursday they're asking again, because nobody can say whether their manager approved it, whether Finance has seen it, or whether it's sitting in someone's inbox. Many purchase approvals start out like this, run on email and good intentions. This guide shows how to set up a process that people can follow, with a clear record of who approved what.
What a purchase approval process is
A purchase approval process is the set of steps a request goes through before money is committed: who approves, in what order, and when a more senior sign-off is needed.
It is different from a purchase order. A purchase order is raised after the request is approved, and it is what you send to the supplier. The approval process happens first.
Without those steps written down, each request takes a different path. One person replies in a thread. Another waits for a meeting. Finance hears about the spend after the supplier has already been told yes. A written process gives everyone the same path and a record of what was decided.
Step 1: Write down how approvals happen today
Before you design a new process, write down the one you already have. Take the last few purchase requests and trace where each one went.
For each request, note who was asked, where it waited, and what was missing when it arrived. One may have sat with a manager because the amount was unclear. Another may never have reached Finance, because someone said yes in a message.
This is often different from the written policy. The policy may say Finance sees every request. The real path may let smaller requests pass, and send only the difficult ones to Finance. Write down the real path. That is what people already follow.
If the same kind of request always stalls in the same place, that step is unclear or it is in the wrong order.
Step 2: Decide who approves, and in what order
Decide who approves, and in what order, by role rather than by name. A named person goes away, changes job, or leaves, and a process built on their name stops. A role keeps going.
For many teams the order is the requester's line manager or the budget holder first, then Finance, then a senior sign-off for larger amounts. Your team may use different roles. Write the order down, and make sure each role knows what it is deciding.
Decide who covers when an approver is away. Name the covering role in advance, such as another budget holder or a deputy in Finance, so a request does not sit because one person is out.
Good practice is that nobody approves their own request. The person who asks for the spend should not be the person who signs it off. That is a rule you set for your own team.
Keep the chain as short as your controls allow. Every extra step is another place for a request to wait. If a senior sign-off adds nothing for smaller amounts, leave it off those requests.
Step 3: Set your approval thresholds
Thresholds decide when a request needs a more senior approver. Below the line, the earlier approvers can finish the request. Over the line, it goes to someone more senior, such as a finance lead or a CFO.
These are your rules. Base them on your finance policy, your risk appetite, and who holds which budget. A tool should not choose the amounts for you, and this guide will not suggest figures for your company. The amounts further down are an example from one demo organisation, not a recommendation.
Write down exactly what happens at the threshold amount itself. A rule for requests over the amount does not include the amount. A rule for requests of the amount or more does include it. Those are different rules. Say which one you mean, in one plain sentence, next to the amount. Use one currency for each threshold. If you buy in more than one currency, write a separate rule for each, rather than mixing currencies in one line.
Review the thresholds once a year, or when the business changes. A line that was right last year can be too low or too high after what you buy changes, or after who holds the budget changes.
Step 4: Decide what every request must include
Agree what every request must include before anyone is asked to approve it. A short checklist is enough:
- what is being bought
- the supplier
- the amount
- the budget or cost centre
- the reason for the spend
- when it is needed
Add a quote or other supporting document if your policy needs one. If a fact is required, say so on the request, so people are not guessing.
When a request arrives complete, the approver can decide from what is in front of them. Nobody has to send it back to ask for the supplier, the amount, or the reason.
Keep the list short enough that people will fill it in. Start with the facts a budget holder and Finance need. Add a field only when a real request was stuck because that fact was missing.
Step 5: Make rejections and changes clear
An approver will sometimes say no. Ask them to give a reason, so the requester knows what to fix. A no on its own sends the person back to guessing. A short reason, such as the budget already being used, tells them what to change.
Decide whether a rejected request can be edited and sent again, or whether it stops and a new request has to start. Write down which one you use, so people do not invent a third path on the day.
If a request can be changed and sent on, say which steps it returns to. A change to the amount may need to start again at the first approver, because the earlier yes was for a different figure.
Step 6: Keep a record of every decision
Record who approved or rejected each request, at which step, when, and why. Later, you should be able to open the request and see the path it took, without rebuilding it from memory.
Once a request is decided, the record should stay as it was. If the reason or the approver can be edited afterwards, you can no longer rely on it.
This is what your finance team, and anyone checking your spending later, will ask for: the request, the amount, the people who signed off, and the order they did it in.
Email threads and spreadsheets are hard to rely on for this. Messages get lost in a long thread, and a spreadsheet can be overwritten. A record that stays with the request, and does not change after the decision, is easier to trust.
Step 7: Move requests out of email and tell people
Pick one place where requests are submitted and decided. That might be a shared form and a tracker, or an approvals tool. What matters is that there is one place, and that people stop keeping a second copy in their inbox.
Tell people the rules in plain language: who approves, in what order, the thresholds, and what a request must include. Put that where they will see it when they submit, not only in a document they read once.
Then stop accepting approvals by email. If a yes in a mailbox still counts, the shared place will be incomplete. For a short time, redirect people to the form, including senior people.
Check after the first month what got stuck: requests that waited, requests that arrived incomplete, and steps people tried to skip. The process is working when someone can see where a request has got to without chasing it.
Example: a three-step purchase approval in Achi
This example comes from a test run in the live Achi app on 21 October 2026, using a demo organisation. The organisation, the people, the requests and the amounts are all fictional demo data. The example is in pounds because that was the demo organisation's currency.
Demo data
We described the process in Ask Achi, in one paragraph:
When someone submits a purchase request, their manager approves it first. Then Finance reviews it. After Finance approves, requests over £10,000 go to the CFO for sign-off, and requests of £10,000 or less are complete.
Achi drafted a Process App with three stages: Manager Approval, Finance Review, and CFO Sign-off. It also drafted one rule, placed after Finance Review. Requests over £10,000 go to CFO Sign-off. Requests of £10,000 or less are complete after Finance. You confirm, then it's live.
Demo data
Three demo requests then ran through that Process App.
A £12,500 request went to the manager, then to Finance, then to the CFO, and was approved.
A £2,400 request was complete after Finance. CFO Sign-off was shown as "Not required", because the amount was not over £10,000.
A £300 request was rejected by the manager. Achi would not confirm the rejection without a reason. The requester saw the reason, and the reason was kept in the request's history.
Process Monitor shows each request's current stage and status, so you can see which request is complete and which one was rejected.
When a request reaches their stage, the assigned approver opens it in Achi to decide.
The amounts and the approvers in this example are demo choices, not a recommendation. In Achi, you set your own thresholds and decide who signs off. Achi runs the process you describe and doesn't decide your rules for you.
You can see other processes teams run in Achi, and you can see what's new in Achi as the product changes. For a closer look at this kind of approval path, see workflow approval software.
Purchase approval process FAQ
Who should approve a purchase request?
Usually the requester's line manager or budget holder first, then Finance, and a senior person such as the CFO for larger amounts. Name roles rather than people, so approvals don't stop when someone is away. Many teams also make sure nobody approves their own request.
How do you set purchase approval thresholds?
Start from your finance policy and who holds which budget. Pick the amounts at which a more senior sign-off is needed, write down exactly what happens at the threshold amount itself, and review them once a year. The thresholds are your decision, not something a tool should set for you.
What should a purchase request include?
What's being bought, the supplier, the amount, the budget or cost centre, the reason, and when it's needed. Add a quote or other supporting document if your policy asks for one. When a request is complete, approvers don't have to go back and ask for missing details.
What's the difference between a purchase request and a purchase order?
A purchase request is an internal ask to spend money, and it goes through your approval steps. A purchase order is the document you send to the supplier after the request is approved. Many teams approve requests in one place and raise purchase orders in their finance system.
How do you keep a record of purchase approvals?
Record who approved or rejected each request, at which step, when, and why, and don't let the record change once a decision is made. In Achi, each request keeps a history of its decisions, and the approver's reason for a rejection is kept with the request.