Purchase requisition software: what it does and how to choose

What is purchase requisition software?

Purchase requisition software is an application where employees request purchases, code the request to a budget and send it for approval before anything is ordered. It routes each request to the right approvers, records every decision, and passes the approved request to purchasing or turns it into a purchase order.

A purchase requisition is an internal request to buy; the purchase order is the document sent to the supplier. Microsoft’s and SAP’s product documentation both describe the requisition as an internal document. A full guide to the purchase requisition itself, its fields and its process, is in preparation.

The software goes by several names: purchase requisition system, requisition tool, purchase request software or e-requisition. They describe the same job. It is narrower than procure-to-pay software, which also runs receipts, invoice matching and payment. It also stops where purchase order software starts: one handles the request and its approval, the other the order sent to the supplier. Many products do both.

A common starting point: a team leader emails a buyer to ask for two monitors. The buyer forwards the email to the budget holder, who answers three days later from a phone. By then the price has changed, nobody knows which cost centre pays, and the approval cannot be found when the invoice arrives. A requisition system keeps the request, the budget line, the approval and the later order in one record.

What does a purchase requisition system do?

A purchase requisition system follows the request from the moment it is written to the moment it becomes an order. The table lists each function, what it does and the question that shows in a demonstration whether a product does it well.

Product documentation shows how far these functions go. Microsoft Dynamics 365 Supply Chain Management, for example, separates three roles on a requisition: the requester, whose department, cost centre and spending limits drive the routing; the preparer, who creates and submits it; and one or more approvers. A requisition moves through draft, in review, approved, rejected, cancelled and closed, and it closes when the purchase order is created. In the same product, asking for a change lets the workflow resume where it stopped, while a rejection sends it through the whole workflow again.

Approval can apply to each line or to the whole request. SAP S/4HANA calls this the release procedure: with item-wise release, each item is checked against the approval rules; with overall release, the whole requisition is approved at once, so every item must meet the same criteria. Item-wise release suits a request that mixes IT equipment and office supplies, each with its own approver.

How should purchase requisition approval rules work?

Purchase requisition approval rules should follow the written delegation of authority: who may approve how much, for which category, on which budget. The software only enforces them. If the rules are not written down, every approver decides case by case and the system copies the confusion. The procurement policy is where those rules usually live.

The fictional approval matrix below shows a common shape for a mid-sized company. It combines amount bands with a category rule, so that IT and contractor requests always reach the specialist who knows the market.

1. An engineer requests a €2,400 laptop, charged to the engineering cost centre.
2. The system finds the €1,001–10,000 band and the IT category: the request goes to the engineering budget holder, then purchasing, with the IT manager in parallel.
3. The budget holder is on leave; her delegate, whose own limit is €5,000, approves.
4. Purchasing sees that the laptop is in the IT catalogue at a contract price, approves, and the system creates the purchase order.
5. Two days later the request is changed to a €3,100 model. The amount is still in the same band, but the approvals start again, because the item changed.

The last step is the one to test. Some systems keep earlier approvals when a request changes; others restart the chain. A sound rule restarts approval when the amount crosses a band or when the item, supplier or cost centre changes, and keeps it for a small correction such as a delivery address.

When do you need purchase requisition software?

You need purchase requisition software when requests and approvals no longer leave a reliable record. The signs usually show up in purchasing and in accounts payable:

• Requests arrive by email, chat and phone, and nobody can say how many are waiting.
• Approvals sit in mailboxes and cannot be linked to the order that followed.
• Budget holders learn about a purchase when the invoice arrives.
• Requesters chase purchasing for news, and buyers spend their day answering them.
• Free-text requests go to new suppliers when a contract already covers the item.
• Orders are placed before approval and approved after the fact.

A team of 20 with one buyer can manage with a shared form and a clear approval rule. A tool earns its cost when many people request, approval depends on amounts or budgets, and the approval must be proven at audit. Some purchases never need a requisition: a low-value buy on a procurement card, or a utility bill under a standing contract. The policy lists them so that requesters do not guess.

