Purchase orders come in a few recognisable kinds and they behave differently once issued, which is the part examples usually omit. Seeing three side by side, with what happens to each after it goes to the supplier, explains why the same system handles them with different rules and why using the wrong kind creates administration.
The standard order
Specific items, quantities and prices for one purchase, with a delivery date. Approved at its own value, matched against receipts and invoices for those lines, and closed when the quantities reconcile. The simplest case and the one every system handles; it becomes administratively heavy only when used for high-frequency repeat buying.
The blanket order
Agreed prices and a total value over a period, with deliveries drawn against it. Approved once at the total, which is efficient and puts the weight on getting that total right. It needs a visible remaining balance and an expiry date, or cumulative deliveries pass the approved value one at a time without anybody noticing.
The order against a framework
Terms and prices already agreed in a contract, so the order calls off against them rather than negotiating anything. Approval is usually lighter, because the commercial terms were approved when the framework was signed. What matters here is that the order references the agreement, so the price basis is traceable later.
Questions people ask about purchase order examples
Which kind should we use for monthly consumables?
A blanket order with an expiry, since a standard order per delivery is administration without added control.
Does the kind change how matching works?
Blankets need drawdown tracking as well as line-level receipts. Standard and framework orders match the same way.
Can we mix them?
Most organisations do, and should. The kind follows the purchasing pattern rather than being a system-wide choice.