What is a purchase requisition, and how does the process work?

What is a purchase requisition?

A purchase requisition is an internal document in which an employee asks the organisation to buy goods or services. It states what is needed, the quantity, the date, the estimated cost and the budget to charge. Once approved, it allows purchasing to place an order with a supplier. Nothing is ordered at this stage.

Software documentation uses the same definition. Microsoft’s training for Dynamics 365 Supply Chain Management states that purchase requisitions are internal documents, whereas purchase orders are the external documents that purchasing sends to vendors. SAP’s training describes a purchase requisition as a request to procure a material or a service. Many organisations shorten it to requisition, purchase request or PR; the meaning is the same.

A typical case: a laboratory manager needs a new centrifuge. Instead of calling a supplier, she raises a requisition in the purchasing system with the model, a quote from the supplier she prefers, the project code and the reason. Her budget holder approves it, then purchasing checks the price against the existing contract and sends the order. If she had called the supplier directly, the organisation would receive an invoice with no approval and no purchase order behind it.

The requisition is the first document of procure-to-pay. The purchase order that follows is the document sent to the supplier; a detailed comparison of the purchase requisition and the purchase order is in preparation.

What does a purchase requisition contain?

A purchase requisition contains enough information for an approver to say yes or no, and for a buyer to place the order without asking again. The fields below are common in purchasing systems; names change from one product to another.

How does the purchase requisition process work?

The purchase requisition process runs from the moment a need appears to the moment purchasing turns the approved request into an order. In most organisations it has six steps.

1. Describe the need. The requester picks an item from a catalogue or a contract, or writes a free-text description and attaches a quote.
2. Code it to a budget. The requester, or the system, adds the cost centre, account or project. The system can check the remaining budget.
3. Submit for approval. The system routes the request to approvers under the written rules, usually by amount, category and budget.
4. Approve, change or reject. Each approver accepts, sends the request back for a change, or rejects it, with a reason.
5. Choose the source. For catalogue and contract items, the supplier and price are already known. For free-text requests, a buyer finds the supplier, sometimes with a request for quotation.
6. Create the purchase order. The approved requisition becomes an order, automatically or through a buyer, and the requisition is closed.

The longest step is usually approval. A request that waits a week in an approver’s inbox pushes requesters to order directly from suppliers, which is how invoices without purchase orders appear. A clear route, a deputy during absence and a status the requester can see keep the process short.

How does purchase requisition approval work?

Purchase requisition approval follows the organisation’s delegation of authority: the written rule that says who may approve how much, for which budget and category. A small request may need only the budget holder; a large one may need a head of department and finance. The rules usually live in the procurement policy.

Systems apply these rules in different ways. SAP S/4HANA can release (approve) each item of a requisition separately, or the whole requisition at once, in which case every item must meet the same criteria. Microsoft Dynamics 365 lets an approver send a requisition back for a change, after which the workflow resumes where it stopped, or reject it, after which it goes through the whole workflow again. Ask how your system handles a change after approval, such as a higher price: whether it goes back to the approver depends on these settings.

Approval is also a control. The GAO’s internal control standards for US federal bodies call for segregation of duties, so that no single person controls every key step of a transaction. Applied to requisitions, the person who approves a request should not also create the supplier or approve the invoice for payment. An approval matrix with example amounts and roles is shown in the guide to purchase requisition software.

What happens once a requisition is approved?

An approved requisition becomes a purchase order when purchasing, or the system, turns it into an order to one supplier with a price, quantity and delivery terms. The requisition then closes. The requisition is a request inside the organisation; the purchase order is what the supplier receives. Under US commercial law, for example, a purchase order is an offer to buy, which the supplier accepts by promising or starting to ship.

• Automatic conversion. When the item, supplier and price are already known, the system creates the order without a buyer. In SAP, for example, both the material and the supplier must be flagged as allowed for automatic orders, and the system must find one valid source of supply.
• Conversion by a buyer. Free-text requests, or those above a set value, wait for a buyer, who confirms the source and the price. Microsoft Dynamics 365 lets purchasing rules decide which approved requisitions become orders automatically and which are held for a buyer.
• Consolidation. Several approved requisitions for the same supplier can be grouped into one order, which means fewer orders and fewer invoices.
• Sourcing first. A request with no supplier or price may start a quotation, and becomes an order once a supplier is chosen.

How the purchase order is built and what it must contain is explained in what is a purchase order.

What are examples of purchase requisitions?

Three fictional examples show the common shapes of a requisition and the route each one takes.

How do you track purchase requisitions?

You track a requisition through its status. Microsoft Dynamics 365 uses six: draft, in review, rejected, approved, cancelled and closed, where closed means the purchase order has been created. A requester who can see the status, and the name of the approver holding the request, does not need to email purchasing to ask.

For a small team, a shared register in a spreadsheet can track requests, approvals and order numbers. It stops working when several people approve, budgets must be checked or requests change after approval. At that point teams look at purchase requisition tracking software, which routes, records and reports on every request; what such tools do and how to choose one is covered in purchase requisition software. Useful measures include the time from submission to approval and the share of requests raised from a catalogue.

What is a purchase requisition in SAP and other ERPs?

ERPs use the same name. In SAP S/4HANA, the document is called a purchase requisition and is an internal document; it can be created by hand or automatically, for example by planning. SAP’s training separates two ways of creating it: self-service requisitioning, where an employee fills a shopping cart, mostly from catalogues, and the system generates the requisition from it; and professional requisitioning, where a purchaser creates the requisition. Approval runs through a release procedure or a flexible workflow, and the approved requisition becomes a purchase order, automatically or by hand.

Microsoft Dynamics 365 Supply Chain Management also calls it a purchase requisition, with a requester, a preparer and approvers. Other products may say requisition, purchase request or shopping cart for the screen the employee fills in. The screens and settings differ from one system to another; the document and its role in procure-to-pay stay the same.