What types of purchase requisition software are there?

Purchase requisition software comes in five types. They differ in what surrounds the request: nothing, the ERP, a purchasing tool, a layer that routes every kind of request, or a full suite. The examples are taken from each vendor’s own documentation and pages, not from testing.

Disclosure: the author works as an Ivalua consultant. This comparison relies on public documentation and, where stated, first-hand use.

Lists of the top purchase requisition platforms and leading vendors are easy to find; most are published by a vendor or paid for by one. Use them to build a long list, then compare on your own scenarios. Inclusion in the table above is not a recommendation, and vendor descriptions change often. The wider market of buying tools is covered in the procurement software guide.

What do AI and automation change in requisition software?

AI and automation change how the request is written and how it is routed, not who is accountable for approving it. Vendors describe features that read a supplier’s quote and fill in the request, suggest the category and the account code, and send the request to the right channel: a catalogue item, a contract, or a buyer for quotes. Procurify, for example, says a quote can become a request in seconds; Precoro lists AI document processing in its Automation plan.

These features save typing, but their output can be wrong: a quote read with the wrong unit, a laptop coded as office supplies. Test them on 20 of your own past requests and count the corrections. Rules-based automation is more predictable: an approved catalogue request at a contract price can become an order with no buyer, as the purchase order software guide explains. How to test AI features in general is set out in what is AI in procurement, and automation tools beyond the requisition in procurement automation software.

How do you choose purchase requisition software?

To choose purchase requisition software, start from who requests, who approves and where the approved request must go next: a buyer, the ERP or a purchase order system. Then test a short list on your own cases. The steps below are shorter than a full procure-to-pay selection because the scope is the request and its approval.

1. Count requesters, approvers and requests per month, and the share of requests that are free text rather than catalogue or contract items.
2. Write the approval matrix: amount bands, category rules, budget checks, delegation, and what happens when a request changes.
3. Decide where approved requests go: to a buyer for quotes, to the ERP, or straight to a purchase order system.
4. List the master data the tool needs and who owns it: cost centres, accounts, projects, approvers and their limits, catalogues and contracts.
5. Check how the tool reaches requesters: browser, mobile, email approval, and the languages your teams use.
6. Run your test scenarios with two or three products, on a trial set up with your own cost centres and approvers.
7. Compare the cost over the contract term: subscription, users, implementation and the integration with accounting or the ERP.

Prices vary by type. In an ERP, requisitions are part of the purchasing module, so their cost sits in the ERP contract. Among dedicated tools, Precoro publishes plans billed annually from $499 a month, while Procurify prices on quote. Intake platforms and suites quote on request. Ask every vendor to price the same scope and number of users, and add the internal time to load cost centres, approvers and limits, and to keep them current when people change roles.

Which scenarios should a requisition software demo cover?

A demonstration is useful only if it follows your cases, not the vendor’s script. The scenarios below test the parts of the request where products differ most. Replace the items, amounts and roles with your own.

Ask for each scenario to run live, on a test environment with your approval rules. If the vendor cannot run a scenario, or only after future configuration, the product does not do it today. The same scenarios work in a formal tender: the RFP guide explains how to build the request and score the answers.

What is the best purchase requisition software?

No purchase requisition software is best for every organisation. A team of 20 with one buyer can live with a form and a written rule. A company with 400 occasional requesters needs routing, budgets and delegation that a dedicated tool or a suite provides. A manufacturer whose finance runs on the ERP is often better served by the ERP’s own requisitions, connected to its purchasing rules.

Decide on what your own scenarios show: whether the approval follows your policy, whether changes are controlled, and whether the approved request reaches the order without retyping. If the next step is the order itself, read the purchase order software guide; if you are replacing the whole cycle from request to payment, the procure-to-pay software guide sets out the longer method. The steps around the requisition are explained in the procure-to-pay guide.