Controls

Five small orders walk through the gate one big order cannot

A purchase order approval is three decisions, not one: where the gate sits, what it measures, and what it is allowed to stop. Get the second one wrong and the control is decorative. The orders below are invented so the arithmetic can be checked.

An approval process is often designed once, in a hurry, after something went wrong. Somebody bought something they should not have, a number gets picked, a rule gets written, and the organisation moves on believing it has a control.

What it has instead can be a speed bump with a documented way around it. Not because anyone is dishonest — because the rule tests the wrong thing, and the people doing the work find that out.

Step 1 — Put the gate at commitment

The useful question is not “who should approve purchase orders”. It is: after which moment does changing our mind start to cost money? That moment is the gate.

Before it, an order is a proposal. Cancelling costs a conversation. After it, the supplier has allocated production, bought materials, or booked freight, and cancelling costs a relationship, a fee, or both.

Two failure modes follow from missing that moment:

• The gate set too early — approving a draft while quantities are still moving. The approver signs off a number that changes before it is sent, so the approval means nothing and the organisation learns it means nothing.
• The gate set too late — approving at invoice, or at receipt. By then the commercial commitment has usually already been made. That is not an approval, it is a reconciliation with a signature line.

A common commitment point is when the order is sent or otherwise accepted by the supplier. Not always — if your supplier treats a sent order as advisory until you confirm a proforma, your real commitment point is the proforma. Find yours and put the gate exactly there rather than where the software defaults it.

A control placed where nothing is at stake does not protect anything. It just teaches people that signatures are paperwork.

Step 2 — Test the right unit

Here is a common failure mode worth designing for.

Set a rule: purchase orders of $5,000 or more need finance approval. Sensible, easy to explain. Now watch an ordinary week:

Twenty thousand dollars of commitment, in one week, with the control working exactly as written. A single $20,000 order would have been stopped. Five $4,000 orders are not.

It is worth being precise about why this happens, because the instinct is to suspect people of gaming the rule. Occasionally that is true. The orders may equally be split for ordinary reasons — three different suppliers, two different ship dates, a part that was ready before the rest — and the threshold simply never saw the total because nobody asked it to.

The fix: test the line and the batch

Keep the per-order threshold. Add a second test against the combined value of orders released together, and let either one trigger the approval. It is a small change and it closes that gap structurally rather than by asking people to behave differently.

Be precise about which gap it closes, though. Five $4,000 orders released separately over a day or a week are not in the same batch, so a batch test does not see them together. Cumulative exposure needs a test of its own — value per supplier per period, in the table below, or the same test applied per requester. Batch testing catches same-release splitting; supplier-period or requester-period limits catch cumulative exposure across separate releases.

In SKU Compass, an approval step carries both tests side by side — a per-order threshold and a $ batch threshold described as applying “when the POs submitted together total at least this much” — under the caption “Finance signs when either is met.”

Other units worth testing

Value per order is the obvious axis, and not the only one worth testing — some businesses gate on role, category, budget or supplier rather than on a dollar figure:

That last row is the most interesting of the set and the easiest to overlook. If your replenishment maths says order 400 and the purchase order says 2,000, the interesting fact is not the dollar value — it is the five-fold override. That is worth a conversation at any size.

Step 3 — Decide what the gate is allowed to stop

An approval gate has to lock something or it is not a gate. The design question is what. There is one design choice that creates serious operational risk: blocking the recording of goods that physically arrived.

It must not stop you recording what physically happened. Goods arrive on the schedule the freight company chose, not the schedule your approver chose. When a pending approval prevents receiving, two predictable failure modes follow, and both are worse than no control:

1. The stock becomes invisible. It is in the building, unrecorded, so it cannot be sold, and your reorder maths is about to order it again. A control that causes double-ordering has cost more than it saved.
2. People approve to unblock the dock. The approval gets granted because a pallet is sitting in the way, which converts a financial control into a formality. Now you have the cost of the process and none of its protection.

The principle generalises past purchasing: a control may gate a decision, but it must never gate the recording of a fact. The fact already happened. Refusing to write it down does not un-happen it; it only means your records and the world disagree, and the records lose.

So: lock the commercial terms — quantities, prices, supplier, the sending of the order. Leave receiving open, and leave notes and attachments open, since evidence arriving is also a fact.

In SKU Compass, a purchase order in approval carries the tooltip Locked while in approval — read-only on its editing actions, and received quantities can still be recorded against it while everything else stays locked.

An approval with no clock is just a queue

The last piece is often overlooked: measuring the queue itself. If you cannot say how long a typical approval waits, you do not have a measured control — you have an inbox.

Two numbers are enough: how long each pending approval has been waiting, and what the typical wait is. Use the median rather than the mean for the second one, because a few stuck approvals drag an average away from what the ordinary order experiences. The first lets you chase the one that is stuck. The second tells you what the process costs.

What the wait costs, in units

This is the part that makes approval a planning question rather than a finance one.

A purchase order waiting six days for a signature is six days that stock is not on its way. Your replenishment lead time starts when you decide to order, not when the supplier gets around to reading the email. So your approval queue is inside it.

That is 120 additional units of working capital tied up while that six-day delay remains part of the process, on one SKU, to absorb an internal queue. Across a catalogue that is a real number, and it is largely within your control — unlike the 42 days, which is not.

Which reframes the whole exercise. The question is not whether approval is worth the risk it prevents. It is whether this much approval is, given that the delay has a price you can calculate and put next to the risk.