Purchasing Requisition Software: What to Look For (and When You Need It)
A purchase requisition is a request to buy; a purchase order is the committed order that goes to the supplier. Purchasing requisition software runs the bit in between — request, approve, convert to a PO — and the best of it keeps going through receipt and invoice match. This guide covers the features that actually matter for a growing product business, the point where a spreadsheet stops being enough, and how an owned system builds the flow around how you already buy.
Quick summary: Purchasing requisition software manages the step before a purchase order — the internal request to buy something and the approval that turns it into a committed order. A requisition is a request; a purchase order is the commitment sent to the supplier. Good software routes the request to the right approver, checks it against a budget, and converts the approved requisition straight into a PO with no re-keying. The best of it doesn’t stop there: it carries the same record through goods receiving and invoice matching, so what was requested, ordered, received and paid all stay tied together. You need it when approvals are happening over email and stuck POs and maverick spend have become a regular tax — not before.
Most of the confusion around this term is one distinction: a purchase requisition is not a purchase order. Get that right and the rest of the software makes sense — it’s the tool that turns “someone wants to buy this” into “this is on order, approved, and about to arrive.” Get it wrong and you end up shopping for a procurement suite ten times bigger than the problem, or running approvals through a chat thread that nobody can audit six weeks later.
This page is about the software specifically — what it does, the features that earn their keep, and the honest point where a spreadsheet stops being enough. For how the request-and-approve process itself works as a discipline, and for what happens after the PO leaves the building, the flow links out at the right moments rather than repeating it here.
In this guide
- Requisition vs purchase order: the distinction that matters
- What purchasing requisition software actually does
- The features that actually matter
- Requisition software vs a spreadsheet request log
- When a growing business actually needs it
- Why the flow shouldn’t stop at the PO
- How an owned system builds the flow around how you buy
- FAQ
Requisition vs purchase order: the distinction that matters
A purchase requisition is an internal request. Someone in the business — a line manager, a production lead, a warehouse supervisor — needs something bought, and the requisition is how they ask for it: what’s needed, how much, roughly what it costs, and why. It’s a document that stays inside your walls. Nobody at the supplier ever sees it. Its whole job is to get a “yes” from whoever holds the budget before any money is committed.
A purchase order is the commitment. Once the requisition is approved, it becomes a PO — a formal, numbered order that goes out to the supplier and says “we will buy this, at this price, delivered here.” The PO is external and binding; the requisition was internal and provisional. The requisition asks can we; the PO says we are.
Purchasing requisition software lives in the gap between those two. It captures the request, routes it to the right person, records the approval, and then converts the approved requisition into a PO — ideally without anyone re-typing a single line. That conversion is the whole point. A requisition that gets approved and then has to be manually retyped into a separate PO template is where errors and delays creep back in, and it’s exactly the join that decent software removes.
What purchasing requisition software actually does
Strip away the marketing and the tool does one job in five moves: request, approve, convert, receive, match. The first three are the requisition’s home turf; the last two are where the good software keeps going instead of dropping the record at the PO.
Request. Someone raises a requisition — picks the items (ideally from a catalogue or a list of things you actually buy), enters quantities, a delivery need-by date, and the reason. A clean request form does more than collect data; it stops the vague “can we order some more of the blue ones” that a buyer then has to chase for a part number.
Approve. The request routes to whoever’s allowed to say yes — and who that is usually depends on how much it’s for. A £200 consumable order and a £12,000 capital purchase should not take the same path. The software holds those rules so nobody has to remember them, and it timestamps the approval so there’s a record of who signed off on what.
Convert. The approved requisition becomes a purchase order, carrying every line across untouched. This is the step that separates a real tool from a form-builder: no re-keying, no transcription errors, no “the requisition said 100 but the PO says 10.”
Receive. When the goods land, they’re booked in against the PO — the same record, now showing what actually arrived versus what was ordered. This is the goods receiving step, and whether the software reaches it or stops at “PO sent” is one of the biggest differences between tools.
Match. When the invoice comes in, it’s checked against the order and the receipt before it’s paid — three-way matching, which catches the short delivery billed in full and the price that crept between quote and invoice. A requisition tool that carries its record this far means the money at the end still ties back to the request at the start.
The tools that only cover request-approve-convert aren’t wrong — they’re just half the flow. Whether that half is enough depends entirely on what you’re buying, which the features section gets into next.
The features that actually matter
Requisition tools list dozens of features. For a growing product business, most are noise and a handful decide whether the thing earns its cost. Here’s the short list that does the work.
Approval routing that matches your real hierarchy. The single most valuable feature, and the one most often done badly. You need rules that send a request to the right approver based on amount, category, department or site — and escalate or reassign when someone’s on holiday, so nothing sits dead in an absent person’s queue. If the routing can’t mirror how your business actually delegates spending authority, you’ll end up overriding it constantly, and an approval process you override is no process at all.
Budget checks at the point of request. The best time to catch overspend is before the order goes out, not at month-end when the invoice lands. Software that shows the requester and approver what’s left in the relevant budget — and flags a request that would blow it — turns approval from a rubber stamp into an actual decision. Without this, approvers are signing off on spend they can’t see the context for.
Clean PO conversion. Covered above, worth repeating because it’s non-negotiable: the approved requisition must become a PO with no manual re-entry. Every retype is a chance for a wrong quantity, a wrong price, or a wrong supplier to slip in — and it slips in on the document that’s now legally binding.
A supplier and item catalogue. Requesters pick from things you actually buy, with known part numbers and prices, rather than free-typing descriptions a buyer has to decode. This kills a surprising amount of chasing and stops the same item being ordered under three different names.
Goods receipt and three-way match built in — or at least connected. If you take physical delivery of what you buy, a tool that stops at “PO sent” leaves the expensive half of the problem unsolved: whether the right stuff arrived, and whether the invoice matches it. This is where a lot of standalone requisition apps quietly fall short.
An audit trail. Who requested, who approved, when, and against which budget — recorded and searchable. This is what turns “I think Sam okayed it” into a fact, and it’s the thing a spreadsheet can never honestly provide.
Notice what’s not on this list: supplier scorecards, RFQ tendering, contract lifecycle management, punch-out catalogues to external marketplaces. Those are enterprise procurement features. They’re real, and for a large buying operation they matter — but for a business that raises a few dozen requisitions a week, they’re weight you’ll pay for and never use.
Requisition software vs a spreadsheet request log
Most businesses start with a shared spreadsheet or an email thread for purchase requests, and for a while it holds. The question is what specifically breaks as volume grows — because “it feels messy” isn’t a reason to spend money, and the failures are concrete.
| Spreadsheet / email requests | Purchasing requisition software | |
|---|---|---|
| Routes to the right approver by amount/category | No — sender decides, or guesses | Yes — rules-based, automatic |
| Escalates when an approver is away | No — request sits until chased | Yes — reassign or escalate |
| Checks the request against a budget | No | Yes, at point of request |
| Converts to a PO without re-keying | No — retyped into a template | Yes — carries every line across |
| Audit trail of who approved what, when | Fragile — buried in email, or overwritten | Yes — timestamped and searchable |
| Prevents maverick / off-process spend | No — nothing stops a direct order | Yes — no requisition, no PO |
| Links request → PO → receipt → invoice | No — four disconnected places | Yes — one record end to end |
| Cost / setup for very low volume | Effectively free | Overkill until volume justifies it |
The pattern the table shows: a spreadsheet is fine at capturing that a request happened, and hopeless at everything that makes a request safe — routing it correctly, checking it against money, proving it was approved, and stopping the spend that skips the process entirely. Those aren’t nice-to-haves; each one is a specific way a request log leaks. And the last row is the honest counterweight: at genuinely low volume, none of those leaks costs enough to justify a system yet.
When a growing business actually needs it
The honest answer isn’t a headcount or a revenue figure — it’s a set of symptoms. You need purchasing requisition software when the approving has become the bottleneck, not the buying. A few signs that the spreadsheet has run out of road:
- Approvals live in email, and they get lost. Requests sit unanswered because they went to the wrong person, or the right person was away and nothing reassigned. Orders are delayed not because the goods are slow but because the “yes” is.
- Maverick spend is normal. People order directly with the supplier and sort the paperwork later, because the official route is slower than just phoning it in. Every one of those is spend that skipped budget control entirely.
- Nobody can answer “who approved this?” An invoice lands for something nobody remembers sanctioning, and the trail is a scroll through six weeks of email that may not exist.
- The same thing gets ordered twice — or under three different names — because there’s no catalogue and no visibility of what’s already been requested.
- Budgets are blown before anyone notices, because the only place spend gets checked against budget is after the fact, in the accounts.
- Re-keying requisitions into POs is a job someone does, with the transcription errors that come free with it.
If you recognise three or more of those, the request process has become a leak, and a tool that routes, checks and converts will pay for itself in recovered time and caught overspend. If you recognise none of them — you raise a handful of requests a month, one approver signs them, and they turn into orders without drama — then building or buying software for it is solving a problem you don’t have yet. The steer we give across the board holds here: switch when the leak outgrows the fix, not before.
Why the flow shouldn’t stop at the PO
Here’s the trap in shopping for requisition software as a standalone thing: the requisition is the start of a chain, and the money leaks at the end of it. A tool that nails request-approve-convert and then hands you a PO and walks away has solved the visible half of the problem and left the expensive half open.
Think about where the spend actually goes wrong. The requisition was approved correctly, the PO was clean, it went to the supplier — and then the delivery came up short, and the invoice billed for the full amount, and it got paid because nobody held the invoice against what actually arrived. None of the requisition software’s careful approval routing helped, because the record ended at “PO sent” and the goods received note lives somewhere else entirely.
That’s why the receive-and-match steps belong in the same flow as the request-and-approve steps. When the same record carries all the way through, the chain closes: what was requested is tied to what was ordered, is tied to what arrived, is tied to what got paid. Break the chain at the PO and you’ve bought a very tidy way to approve spend that you then can’t verify. A purchase order tracking system is the piece that keeps the order visible from sent to received, and it’s the natural extension of requisition software rather than a separate purchase — the two are the front and back halves of one flow.
How an owned system builds the flow around how you buy
The reason so many businesses end up unhappy with off-the-shelf requisition software is that it makes them buy the way the tool assumes, not the way they actually operate. Every business has its own quirks in how spending gets authorised — a site manager who can approve up to a limit, a category that needs a second sign-off, a supplier who’s on standing agreement so their orders skip a step. Generic tools flatten those into whatever workflow the vendor designed, and you spend the first three months bending your process to fit the software.
An owned, right-sized operations system inverts that. The requisition form asks for what your buyers actually need to specify. The approval routing encodes your real delegation of authority — the limits, the exceptions, the standing agreements — rather than a vendor’s idea of a hierarchy. The catalogue is your suppliers and your parts. And critically, the record doesn’t stop at the PO: it carries through goods receipt and three-way matching, so the same system that captured “we’d like to buy this” is the one that later confirms “it arrived, it matched the invoice, it’s paid.” One record, one flow, no join between four disconnected tools.
This is squarely the gap OpsMavix builds for — businesses too messy for spreadsheets but not ready for a full ERP, where the request, the approval, the PO, the receipt and the invoice already happen but live in five places that never talk. The value isn’t a slicker requisition form; it’s the flow being whole, so the money you approve at the start is still traceable at the end.
FAQ
What is the difference between a purchase requisition and a purchase order?
A purchase requisition is an internal request to buy something — it stays inside your business and its job is to get budget approval before money is committed. A purchase order is the approved, formal order that goes out to the supplier and commits you to the purchase. The requisition asks whether you can buy; the PO tells the supplier to ship. Purchasing requisition software manages the requisition and its approval, then converts it into a PO.
What does purchasing requisition software do?
It runs the steps from a spending request to an approved order: it captures the request, routes it to the right approver based on rules like amount or category, records the approval, and converts the approved requisition into a purchase order without re-keying. The better tools keep the same record going through goods receipt and invoice matching, so what was requested, ordered, received and paid all stay tied together.
What features matter most in requisition software?
Approval routing that mirrors your real spending hierarchy, budget checks at the point of request, clean PO conversion with no manual re-entry, a supplier and item catalogue, an audit trail of who approved what and when, and — if you take physical delivery — goods receipt and three-way matching. Enterprise features like tendering and contract lifecycle management are usually more than a growing business needs.
When does a business need purchasing requisition software?
When getting permission to buy has become the slow, leaky part of the process — not the buying itself. The signs are concrete: approvals lost in email, maverick spend that skips the process, nobody able to answer “who approved this?”, the same item ordered twice, budgets blown before anyone notices, and requisitions being re-keyed into POs by hand. If three or more of those are normal, the request process has become a leak worth closing. If none are, a spreadsheet is still fine.
Can I run purchase requisitions in a spreadsheet?
For low volume, yes — a shared sheet or email thread captures that a request happened. It breaks on everything that makes a request safe: it can’t route to the right approver, can’t escalate when someone’s away, can’t check the request against a budget, can’t stop off-process spend, and can’t give you a reliable audit trail. When those gaps start costing real money, it’s outgrown its usefulness.
Should requisition software include goods receipt and invoice matching?
If you take physical delivery of what you buy, ideally yes. A tool that stops at “PO sent” leaves the expensive half unsolved — whether the right goods arrived and whether the invoice matches them. Keeping the record through receipt and three-way matching means the money at the end still ties back to the request at the start.