Purchase requisition: 8 ways to automate
I'm Liam Jones, founder of Pilla and a qualified management consultant. I've helped hundreds of businesses set up workflows, and in this article I'm going to show you eight real examples of how to set up your purchase requisitions.
I'll start from the simplest and then add some more powerful options. You can open up each template in our workflow builder playground as a starting point and experiment for yourself. If you have any suggestions or you need some help, you can email me directly.
If you're looking to automate this part of your operation, speak to an expert and we'll show you what it would take to set up.
The workflows at a glance
- #1 - The request and receipt. What is needed, why, the supplier and cost, the order, and a goods received check.
- #2 - With guidance above the checks. The same requisition, with what a complete request includes and how to check the delivery.
- #3 - With a photo of the delivery note. A photo of the delivery note or receipt, taken straight after the goods received checks.
- #4 - With signatures on the checks. The approver signs before it is ordered, and the receiver signs when it arrives.
- #5 - With earlier requests on screen. Pilla shows when this was last bought, what it cost, and how that delivery went.
- #6 - With more detail when a delivery is wrong. A short, damaged or overpriced delivery opens a step that asks what and how many.
- #7 - With a direct message about the problem. After that step, Pilla messages the person who set the requisition up.
- #8 - With a chase if it is late. A requisition that is not finished by the deadline is chased.
Article Content
What a purchase requisition covers
A purchase requisition is a request from someone in the team to buy something, sent to the person who can approve the spend before anything is ordered. It says what is needed, how many, why, which job or budget it belongs to, and roughly what it will cost. In a lot of small firms it is still a paper purchase request form left on the office desk, and it gets read whenever someone gets round to it.
Purchase order vs purchase requisition
A purchase requisition is the internal request to buy something, made before anyone has approved the spend. A purchase order is the commitment sent to the supplier once it is approved, and it is what the supplier delivers and invoices against.
The order of the two matters. NHS England's standing financial instructions say a purchase order must be raised before the commitment is made, not when the invoice arrives, and that the same person can't both ask for something and approve it. Small businesses often skip the formal order and buy on a card or a trade account, which makes the approved requisition the only record of what was agreed.
The trouble usually starts when the buying happens first. A site buys a box of fixings and some blades on the way in, and the paperwork is made afterwards, or not at all. Nobody knows which job the receipt belongs to until the card statement arrives. Every version below keeps the request, the approval, the order and the receipt on one record.
Where the goods received note fits
A goods received note is the record that what arrived matches what was ordered: the right items, the right quantity, nothing damaged, and the right price. Larger businesses raise one as a separate document. On a Pilla canvas it is the goods received check at the end of the same requisition, so the order and the delivery sit side by side.
That matters because the receipt is where most mistakes show up. A short delivery, a substituted item or a price that crept up between quote and invoice all get paid if nobody compares the delivery to the order. The goods received check makes that comparison part of finishing the request.
#1 - The request and receipt
Who it's for: Small teams where one person asks and one person buys.
What it is: A request and receipt record is one purchase requisition, on a phone, from the first ask to the delivery. It asks what is needed and by when, why and which job it is for, and the supplier and cost. Four checks come before it is sent: it is not already in stock, the supplier is one you use, there is a price for each item, and the budget is named. Then the order details, and four goods received checks: the quantity matches, the items match, nothing is damaged, and the price matches. The ask, the order and the delivery share one record.
In practice: A mechanic at a 12-bay garage needs a set of brake pads for a customer's van by Thursday. He raises the requisition at the bay, names the job number, and adds the parts supplier's price. The workshop manager orders it and writes the order number. When the box arrives, the parts counter checks it against the request and ticks the four checks. One set is the wrong size, and he writes that in the last note.
Why it works: The four checks before sending catch the common waste: buying something already on a shelf, using a supplier nobody agreed, and spending with no job attached. The four checks at the end catch the rest, and the wrong part is spotted before it is fitted or paid for.
Steps included:
- 1 text input (what you need)
- 1 text input (why and what it is for)
- 1 text input (supplier and cost)
- 1 checklist (4 checks before you send the request)
- 1 text input (order placed)
- 1 checklist (4 goods received checks)
- 1 text input (anything not right)
When to upgrade:
- Anyone on site can raise a request
- Receipts need matching to orders at month end
- Spending needs a named approver
- You buy the same things again and again
#2 - With guidance above the checks
Who it's for: Teams where anyone on site can raise a request.
What it is: The same requisition, with two guidance panels above it. The first says what a complete request includes: what, how many, by when, which job or budget, a quote or price, and a look in the stockroom first. It also says don't order until it is approved. The second says how to check the delivery: count it before signing for it, check each item and the price, and write down anything wrong before the driver leaves. Requests arrive complete the first time.
In practice: A construction firm lets every site supervisor raise requests for consumables. A new supervisor reads the first panel and adds the job number and a link to the blades she wants, which is the part people used to leave out. When the blades arrive at site, the second panel has her count the box before the driver goes.
What it adds to the previous template:
- What a complete request includes, before anyone types
- How to check a delivery, before anyone signs for it
- The same standard from every site and every person
Why it works: The usual back and forth on a request is a missing job number or price. The panel asks for them at the start, and the approver can say yes without chasing anyone.
The other common mistake is signing for a delivery before counting it. Once the driver has gone with a clean signature, a short delivery is your word against the supplier's. The second panel has the person receiving it count while the driver waits, and write any shortfall on the driver's copy. That note is what gets you a credit later.
Steps included:
- 1 guidance panel (what a complete request includes)
- 1 guidance panel (how to check the delivery)
- The seven steps from #1
When to upgrade: When receipts have to be matched to orders later (#3).
#3 - With a photo of the delivery note
Who it's for: Businesses that match receipts to orders at month end.
What it is: The guided requisition, with a photo step straight after the goods received checks. The person who received it photographs the delivery note, invoice or till receipt so the reference and the prices can be read. The receipt is attached to the request it belongs to.
In practice: A three-site café group buys most supplies on a trade card. At the end of the month the bookkeeper used to guess which receipt went with which site. Now each receipt is photographed on the requisition that asked for it, with the site and the approval on the same record.
What it adds to the previous template:
- A photo of the delivery note or receipt, straight after the goods received checks
- The prices on the receipt beside the prices on the request
- No more loose receipts at month end
Why it works: A paper receipt gets lost in a van or a pocket. A photo taken at the moment of delivery, inside the requisition, already knows which job and which approval it belongs to.
The photo has to be readable. Lay the note flat in good light and get the supplier, the date, the reference and every line price in the frame. If the goods came on two notes, take both. A blurred corner of a receipt is no better than a lost one. With the prices on the record, a later invoice that charges more than the delivery note said is easy to spot and easy to argue. At month end the bookkeeper opens the requisition, not a shoebox.
Steps included:
- The guided requisition from #2
- 1 photo (the delivery note or receipt)
When to upgrade: When spending needs a named approver (#4).
#4 - With signatures on the checks
Who it's for: Businesses where spending needs a named approver.
What it is: The photo requisition, with two signatures. The approver signs after the request checks, before anything is ordered. The person who received the goods signs at the end to confirm they checked the delivery. Every purchase has a name on the approval and a name on the receipt.
In practice: A school business manager approves every request from the site team. She reads a request for a replacement boiler pump, checks the budget line, and signs. The caretaker signs when the pump arrives and the delivery checks pass. When the auditors ask who authorised the spend, the answer is on the record.
What it adds to the previous template:
- An approver's signature before the order is placed
- A receiver's signature once the delivery is checked
- A clear line between asking, approving and receiving
Why it works: The approval signature sits before the order step, so the order can't quietly come first. The second signature ties a named person to the goods received check.
Keep the person asking and the approver different people. NHS England's standing financial instructions forbid the same officer from both requisitioning and approving, and the idea works just as well in a small firm. Two names make a quiet mistake much harder to slip through. The receiver should be whoever actually counted the goods, not whoever was nearest the clipboard. If the approver is away, name a deputy rather than letting someone sign for them.
Steps included:
- The photo requisition from #3
- 1 signature (approved by), before the order
- 1 signature (received by), at the end
When to upgrade: When the same things get bought again and again (#5).
#5 - With earlier requests on screen
Who it's for: Teams that buy the same things again and again.
What it is: The signed requisition, with a Pilla briefing on the "what you need" step. Pilla looks up earlier purchase requisitions for the same item, supplier or job. It says when it was last ordered, what it cost, who supplied it, and whether that delivery had any problems. The person asking sees last time's price before they ask.
In practice: A manufacturer reorders floor consumables, gloves and wipes, most weeks. A team leader starts a request for gloves. Pilla tells him the last order was nine days ago, from a cheaper supplier, and that it arrived two boxes short. He goes back to the usual supplier this time and says why in the request, so the approver can see the higher price was a choice.
What it adds to the previous template:
- When this was last bought, before the request goes in
- The last price and supplier, to compare
- Any problem with the last delivery
Why it works: Repeat buying is where prices drift and the same short delivery happens twice. The briefing puts the history in front of the person asking, at the moment they choose.
It also stops double orders. If gloves were ordered nine days ago and that delivery is still due, the briefing shows it before someone orders them again. And it gives the approver a reason to say yes or no. A price that has gone up since last time is fine if someone noticed and said why. It is a problem if nobody did. Over a few months the same history shows which suppliers deliver short most often.
Steps included:
- The signed requisition from #4
- 1 Pilla briefing of earlier requisitions, on the "what you need" step
When to upgrade: When a wrong delivery needs a full account (#6).
#6 - With more detail when a delivery is wrong
Who it's for: Teams that need short or damaged deliveries written up properly.
What it is: The same requisition, with a Pilla rule on the "anything not right" note. If the note says something was short, missing, damaged, the wrong item, or charged at a different price, the next step opens. It asks what is wrong, how many, and what the supplier has said. If everything matched, the step stays out of the way. A wrong delivery always comes with what you need to claim it back.
In practice: A hotel's maintenance lead receives a box of light fittings. Two are cracked and one is a different model. He writes that, the follow-up opens, and he adds that the driver noted it on the delivery note and the supplier promised replacements by Friday.
What it adds to the previous template:
- A follow-up that opens only when the delivery is wrong
- What is wrong, how many, and what the supplier said
- No extra step when everything matched
Why it works: "Some damaged" doesn't get a credit note. "Two cracked, one wrong model, replacements promised Friday" does. The follow-up asks for that detail while the box is still open.
Write it up before the driver leaves if you can. Ask the driver to note the problem on their copy of the delivery note, and photograph the damage. Suppliers often give only a short window for reporting damage or shortages, so the follow-up asks when the supplier was told and who you spoke to.
Steps included:
- The requisition with earlier requests on screen, from #5
- 1 Pilla rule on the "anything not right" note
- 1 follow-up step in the chain (what is wrong with the delivery)
When to upgrade: When the person running purchasing should hear about it straight away (#7).
#7 - With a direct message about the problem
Who it's for: The person who set the requisition up.
What it is: When the follow-up step is filled in, Pilla sends a direct message to the person who set the automation up. It says what was ordered, the supplier, the order reference, and what the follow-up says is wrong. A delivery that matched sends nothing. You hear about a short delivery before the invoice is paid.
In practice: The hotel's general manager gets a direct message about the light fittings that afternoon. She holds the invoice until the replacements arrive. The other deliveries that week, all correct, stay quiet.
What it adds to the previous template:
- A direct message after the follow-up step
- The order, the supplier and what is wrong
- Nothing sent when the delivery matched
Why it works: The person who pays the invoice is usually someone other than the person who opened the box. The message joins the two up, and only when there is something to act on.
Holding the invoice is usually the right call. NHS England's standing financial instructions say an order should only be marked as received once satisfactory goods have arrived. That matters because the order is what the invoice gets paid against. The goods received check is what shows the order was met. If it was short, pay for what came or wait for the credit note. The message carries the order reference so whoever pays can find the invoice quickly. Set the requisition up as the person who pays the bills or agrees credits, because that is who the message goes to. A correct delivery sends nothing.
Steps included:
- The follow-up requisition from #6
- 1 direct message, sent when the follow-up is completed
When to upgrade: When requests stall and nobody notices (#8).
#8 - With a chase if it is late
Who it's for: Teams where requests stall waiting for approval or delivery.
What it is: The same requisition, plus a chase if it is not finished by the deadline. Pilla messages you to get it ordered or received. A requisition finished on time does not trigger one. A stalled request is chased before the job runs out of parts.
In practice: A fleet garage has an urgent request for a part needed on Wednesday. By Tuesday afternoon it still has not been ordered, because the buyer was off. You get a message that it is not finished. The part is ordered that evening.
What it adds to the previous template:
- A deadline on the requisition
- A chase when the deadline passes and it is unfinished
- No message when it was done on time
Why it works: Requests stall quietly. An approver is off, a request sits unread, and the first anyone hears of it is when the job is ready and the part is not. The chase goes to the person who set the requisition up as soon as the deadline passes with it unfinished.
Set the deadline from when the item is needed, minus the supplier's lead time, not from when the request was raised. A part needed on Wednesday from a next-day supplier should be chased by Tuesday lunchtime. A requisition that was ordered and received in time sends nothing, so the chases you see are the ones that matter. If most of them land while a request is waiting for approval, approval is where things get stuck.
Steps included:
- The requisition from #7, including the direct message when a delivery is wrong
- 1 chase if the requisition is not finished by the deadline
When to upgrade: This is the full route. Use an earlier version if you do not want the message or the chase.
How to pick the right version
You don't need to know the product to choose. You need to know who raises requests, what proof your bookkeeper needs, and who approves spending.
Is it just you, or can other people raise a request?
If one person asks and one person buys, #1 is enough. Once anyone on site can raise one, put what a complete request includes above the checks: #2.
Do you need the receipt, or are the ticks enough?
Ticks are enough if nobody matches receipts later. But if a bookkeeper has to match each receipt to an order, add the photo: #3.
Does someone need to sign off the spend?
If any request can go straight to order, stop at #3. If a named person has to approve before anything is ordered, add the signatures: #4.
After that, the choice is about repeat buying and problems. If people buy the same things often, use #5. If a wrong delivery should open a step that collects the detail, use #6. If you want a direct message after that step, use #7. If the real risk is a request that stalls, use #8.
Related workflows
- Delivery received - checking goods in when they arrive
- Approved suppliers - keeping a list of who you buy from
- Stock count - counting what you already have before you buy more
- Maintenance fault report - logging the fault that usually starts a request for parts
- How to automate operations - the wider set of day to day records a requisition sits in
Conclusion
A purchase requisition is the request to buy something, approved before it is ordered, and the goods received check is the proof that what arrived matches. Keep both on one record and you know what was asked for, who approved it, and whether you got it. Start with the request and receipt, add photos and signatures when money needs proof, and add Pilla when you buy the same things again and again. Open any version in the playground and use it for the next thing someone asks you to buy.