What a purchase requisition is
The requisition (or purchase requisition) is an internal request: the document the jobsite uses to tell administration what it needs and when it needs it. It originates from the lack of a material or service in the field — cement, rebar, formwork, an equipment rental, a concrete pumping service — and its job is to put that need in writing so someone can act on it. It is not an order to the vendor: it is a request directed inward, into the company.
That is why a typical requisition carries no price and no vendor. It carries what the jobsite does know: description of the item, quantity, unit, which area or cost code it is for, and the date it is needed on site. It may include a quality reference or specification (for example, “3,000 psi concrete, 4-inch slump”), but the “how much does it cost” and the “who do we buy it from” are settled later, during the purchasing stage.
The requisition serves two useful roles at once: it is the trigger for the purchasing process and it is the first record of traceability. If tomorrow you want to know why a certain material was ordered or who requested it, the requisition is the document where that story begins.
What a purchase order is
The purchase order is the formal document the company issues and sends to the vendor in order to buy. Unlike the requisition, everything here is already defined: vendor, quantities, unit prices, total amount, payment terms, place and date of delivery. It is an outward-facing document that, once accepted, works as a firm commitment between the two parties.
The purchase order grows out of the requisition, but it is not a copy of it: the purchasing work happens in between. One or several vendors are asked for quotes, price and terms are compared, budget availability for that cost code is checked, and a choice is made. The result of that process is the purchase order, which now carries the number, the vendor, and the price the requisition did not have.
Its effect is twofold. Toward the vendor, the PO is the backing for the order and the basis for the invoice to later match what was agreed. Internally, it is the moment the spend becomes committed: issuing a purchase order means setting that money aside from the budget, even though the material has not arrived and no invoice exists yet. That is the heart of purchasing control.
Key differences, point by point
Although they are part of the same workflow, the requisition and the purchase order differ in almost everything: direction, content, who signs them, and what effect they have on money. Seeing them side by side makes it clear why they are not interchangeable.
- Direction: the requisition is internal (jobsite → administration); the purchase order is external (company → vendor).
- What it contains: the requisition carries need, quantity, and date, with no price or vendor; the purchase order carries vendor, price, terms, and total.
- Who creates it: the requisition is created by whoever is in the field; the purchase order is created by purchasing or administration.
- Effect on money: the requisition commits no spend (it only asks); the purchase order does commit the budget the moment it is issued.
- Legal commitment: the requisition obligates no one to buy; the purchase order, once accepted, obligates the vendor to deliver and the company to pay.
- Point in the workflow: the requisition comes first (need), then the quote and the authorization, and finally the purchase order (commitment).
How committed cost is controlled
The underlying reason to separate the two documents is control of committed cost. “Committed” is the money that is already set aside because a purchase order has been issued, even though you have not yet paid it and no invoice has arrived. It is different from “spent” (already invoiced or paid) and from “budgeted” (what the cost code was assigned from the start).
These three concepts build the budget snapshot of a cost code: available budget = budget − committed − spent. If every purchase order deducts from the available amount the moment it is issued, you know at any time how much you really have left for that cost code, not how much you had left before the latest orders. Without that up-front deduction, it is easy to believe there is budget and to over-commit because the orders have not been paid yet.
This is where the requisition earns its value: because it commits no money, it lets someone review the available balance BEFORE the purchase order is issued. If the cost code no longer covers it, the requisition is stopped, adjusted, or authorized as an exception with full knowledge of the situation. The purchase order should only go out once that review has been done; that way the commitment always lands inside a budget that someone actually looked at.
Why separate requisition and purchase order
You could buy without a requisition: have the jobsite call the vendor and order directly. Many small companies do it, and it works until it stops working. The problem is that without the intermediate step there is nowhere to review before committing, and each purchase becomes a done deal that administration finds out about when the invoice arrives.
Separating the two documents creates exactly that approval point between “I need it” and “I’m buying it.” Several healthy checks fit there: that the material is really needed and in that quantity, that there is budget in the cost code, that it was quoted, and that whoever authorizes the spend sees it before it becomes irreversible. It is the difference between controlling the spend at the front door or discovering the overrun at month-end close.
- It gives a formal moment to review against budget before committing money.
- It separates responsibilities: the jobsite requests, purchasing negotiates, administration authorizes; no one is both judge and party.
- It leaves traceability: from an invoice you can go back to its purchase order and from there to the requisition that started it.
- It allows orders to be consolidated: several requisitions for the same material can become a single, better-negotiated purchase order.
- It avoids the recurring “emergency” purchase, which almost always ends up expensive because it is done without quoting and without checking the available balance.
Common mistakes in the purchasing workflow
Most purchasing breakdowns come not from bad intentions but from skipping steps under pressure. Knowing the typical stumbles helps you design a workflow that holds up to the day-to-day of a jobsite.
- Buying without a requisition: the order goes straight to the vendor and administration finds out with the invoice, when there is nothing left to approve.
- Issuing the purchase order without checking available budget: spend is committed in a cost code that was already used up.
- Not deducting the committed amount: “free budget” appears that is actually already set aside by issued purchase orders, and you over-buy.
- Using the requisition as if it were a purchase order (or vice versa): the jobsite sends “requisitions” with vendor and price already closed, and purchasing loses its control point.
- Regularizing after the fact: buying today and “doing the purchase order later,” so the document stops working to authorize and only works to file away.
- Confusing petty cash with a formal purchase: settling amounts through jobsite petty cash that should have gone through a purchase order, losing the quote and the control.
How Matterial handles it
In Matterial the workflow goes from requisition to purchase order without re-keying: the jobsite raises the requisition with what it needs, and that same request becomes a purchase order once vendor, price, and terms are added to it. They are not two separate entries you have to reconcile by hand, but a single thread that moves from “I need it” to “I’m buying it.”
When the purchase order is issued, the amount enters as committed cost for the cost code and is deducted from the available balance live, alongside what has already been spent. That way, before authorizing a new purchase, you see the budget you truly have in that cost code, not the one you had before the latest orders. That is the honest mechanism that keeps you from committing over budget: not an alert that arrives too late, but an available balance that already accounts for what is committed.
It is not magic and it does not replace the judgment of whoever authorizes: it is order and traceability. From an invoice you reach its purchase order and from there the requisition that started it, and each purchase stays charged to the area and cost code it belongs to. What Matterial adds is that this trail is always complete and at hand, so you decide with the right number instead of reconstructing it at month-end close.