Purchase requisition versus purchase order
This is the most common question about the document and the one an approver most needs answered. The two are sequential rather than alternative, and each controls something the other cannot.
| Purchase requisition | Purchase order |
|---|---|---|
What it is | An internal request asking permission to buy | An external commitment to buy from a named supplier |
Who sees it | Internal only: requester, manager, finance, procurement | The supplier, as well as the internal teams |
Who raises it | The person who needs the goods or service | Procurement, once the requisition has been approved |
Legal status | Not binding. It is a request that can be refused | Legally binding once the supplier accepts it |
What it controls | Whether the purchase should happen at all | What was agreed: price, quantity, terms and delivery |
When it is created | Before any commitment, and usually before supplier contact | After approval, once source and price are settled |
Also called | Indent, purchase request, requisition slip, PR | PO, order |
Typical failure | Raised by email, so nothing checks budget or policy | Raised without a contract price, so matching catches nothing |
The practical consequence is about sequencing rather than paperwork. A requisition asks whether the purchase should happen at all, which is a question that becomes considerably harder to ask once a purchase order has already been sent to a supplier.
This is also why requisitions raised by email fail as a control. Nothing in an email thread checks the budget, applies a threshold or leaves an audit trail, so the approval becomes a matter of whoever replied rather than of policy.
What a purchase requisition form should contain
Most published guidance names four or five fields, which is enough to record a request and not enough to approve one properly. The set below is what a form needs to survive both an approver's scrutiny and an auditor's.
Field | Why it is there | Required? |
|---|---|---|
Requisition number | Unique reference for tracking and audit, normally generated by the system rather than typed | Always |
Requester name and department | Establishes who is asking and which budget the spend belongs against | Always |
Date raised and date required | Drives urgency, and the required date determines whether expediting or a faster route is needed | Always |
Item description and specification | What is actually wanted, in enough detail that procurement can source it without a follow-up call | Always |
Quantity and unit of measure | Prevents the classic error of ordering ten boxes when ten units were wanted | Always |
Estimated unit price and total value | Determines which approval threshold applies, so an estimate is far better than a blank field | Always |
Budget code or cost centre | Where the spend lands, and what the budget check is validated against | Always |
General ledger account or expense category | Coding correctly at source avoids a reclassification exercise at month end | Always |
Business justification | The why, which lets an approver reject on merit rather than only when budget has run out. The field most often missing. | Always |
Preferred or suggested supplier | A useful signal from the requester, but it must not bind procurement to that supplier | Optional |
Contract or catalogue reference | Links the request to an already agreed price, which is what makes automated conversion safe later | Where one exists |
Delivery location and recipient | Prevents goods arriving at the wrong site with nobody expecting them | Always |
Attachments: quote, specification or drawing | Supports the estimate and shortens the sourcing step considerably | Where available |
Approver and approval date | The audit trail showing who authorised the request and when they did it | Always, system captured |
Linked purchase order number | Closes the loop from request through to commitment for reporting and audit | Populated on conversion |
Two fields deserve particular attention. Business justification is the one most often absent from home made forms, and without it an approver can only assess whether there is budget rather than whether the purchase is sensible.
The contract or catalogue reference is the second. Linking a request to an already agreed price is what makes automated conversion safe later, because the system has a price it can trust rather than an estimate someone typed in.
Indent, purchase request and requisition slip: the same document by other names
The terminology varies by region and by industry, and the variation matters because searching for the wrong word returns the wrong guidance. All of these describe the same internal request.
Indent. Standard usage across India and much of the Commonwealth, and more common in manufacturing, stores and inventory contexts than in software marketing. Indent management is a larger search term in India than purchase requisition itself.
Purchase request. Common in United States corporate usage and in accounting software, and generally interchangeable with requisition in everyday conversation even where the system calls it something else.
Requisition slip. Usually refers to the paper or single page version, still widely used in stores, hospitals, schools and manufacturing where a physical document travels with the request. A requisition template in a spreadsheet serves the same purpose digitally.
Material requisition. Narrower, referring specifically to a request to draw materials from existing stock rather than to buy something new from a supplier. Worth distinguishing because the approval path is different.
PR. The standard abbreviation inside ERP systems and procurement teams, and the one you will see on SAP screens and in the transaction names covered further down this guide. Indian groups often pair it with GST fields on the same form.
If your organisation uses indent and your software says requisition, nothing is wrong. Set the terminology once in your policy document so requesters, approvers and finance are describing the same document with the same word.
The purchase requisition process, step by step
Published guides describe this process in anything from three steps to eight, which makes it look like the models disagree. They do not, because the longer versions simply split the same activities more finely.
What follows is the six stage version, with a note on which steps the shorter models collapse together. Use whichever granularity matches how work is actually divided in your organisation.
One, identify and specify the need. The requester establishes what is required and in what quantity, ideally against a specification rather than a product name copied from a supplier's website. Three step models fold this into the request itself.
Two, raise the requisition. The form is completed with the fields listed above, including the budget code and justification. This is the point at which the request enters a system that can check it rather than an inbox that cannot.
Three, budget and policy check. The request is validated against the remaining budget for that cost centre and against purchasing policy. Doing this before human approval saves approvers from decisions they have no information to make.
Four, approval or rejection. The request routes according to value and risk thresholds, with the delegation of authority determining who signs. Rejections should carry a reason, because a rejection without one simply returns as the same request next week.
Five, sourcing and source assignment. Procurement confirms the supplier, the price and the contract or catalogue reference. Shorter models merge this into the purchase order step, but keeping it separate is what makes automation possible later.
Six, conversion to a purchase order. The approved requisition becomes a purchase order issued to the supplier, carrying the line items, quantities and agreed prices across without retyping. The requisition remains linked for audit purposes.
The stage most often skipped is the third, and skipping it is why so many approvals happen without anyone knowing whether the money exists. A budget check after approval is a report, not a control.
Who raises requisitions, and what goes wrong
Four groups interact with this document and they experience entirely different problems with it. Recognising which set of complaints you actually have determines whether you need better policy, better thresholds or different software.
Who | What they experience | What actually fixes it |
|---|---|---|
The requester | Raising a request takes longer than buying it themselves, and nothing tells them where it has got to or when it will be approved | One structured intake form, published cycle times, and visible status rather than an email into silence |
The approver | Requests arrive with no justification and no budget context, so the only available judgement is whether money remains | Budget checked before routing, mandatory justification, and no more than two approvers on low value requests |
Procurement | Requests arrive incomplete or with a supplier already chosen, which turns sourcing into paperwork and removes any negotiating position | An intake gate that can refuse an incomplete request, plus catalogues so routine items never need sourcing at all |
Finance | Commitments appear at month end that nobody saw coming, and coding has to be corrected after the fact rather than captured at source | Budget validation at the request stage and general ledger coding on the form rather than added later by someone guessing |
The pattern across all four rows is worth naming. Almost every complaint about requisitions is really a complaint about speed or about missing information, and both are design problems rather than compliance problems.
Where this guide comes from
This is written from operating procurement rather than from surveying it, and every technical detail has been checked against a primary source rather than repeated from other articles.
What we operate. Mindsprint runs procurement and supplier operations for a multi entity global group with more than 3,000 suppliers digitally connected across several countries, which is where the failure patterns described here come from.
What we verified. The SAP transaction codes and the automation prerequisites below are checked against SAP's own documentation and support notes rather than taken from secondary articles. Vendor pricing is taken from each vendor's published pricing page.
What we corrected. Two widely circulated pricing figures for this category are wrong, with Precoro commonly listed at around 35 dollars per user when it publishes a 499 dollar flat monthly fee. The corrected set appears in the software section.
What we left out. Purchase order management, three way matching and platform comparison, which belong to a separate guide. This page stops at the point the requisition becomes a purchase order.
Two limits, stated plainly. Vendor pricing moves, so treat the figures as a starting point for a budget conversation rather than a quotation. And Mindsprint sells procurement software, which is disclosed at the end rather than threaded through the guide.
How to set requisition approval thresholds
Approval design decides whether the process is used or worked around, and it receives less attention than any other part of this subject. The failure is almost always the same: chains inherited from email, where everyone once copied became an approver.
Route by value and risk rather than by habit. Set multi level approval thresholds so a small consumables request and a capital purchase travel genuinely different paths, and encode the delegation of authority once so the system applies it rather than people remembering it.
Keep low value requests to a single approver. Every additional signature adds delay and diffuses accountability, and the marginal control gained from a third approver on a small request is close to zero while the delay is real.
Run approvals in parallel unless one genuinely depends on another. Finance and the budget holder can usually review at the same time, and sequencing everything by default is the most common reason cycle times run into weeks.
Apply segregation of duties deliberately. The person raising the requisition should not be the person approving it, and neither should be the person confirming the goods arrived, because that separation is the actual control.
Set an auto approval limit and defend it. Requests below a genuinely trivial value should convert without human review, because routing a twenty dollar request to a manager costs more in attention than the request is worth.
Build an exception path and measure it. Urgent requests will bypass the normal route whatever the policy says, so give them a fast lane with review after the fact and then track how many people use it.
One test worth applying to any proposed design. Count the approvers on a typical low value request, and if the answer is more than two, the process will be routed around within a quarter regardless of which system enforces it.
How to stop people bypassing the requisition process
Bypassing is a symptom rather than a behaviour problem, and treating it as misconduct reliably makes it worse. People go around a process when the workaround is faster, which is a design signal rather than a discipline issue.
The scale is worth knowing before you address it. Maverick spend runs at around 30 per cent of total spend in organisations with weak controls, while best in class functions hold it just under 10 per cent.
Make the compliant route the fastest route. If raising a requisition takes longer than putting the purchase on a card, the card wins, and no amount of policy communication changes that arithmetic for the person in a hurry.
Give the tail a route rather than an exception. Low value purchases are individually too small to source and collectively significant, with BCG putting unmanaged tail spend at up to 25 per cent of total spend leakage.
Load catalogue and contract prices so requesting is easier than shopping. The Hackett Group reports guided buying and catalogue adoption improving 110 per cent among AI enabled functions, with maverick spend leakage falling 69 per cent as a direct result.
Publish requisition cycle time and hold yourself to it. Measuring from when the request was raised rather than when procurement received a complete one is the only honest measure, and it is the number requesters actually judge you on.
Fix the rejection loop. A request rejected without a reason returns unchanged, so requiring a reason and a suggested correction removes most repeat traffic and most of the frustration behind bypassing.
The diagnostic question to ask is uncomfortable but useful. When someone bought outside the process last month, was the compliant route genuinely available and faster, and if not, the process caused the breach rather than the person.
How to raise a purchase requisition in SAP
SAP is where a large share of requisitions are actually raised, and it is the part of this subject that published guidance consistently skips. The transactions below are verified against SAP's own documentation.
Transaction | What it does | When you use it |
|---|---|---|
ME51N | Create a purchase requisition | The everyday transaction for raising a request, with material or free text, quantity, delivery date, plant and account assignment |
ME52N | Change an existing purchase requisition | Correcting a request before release. Supports park and hold, item blocking and account assignment changes |
ME53N | Display a purchase requisition | Checking status or content without any risk of altering a document that is already in flight |
ME54N | Release a purchase requisition | The approval step where a release strategy applies, equivalent to the approval stage described earlier |
ME5A | List display of purchase requisitions | Working the daily queue, rather than opening documents one at a time to find what is outstanding |
ME57 | Assign and process requisitions | Assigning a source of supply where one was not determined automatically. Nothing downstream works without this |
ME59N | Automatic creation of purchase orders from requisitions | Converting approved requisitions to purchase orders in bulk, usually on a schedule. See the prerequisites below |
ME01 | Maintain the source list for a vendor and material | Master data setup, and a prerequisite for ME59N to find anything at all |
ME51 / ME52 / ME53 / ME54 | The older, non single-screen versions of the four core transactions | Still present and still in older training material. Use the N versions instead |
One distinction the search results rarely make clearly. The older ME51, ME52, ME53 and ME54 transactions still exist and still appear in training material, but the N suffixed versions are the current single screen replacements.
All four core transactions share the same program and package, and they support copying an existing requisition, creating from a template, park and hold, account assignment and item blocking. Those features answer several of the template questions people ask separately.
The practical sequence in SAP
Raise the requisition in ME51N, entering the material or a free text description, quantity, delivery date, plant and account assignment against the correct cost centre.
Use ME52N to correct anything before release, and ME53N to check status without risking an accidental change to a document already in flight.
Release the requisition through ME54N where a release strategy applies, which is the SAP equivalent of the approval step described earlier in this guide.
Assign a source of supply through ME57 if one was not determined automatically, because nothing downstream including automation will work without it.
Review outstanding requisitions in ME5A, which is the list view most teams use for their daily working queue rather than opening documents individually.
Purchase requisition automation: what should convert without human review
Automation in this context means an approved requisition becoming a purchase order without anyone retyping it, and in SAP that is transaction ME59N. It works reliably only when four pieces of master data are in place first.
Prerequisite for ME59N | Where it is set | What happens if it is missing |
|---|---|---|
Automatic purchase order flag on the material master | Material master, purchasing view | The requisition is skipped silently, with no error explaining why it was ignored |
Automatic purchase order flag on the vendor master | Vendor master, purchasing view | The same silent skip. Both flags are required together, not either one of them |
Source list maintained for the vendor and material | Transaction ME01 | The system cannot determine who to order from, so no purchase order is generated |
Purchase info record exists for the combination | Purchasing info record | No price is available, so the order cannot be priced automatically even if the source is known |
Fixed source of supply assigned where several vendors exist | Source list, fixed vendor indicator | ME59N returns message ME261, no suitable purchase requisitions found. This is the most common cause by a wide margin |
Configuration: per delivery date and generate schedule lines | ME59N selection screen | Controls whether several requisitions for the same item and date merge into one order line or split into several |
The most common failure deserves stating plainly because it wastes a great deal of time. Without a fixed source of supply assigned, ME59N simply does not find the requisition and returns message ME261, no suitable purchase requisitions found.
Two configuration flags then control how orders are grouped. Setting per delivery date and generate schedule lines determines whether several requisitions for the same item and date merge into one purchase order line or split into several.
What is safe to automate, in any system
Straight through conversion of an approved requisition into a purchase order, where the supplier, item and price already come from a catalogue or a punchout connection to the supplier's own site. These are the touchless transactions worth having.
Reorder point triggers for consumables and stock items where the category and supplier are contracted, provided a value ceiling applies above which a person still approves the commitment.
Routing, notification and exception routing, which are administrative rather than judgemental. Automating these removes delay without removing accountability from anyone, because a person still decides at each threshold.
What should not be automated
Selecting a new supplier, because that decision carries risk, compliance and commercial consequences a workflow cannot weigh or be held responsible for.
Accepting non standard terms or approving anything above the delegated authority, since these are accountability decisions and accountability cannot be delegated to a rule.
Releasing an order against an expired contract, which is exactly the situation where automation converts a lapsed price into a committed one before anyone notices.
The lesson generalises beyond SAP. Automation applied to stale catalogue or contract data does not save time, it commits the organisation to the wrong price faster than a person would have, which is why the master data work comes first.
Purchase requisition software, and what it costs
Most organisations arriving at this subject do not need a new system, because the requisition function inside an existing ERP or accounting package is often adequate. Where it genuinely is not, the options divide by price more sharply than by capability.
Option | Verified pricing | Model | Who it suits |
|---|---|---|---|
Your existing ERP module | Included in the licence you already hold | No additional cost | Anyone on SAP, Oracle or Dynamics. The transactions above show how to use it |
eRequisition | $11.99 per user per month for QuickBooks Online; $30 for QuickBooks Desktop | Per user | Micro and small businesses on QuickBooks. Note it is QuickBooks specific |
Tradogram | Around $35 per user per month on Professional, billed annually. Pro $195 and Premium $375 per month flat | Per user or flat by plan | Small teams wanting configurable routing. A free tier is available |
Precoro | $499 per month for Core; $999 per month for Automation; Enterprise custom | Flat platform fee, not per user | Teams with many occasional requesters, where per user pricing would penalise adoption |
Zapro | Tiered plans with add-on modules. No single flat figure published | Tiered plus modules | Growth-stage buyers wanting AI features. Ask for the module list before comparing |
SAP S/4HANA, Oracle Fusion, Dynamics 365 | Enterprise pricing, not published | Enterprise licence | Large organisations already committed to that ERP |
Mindsprint Procuresprint | Not published | Custom | Multi entity groups needing catalogue prices and budget checks applied at the request stage |
Two corrections are worth flagging because both circulate widely and both mislead. Precoro is frequently listed at around 35 dollars per user monthly when it actually publishes a 499 dollar flat platform fee, which reverses the recommendation for a small team.
Tradogram is the one commonly quoted at a much higher per user figure, when its Professional plan publishes at around 35 dollars per user annually billed. For a team of five those two errors point in exactly the wrong direction.
Two names to treat with care. CobbleStone appears in some requisition lists but is primarily a contract lifecycle vendor, and rupee denominated comparisons for this category are usually converted from the incorrect dollar figures rather than from each vendor's own India pricing.
The honest recommendation by size
Under about twenty requesters on QuickBooks Online, eRequisition at 11.99 dollars per user monthly is difficult to beat, though note it is QuickBooks specific and will not help you on Xero, Zoho or another ledger.
Small teams wanting configurable routing without a platform fee should look at Tradogram, where per user pricing and a free tier make it the cheapest genuine entry point into requisition control.
Organisations with many occasional requesters are usually better served by Precoro's flat fee, because per user pricing penalises exactly the behaviour you want, which is getting more people onto the system.
If you already run SAP, Oracle Fusion, Microsoft Dynamics 365 or NetSuite, the requisition function is in the box and the transactions above show how to use it. Buying a separate tool alongside a capable ERP module adds a reconciliation problem rather than solving one.
For the purchase order side of this decision, including approval routing, three way matching and a full platform comparison, our guide to PO management software covers the eight systems worth shortlisting and what each actually costs.
Purchase requisition best practices
Eight practices that separate a requisition process people use from one they route around. Each is inexpensive to implement, and each fails quietly the moment nobody owns it.
Use one intake route with a structured form. A form captures the budget code, category, specification and justification once, which removes the back and forth that accounts for most of the elapsed time on a typical request.
Require justification, not just description. The why is what allows an approver to reject a request on merit, and its absence is why so many approvals reduce to checking whether the budget happens to have money in it.
Load contract and catalogue prices where they exist. An agreed rate sitting in a signed document nobody opens is not a price control, and it becomes one only when it appears on the screen where the request is raised.
Check budget before routing for approval. Validating against the remaining allocation first means approvers make a decision with the relevant fact in front of them rather than discovering the overrun at month end.
Set thresholds and an auto approval limit deliberately. Routing trivial requests to a manager costs more in attention than the request is worth, and defending a sensible limit is easier than defending a queue.
Give a reason with every rejection. A request rejected silently returns unchanged the following week, so requiring a reason and a suggested correction removes most repeat traffic from the queue permanently.
Measure cycle time from the request, not from receipt. Measuring from when procurement received a complete request removes the queue from the measurement, which is precisely where the delay lives.
Name an owner for the catalogue and the thresholds. Prices go stale, approvers change roles and limits drift, so without someone accountable for maintenance the process degrades quarter by quarter whatever the software does.
The bottom line on purchase requisitions
A requisition is an internal request for permission to buy, and a purchase order is the commitment that follows approval. Keeping those two documents distinct is what allows the question of whether to buy at all to be asked before anyone is committed.
If you fix one thing, fix the form. Fifteen fields including justification, budget code and a contract reference turn a request into something an approver can decide on and an auditor can follow.
If you fix a second thing, fix the thresholds. Two approvers maximum on low value requests, parallel routing where nothing depends on sequence, and an auto approval limit that is actually defended.
If you run SAP, learn five transactions. ME51N to create, ME52N to change, ME53N to display, ME54N to release and ME5A to work the queue will cover almost everything a requester or buyer needs daily.
Before automating anything, fix the master data. ME59N and its equivalents in other systems only work when the supplier, item and price are already agreed, and automation over stale data commits you to the wrong price faster.
And the number worth keeping in view. Ardent Partners puts best in class spend under management at 91.7 per cent against 61.1 per cent for everyone else, and the requisition is the document where that difference is either captured or lost.
See what a requisition looks like when the price is already agreed before anyone asks
Most of the difficulty described in this guide traces back to one thing. When the requester types a price rather than selecting an agreed one, every later step becomes a check on information that was never reliable to begin with.
Mindsprint runs procurement and supplier operations for a multi entity global group with more than 3,000 digitally connected suppliers, which is where Procuresprint came from. Contract, requisition, purchase order and goods receipt sit on one record so agreed prices reach the request screen.
Honest limits. No published pricing, no free tier, no G2 listing, no analyst placement, and no QuickBooks or Tally integration for the small business end of this audience, where eRequisition or your existing ERP module will serve you better.
Two numbers worth measuring first. Your median days from request raised to purchase order issued, and the share of requests where the price came from a catalogue or contract rather than being typed in by the requester.
If those two numbers show a master data problem rather than a software problem, we will tell you that. Talk to the Procuresprint team about running the assessment on your own requisition data before considering any platform.
