Purchase Order Procedure: Policy and Thresholds

Most organisations have a purchase order process. Far fewer have a purchase order procedure written down in a way that anyone can pick up and follow. The procedure is the policy document behind the workflow: it says when a PO is compulsory, who may approve what, which purchases are exempt, and what happens when someone buys first and asks later. This guide sets out what belongs in that document, how to build an approval threshold matrix, and how to enforce no PO no pay without grinding the business to a halt.

Why the written procedure matters more than the workflow

A purchase order is a buyer issued document that authorises a purchase on stated terms. The mechanics of raising one are usually well understood by the people who do it every day. What is far less consistent is the judgement around it: does this particular purchase need a PO at all, who is allowed to approve it, and what should happen when a supplier turns up with an invoice for work nobody formally ordered.

A written procedure fixes the answer once. It converts individual judgement into a shared rule, which is what makes spend control auditable rather than anecdotal. It also protects the people following it: an employee who applied the documented threshold correctly has done their job, even if the purchase later turns out badly. That is a meaningful difference in culture, and it is why the document deserves proper drafting rather than a page copied from a template and never read again.

What a purchase order procedure document should contain

A good procedure is short enough to read in one sitting and specific enough to settle arguments. The outline below works at almost any size, from four pages to twelve with appendices. Copy the headings and fill them in.

• Purpose and objectives. One paragraph on why the procedure exists: control of committed spend, budget visibility, supplier fairness and audit evidence.
• Scope. Which entities, sites, departments and spend categories the procedure applies to, stated positively.
• Exclusions. The categories explicitly outside the procedure, such as payroll, rent, statutory payments and intercompany recharges.
• Definitions. Requisition, purchase order, blanket order, commitment, receipt, three way match, and any internal terms with a local meaning.
• When a PO is required. The core rule, plus the value floor beneath which a PO is optional.
• Approval thresholds and delegation of authority. The matrix, in one table, with rules on splitting and aggregation.
• Roles and responsibilities. Requester, approver, buyer, receiver and payer, with the segregation rules between them.
• Exceptions and emergencies. The retrospective route, who may authorise it, and the time limit for regularising it.
• No PO no pay. The payment rule, its start date, and how invoices without a valid PO are handled.
• Records and retention. What is kept, where, in what format and for how long.
• Non compliance. What happens when the procedure is ignored, escalating from reporting to management action.
• Version control and review. Owner, approval date, next review date and a change log.

Two of those sections do most of the work. The threshold matrix is what people actually look up, and the exceptions section is what determines whether the rest of the document is respected or routed around. Everything else is scaffolding, useful but rarely consulted once the procedure has bedded in.

Scope and exclusions: draw the boundary clearly

Ambiguity about scope is the single most common cause of maverick buying. If a marketing manager cannot tell whether a twelve month software subscription counts as a purchase requiring a PO, they will guess, and the guess that involves less paperwork usually wins. State the boundary in plain terms and give examples on both sides of it.

Exclusions are where you list what genuinely does not need a PO because it is controlled another way. Typical exclusions are payroll and expenses, rent and rates, utilities under a standing agreement, taxes and statutory fees, bank charges, insurance premiums, intercompany recharges, and petty cash within a stated limit. The test is not whether raising a PO would be inconvenient; it is whether another documented control already provides the authorisation and audit trail a PO would have given you. If the answer is no, it belongs inside the scope.

When a PO is mandatory, and the exceptions that are allowed

The default rule should be simple: a purchase order is raised and approved before any commitment is made to a supplier. Commitment is the key word. It is not the invoice or even the delivery that matters, it is the moment someone tells a supplier to go ahead. Writing the rule around commitment rather than payment stops the familiar argument that the order was fine because nobody had paid yet.

Three exceptions are worth building in deliberately, because if you do not, people will invent their own. The first is genuine emergency: a plant failure, a safety issue, an outage where waiting for approval causes real harm. Permit a verbal authorisation from a named senior role, and require the PO to be raised retrospectively within a fixed window, typically one or two working days, with a written reason recorded.

The second is low value. Below a stated floor the administrative cost of a PO exceeds the control benefit, so allow a purchasing card or petty cash instead, with its own receipt and coding rules. The third is recurring spend under an existing agreement, which is better handled by a blanket or standing order covering a period and a total value than by a stream of near identical POs. Draw down against the blanket order and the control remains, while the paperwork collapses to a fraction.

Approval thresholds and delegation of authority

Thresholds translate the organisation's appetite for risk into a number anyone can apply. Publish them as a single matrix rather than scattering them through the text, state the currency, and say whether the figures are net or gross of tax. Always express the approver as a role, never a person, so the matrix survives staff changes.

Three rules make the matrix hold. First, aggregate: the threshold applies to the total value of a contract or of a related series of orders, not to each line. Second, prohibit splitting, and say so explicitly, since breaking a 30,000 purchase into six orders of 5,000 is the oldest way around any delegation of authority. Third, define delegation during absence, naming who acts up and confirming that authority cannot be delegated downwards below the threshold that triggered it.

