A purchase order is a document you issue to a supplier saying what you want to buy, at what price, on what terms. Once they accept it, it's a contract.
The distinction that matters: you raise the purchase order, the supplier raises the invoice. The PO is your commitment to buy; the invoice is their demand to be paid. They describe the same transaction from opposite sides, which is what makes comparing them useful.
What it's actually for
Three things, in order of how much they matter to a smaller business.
Authorisation happens before the money is committed. This is the real one. Approving an invoice is approving something that has already happened — the goods are delivered, the obligation exists, and saying no is a dispute rather than a decision. Approving a PO happens while it's still a choice.
A price you agreed to check against. Without a PO, the invoice price is the only price anyone has a record of.
A record of who ordered what. When an invoice arrives for something nobody recognises, the PO is the answer. Without one, you're asking around.
What belongs on one
- A unique PO number — the reference everything else hangs off
- Your details, and the supplier's
- Date, and any required delivery date
- Line items with description, quantity, unit price
- Total, and whether it's inclusive or exclusive of tax
- Delivery address, which is often not the billing address
- Payment terms
- Who authorised it
The PO number is the load-bearing part. It's how the invoice gets matched back, and asking suppliers to quote it on their invoice is the single thing that makes the whole system work.
The sequence
- Someone identifies a need
- A PO is raised and approved by whoever holds the budget
- The PO goes to the supplier
- Goods or services are delivered — noted on a goods receipt
- The supplier's invoice arrives quoting the PO number
- The invoice is checked against the PO, and the receipt if you keep them
- Paid
Steps 4 and 6 are where PO systems fall over in practice, not step 2.
PO, delivery note, invoice, receipt
Four documents, one purchase, and they get confused constantly:
| Document | Raised by | Says |
|---|---|---|
| Purchase order | You | What you want to buy |
| Delivery note | Supplier | What was sent |
| Invoice | Supplier | What you owe |
| Receipt | Supplier | What you've paid |
The delivery note is the one people discard, and it's the one that proves you received what you're being billed for.
When POs aren't worth it
Worth saying plainly, because the standard advice is that everyone should use them and that isn't true.
POs earn their place when spend is committed in advance and delivered in discrete lots — stock, materials, equipment, subcontractors. They work poorly for services on retainer, utilities, subscriptions and professional fees, where there's nothing to receipt and the commitment isn't a discrete event.
They also fail badly when only partially adopted. If half your spend arrives without a PO, you have a control with a hole in it and a process everyone has learned to route around. A partial PO system generates exceptions without preventing errors — the worst of both.
A reasonable middle position: raise POs for the categories that suit them, set a value threshold below which nobody bothers, and route everything else through ordinary approval. Partial coverage on the spend that fits beats universal coverage everyone circumvents.
If you're starting
- One numbering sequence, not one per person
- A threshold — below it, no PO. Set it high enough that people don't resent it
- Ask suppliers to quote the number, and put it on the PO document itself
- Decide who receipts deliveries before you start, not after
- Accept that some spend won't have one, and have a defined route for that rather than pretending otherwise
Cribble reads the documents around a purchase — the invoice, its delivery note, any credit note — and links related ones together, so what reaches an approver arrives with its paperwork. That's reference linking rather than variance matching: it doesn't compare quantities against a PO or enforce tolerances. For true three-way matching you want a procurement system.
