Purchase requisition: the step before the purchase order

A purchase requisition is an internal document: somebody in the company asks to buy something, and somebody with authority approves it. Only then does a purchase order go to the supplier. The two are constantly confused, and the confusion is expensive — a company without requisitions discovers its spending when invoices arrive, which is the worst possible moment to disagree with it.

For a small company the process does not need software. It needs six fields and one rule about who approves what.

Requisition, order, invoice — three documents, three moments

• Purchase requisition — internal. "I need this, here is why, please approve." Nobody outside the company sees it.
• Purchase order — external. Sent to the supplier after approval, and it becomes a contract when the supplier accepts it.
• Invoice — from the supplier, after delivery, quoting the PO number so all three can be matched.
• The chain matters because each step is a different control: the requisition controls whether you buy at all, the order controls what you agreed to pay, and the invoice is checked against both.

The approval threshold is the whole policy. Below a stated amount, the requester's manager approves; above it, someone else does. Companies that skip the threshold either approve nothing — everything waits on one person — or approve everything, which is the same as having no process.

What a purchase requisition should contain

• Requester and department, and the date raised.
• What is needed: description, quantity, and a specification precise enough for someone else to buy it.
• Why it is needed — one line. This is what the approver is actually judging.
• Estimated cost and the suggested supplier, with an alternative if there is one.
• When it is needed by, which is what turns a request into a priority.
• The budget or cost centre it comes from.
• Approval: who approved, when, and any condition attached.

Running it without buying software

1. Write the approval thresholds down: who can approve up to what amount, and what always needs a second pair of eyes.
2. Use one form for requests, so they arrive structured rather than as messages in three channels.
3. Keep requisitions in one list with a status — requested, approved, ordered, received — so anyone can see where a request stands.
4. Raise the purchase order only from an approved requisition, and put the requisition reference on it.
5. Match the invoice to the order and the delivery before paying — the three-way match is what makes the whole chain worth having.
6. Review monthly: what was bought without a requisition, and why. That list tells you whether the threshold is realistic.

Ettex covers the downstream half directly. Ettex Invoices handles what happens after approval — line items with quantities, rates, multiple tax rates and discounts, notes and terms fields where the requisition and PO references belong, sequential auto-numbering with your own prefix, a client and supplier book so entity names stay consistent between documents, statuses from draft to sent to paid, and export as print-ready PDF or as CSV and XLS for the books. The requests themselves fit Ettex Forms — a short form with the seven fields above, submissions landing in a searchable inbox with a live summary — and the approval status can live in Ettex Records as a table with a saved view per stage.

Signs the process is missing

• Invoices arriving for things nobody remembers ordering.
• Subscriptions renewing that no current employee uses.
• Purchases split into smaller amounts to stay under an approval threshold — a sign the threshold is wrong, not that people are dishonest.
• Approvals given verbally, so the approver later remembers a different number.
• Orders placed by whoever noticed the need, with no record of what was agreed.

A purchase requisition is a small document with one job: making the decision to spend happen before the money is committed rather than after the invoice arrives.