Review the numbers annually. Thresholds set five years ago and never revisited either strangle routine buying or wave through spend that should have had scrutiny. Where thresholds tie into forward budgets, the figures should be sanity checked against your procurement planning cycle so the two documents do not contradict each other.

No PO no pay, enforced fairly

No PO no pay is the enforcement mechanism that gives the rest of the procedure teeth. The rule is that accounts payable will not process an invoice unless it quotes a valid purchase order number raised before the order was placed. Without that backstop, the procedure is advisory, and advisory policies are followed by the people who were never the problem.

Enforcement fails when it is sprung on people. Announce the start date in advance, tell suppliers in writing that invoices must quote a PO number, and be explicit that invoices without one will be returned rather than held. Run a grace period during which non compliant invoices are paid but reported to the relevant budget holder by name, so the pattern is visible before consequences begin.

Fairness also means honouring the exceptions you wrote. If a purchase qualified as an emergency and was regularised within the window, it is compliant and should be paid without argument. What the rule targets is the habit of ordering casually and expecting finance to sort it out later. Where a supplier has done the work in good faith, pay them and address the internal breach separately; punishing the supplier for your own control failure damages relationships you will need again.

Roles, responsibilities and segregation of duties

Segregation of duties is the principle that no single person should control a transaction end to end. In procurement that means the person who requests a purchase should not be the only one who approves it, the person who approves should not be the one who confirms receipt, and none of them should release the payment. Each break in the chain is a place where an error or a fraud has to pass another pair of eyes.

In a small team one person will inevitably wear two hats. Say so in the procedure rather than pretending otherwise, and specify the compensating control: a monthly review of all orders by a director, or a hard rule that the same person may never both approve and receive. Documented overlap is defensible at audit; undocumented overlap is a finding. The mechanics of how these roles hand over to each other are covered in our guide to the purchase order process, and the anatomy of the document itself in the purchase order guide.

Records, retention and audit evidence

The procedure should state what constitutes the record of a purchase and how long it is kept. As a minimum that means the approved requisition, the purchase order, evidence of approval including who approved it and when, quotations or tender documentation where the threshold required them, the goods received note, the supplier invoice, and the match result.

Retention periods usually follow the longest applicable obligation, whether that is tax law, contract limitation periods, sector regulation or grant conditions. Six to seven years is a common baseline, with longer periods for capital projects. Name the actual period in the document rather than saying records are kept as required, and name the system of record so nobody has to hunt through inboxes.

Writing it so people follow it, and keeping it current

A procedure nobody reads controls nothing. Write in the second person and the active voice, addressing the reader directly: you must raise a purchase order before committing to a supplier. Keep sentences short. Number the clauses so people can cite them in an email. Put the threshold matrix on a page of its own that can be printed and pinned up, because that is the part people need most often.

Set a named owner and a review date, and treat the review as real work rather than a formality. Come back to thresholds for inflation and growth, to the exceptions log to see which exception is being used most often and why, and to the non compliance reports to find the departments where the procedure is failing. A rule that is broken constantly is usually a badly designed rule, not a badly behaved department.

This is where software earns its place. ProcureWave holds the requisition, the approval thresholds, the purchase order and the three way match in one flow, so the procedure is enforced by the system rather than remembered by the person. Thresholds are configured once, approvals are captured with a timestamp, and the exceptions route is a form rather than a favour. If you would like to see how your own thresholds and delegation rules would work in practice, take a look at what the platform covers or talk to our team about mapping your procedure onto it.

A purchase order procedure is not bureaucracy for its own sake. Write it clearly, set thresholds that reflect real risk, enforce no PO no pay with a workable exceptions route, and review it once a year. Do that and the procedure stops being a file nobody opens and becomes the way the organisation actually buys.

Frequently asked questions

What is a purchase order procedure?

A purchase order procedure is the written policy that states when a purchase order must be raised, who may approve it and at what value, which purchases are exempt, and how records are kept. It is the rulebook that sits above the day to day purchase order process and makes the same decision repeatable across every department.

What should a purchase order procedure document contain?

At minimum: purpose, scope and exclusions, definitions, the rule on when a PO is mandatory, the approval threshold and delegation of authority matrix, named roles and responsibilities, the exceptions process, the no PO no pay rule, record retention periods, and a review date with a version history.

What are purchase order approval thresholds?

Thresholds are value bands that decide who signs off a purchase. A low value order might need only a line manager, while spend above a set figure escalates to a head of department, a finance director or the board. Thresholds should be stated in one table, with the currency and whether the figure is net or gross made explicit.

What does no PO no pay mean?

No PO no pay is a policy under which accounts payable will not settle a supplier invoice unless it quotes a valid purchase order number raised before the goods or services were ordered. It stops retrospective ordering and gives finance a complete forward view of committed spend.

How often should a purchase order procedure be reviewed?

Annually as a rule, and immediately after any material change: a new finance system, a restructure, a merger, an audit finding, or a fraud incident. Thresholds in particular drift out of date with inflation and growth, so a yearly value check is the minimum sensible cycle.