The short answer
A purchase requisition (PR) is an internal request that says what material is needed, how much, for whom and by when. A purchase order (PO) is the external, commercial commitment to a supplier. The requisition answers "should we buy this?"; the order answers "what exactly have we agreed to buy, from whom, at what price and terms?". Linking each PO line back to an approved PR line is what keeps factory purchasing traceable.
Two documents, two different questions
In a factory, purchasing usually starts with someone who needs material — a store keeper who sees a reorder level, a production supervisor planning a job, or a maintenance engineer who needs a spare. They are rarely the person who negotiates with suppliers. That split is why two documents exist.
| Purchase requisition (PR) | Purchase order (PO) | |
|---|---|---|
| Purpose | Request permission to buy | Commit to a supplier |
| Audience | Internal: purchase, approvers | External: the supplier |
| Raised by | The department that needs material | The purchase team |
| Key content | Material, quantity, required date, department, priority, reason | Supplier, price, taxes, delivery schedule, payment and shipping terms |
| Approval | Is the need genuine and budgeted? | Are the supplier, price and terms acceptable? |
| Legal weight | None outside the company | A commercial commitment once accepted |
Why the link between them matters
When requisitions live in a register or WhatsApp and orders live in Excel, the connection between them exists only in the buyer’s memory. That creates predictable problems:
- Nobody can say later why a particular order was placed or who asked for it.
- The same requirement gets ordered twice because two people chased it.
- Partially ordered requirements are forgotten — 1,000 kg was requested, 600 kg was ordered, and the remaining 400 kg is lost.
- Approvals cannot be audited because the approval was a message, not a record.
The fix is structural rather than procedural: every PO line should reference the requisition line it fulfils, and the ordered quantity should flow back to the requisition so the open balance is always visible.
A typical requisition-to-order workflow
- Raise the requisition with material code, quantity, required date, department and priority.
- Review: the approver checks need and quantity, adds remarks, and approves, rejects or sends it back for changes.
- Source: for new or high-value items, send requests for quotation (RFQs) to suppliers and compare responses.
- Raise the PO against the approved requisition lines, choosing supplier, price, taxes and delivery schedule.
- Approve the PO — ideally by someone other than the buyer who created it.
- Send the PO and track deliveries against the promised quantities and dates.
Controls worth having, even in a small plant
- Segregation of duties: the person who creates a document should not approve it.
- Blocking remarks: if an approver raises a question, the document should not move forward until it is answered.
- Line-level status on the requisition: enquiry sent, PO raised, received.
- Priority and required date on every request, so urgent needs are visible rather than shouted about.
How mosaicOne handles requisitions and orders
In mosaicOne, requisitions move through draft, submitted, approved, changes requested or rejected. Reviewers add action remarks, which must be completed before the document can move on, or information remarks for context. Buyers can compose RFQ emails from plant templates and mark lines as enquiry sent. POs are raised against approved requisition lines, ordered quantity syncs back to the requisition, purchase orders are GST-aware, and each PO goes through approval before delivery batches open. Each user is given read, write or no access to every module when their account is created.
Key takeaways
- A requisition asks permission; a purchase order makes a commitment.
- Link every PO line to the requisition line it fulfils.
- Separate the person who creates a document from the person who approves it.
- Keep approvals and remarks on the record, not in chat.