The Delivery That Was Bigger Than the Order
A supplier sends 110 against an order for 100 and the storekeeper books in what arrived, because that is what arrived. The extra ten become real stock nobody ordered, on an invoice nobody questioned. What a receiving door should refuse, what it must not, and why the distinction is the whole design.
The order said one hundred. The delivery note says one hundred and ten. The lorry is at the gate, the driver wants his copy signed, and there are two more deliveries behind him. The storekeeper counts one hundred and ten cartons, writes one hundred and ten, and books in one hundred and ten — because that is what is physically standing in the yard, and refusing to write down what you can see is not a policy anyone can follow.
Nothing about that afternoon feels like a control failure. Everyone behaved reasonably. And yet the business has just accepted ten units it did not order, at a price nobody agreed, on an invoice that will now match the receipt perfectly and sail through every check downstream.
This is the oldest hole in receiving, and the reason it survives is that the honest version and the dishonest version look identical at the gate.
The two things an over-receipt can be
Before deciding what a system should do about it, it is worth separating the cases, because they have nothing in common except the number on the delivery note.
The ordinary version
- A supplier ships full cases because they do not break a carton of twelve for an order of ten.
- A goodwill extra, or a replacement for something short-shipped last month, arriving unannounced.
- A genuine picking error at their end that nobody has noticed yet.
- A quantity typed into the order wrongly in the first place, which the supplier corrected sensibly.
The expensive version
- A padded receipt created to justify an invoice for more than was ordered.
- A second delivery booked against an order that was already fully received, so the same order pays twice.
- Stock received into the business and never sold through it, with the paperwork made to reconcile.
- A supplier who has learned that over-shipping is accepted here and prices accordingly.
The first column is routine and the second is theft, and the storekeeper at the gate cannot tell which one they are looking at. That is not a training problem. The information required to distinguish them is not present at the gate — it lives in the order, in the previous deliveries against it, and in whether anyone authorised a change.
The honest over-delivery and the fraudulent one look exactly the same to the person receiving it. That is the whole reason the check belongs in the system rather than in a person's judgement.
What AWRA does at the receiving door
Receiving more than was ordered is refused. Not flagged, not warned about, not queued for review — refused, before anything is written, so a rejected receipt leaves no half-created record behind for someone to find later and wonder about.
The default tolerance is zero percent. An organization that routinely accepts small over-deliveries raises the tolerance to a figure it can defend, rather than switching the guard off — which is a deliberate design choice, because a tolerance is a policy somebody chose and a disabled check is a policy nobody remembers making.
The refusal names the item, what is being received, what the running total would become, what was ordered, and by how much it exceeds — and then tells you the two legitimate ways forward: raise the tolerance, or amend the order.
It counts every previous delivery, not just the last one
This is the half that matters most and the half most implementations miss. If the check only looks at the receipt in front of it, an order for one hundred can be received one hundred today and one hundred again tomorrow, and each individual receipt is perfectly in order. The guard sums every prior check-in booked against the order, so the second delivery is measured against what is left rather than against the order total.
What it deliberately does not refuse
A short delivery is reported as an exception and never blocked. This is the more interesting half of the design, because the symmetrical-looking rule — refuse anything that does not match the order exactly — is the wrong one, and wrong in a way that would be discovered slowly and painfully.
Partial shipments are normal. Back-orders are normal. A supplier sending sixty now and forty next week is not an exception to anything, and a system that refuses to book in the sixty forces a warehouse into an impossible position: goods on the floor that the system says do not exist.
What happens next in that situation is entirely predictable. Somebody finds a way around the system — a receipt booked with no order behind it, a quantity adjusted to make the check pass, a spreadsheet kept alongside. And a control that gets routinely bypassed is worse than no control, because it produces the paperwork of compliance without the substance of it.
- Refuse the case that has no legitimate version. Receiving more than was ordered always requires a decision by somebody with the authority to change the order. There is no honest version that a storekeeper should be resolving alone at a gate.
- Report the case that has an obvious legitimate version. Short deliveries happen constantly for good reasons, so surfacing them as exceptions gives you the visibility without creating an incentive to work around the system.
- Never put a control where it makes the correct behaviour impossible. A rule that stops honest work from being recorded does not produce compliance; it produces a parallel process, and then you have lost the record entirely.
The second gate, further down
Receiving is not the only place a quantity mismatch matters, and a control at the door does not help if the money leaves anyway. So there is a second refusal at the point of payment, and it is worth understanding as a pair with the first.
When an order does not reconcile against what was received, payment is refused by default. Every route that pays a supplier asks the same question through the same gate, which matters more than it sounds — a check added to one of several payment screens is theatre, because whoever needs to get paid finds one of the others.
There is an override, and it is built with the assumption that it will be used. It requires a permission deliberately distinct from the one that approves purchase orders, because approving an order is routine work and paying past a failed match is not. It requires a written reason. It records who and when. And it withdraws itself if the order later reconciles or if the discrepancies change — because an authorisation granted for one problem should not keep releasing money for a different one.
| Situation | Default behaviour | Configurable? |
|---|---|---|
| Receiving more than ordered | Refused, zero tolerance | Tolerance percentage, or turn the block off |
| Receiving less than ordered | Reported as an exception | By design, not configurable to refuse |
| Paying an order that does not reconcile | Refused | Can be switched to warn instead |
| Paying before anything is received | Warns — prepayments are legitimate | Can be switched to refuse |
That last row is the counterpart to the short-delivery decision. Prepayments, deposits and proforma terms are ordinary commerce, so refusing them by default would break working businesses on day one. It warns, and an organization whose policy is stricter turns it on.
What AWRA OpsHub does today
- An over-receipt against an order is refused, by default, with zero tolerance, before any record is written.
- Every prior delivery against the order is counted, so a fully received order cannot be received again.
- The refusal is specific — item, incoming quantity, running total, ordered quantity, and the overage — and names the two legitimate ways forward.
- Payment is refused when the order does not reconcile, through a single gate that every payment path asks.
- The payment override needs its own permission and a written reason, and withdraws itself if the order reconciles or the discrepancy changes.
- A purchase order cannot be closed without a check-in recorded against it.
What it does not do
- A receipt with no purchase order behind it is not measured. Opening stock, donations and returns legitimately have no order to check against, and the guard returns early for all of them — which also means booking goods in without an order is the way around it.
- The guard measures quantity, not price or quality. A delivery of exactly the right count at the wrong price passes the door; that mismatch is caught later, at the payment gate.
- A systematically short supplier is not stopped here. Short deliveries are reported rather than refused by design, so the place that pattern becomes visible is the vendor scorecard rather than the receiving screen.
Not ours, by choice
- We will not let a control make honest work impossible. Short deliveries are reported and never refused, because a system that stops a warehouse booking in goods standing on its floor gets bypassed, and a bypassed control is worse than an absent one.
- We will not offer a quiet override. Paying past a failed match requires a different permission from approving the order, a reason in writing, and a record of who — and if that feels like friction, that is the control working rather than a rough edge.
A guard on receipts that have no order behind them — approval to book in unordered stock above a value, say — is scope rather than a ceiling. The refusal machinery, the settings model and the exception reporting all exist and work; this would be a specification and a price.
If you want to test this in an evaluation, do it in the specific way that matters: receive an order in full, then try to receive against it again. A guard that only inspects the receipt in front of it will let the second one through, and that is the version of this check most systems ship.
What to set before go-live
The defaults are deliberately strict, which means the work at go-live is deciding where you genuinely need slack rather than deciding whether to switch anything on.
-
Decide your tolerance, in a number you can defend
Zero is the default and it is right for most businesses. If your suppliers ship full cases against part-case orders, work out the largest honest overage that creates — usually a few percent — and set that, rather than a round number chosen because it felt generous.
-
Decide who can amend an order
The guard sends the storekeeper back to somebody who can change the order. If that person is unreachable at four in the afternoon, the control becomes a queue of lorries, and the pressure to work around it starts immediately. Name a real person and a fallback.
-
Decide who holds the payment override
It is a separate permission on purpose. Giving it to everyone who approves purchase orders quietly returns you to having no gate at all, which is the most common way this control is dismantled.
-
Decide the rule for receipts with no order
This is the documented way past the guard, and that is fine as long as it is deliberate. Decide who may book stock in without an order, for what — opening balances, donations, customer returns — and check the list periodically rather than assuming it stays short.
-
Watch the short deliveries
They are reported rather than refused, which means somebody has to actually look. A supplier who is consistently three percent short is charging you for stock you never received, and the only place that becomes obvious is in the pattern.
Why this belongs at the door rather than in the review
Everything described here could in principle be caught later — in a reconciliation, in an audit, in a month-end review. The argument for putting it at the receiving door instead is about what is recoverable.
An over-receipt caught at the gate is a phone call. The lorry is still there, the driver still has the goods, the order can be amended or the extra sent back, and nothing has entered your stock or your ledger. An over-receipt caught in a month-end review is an argument with a supplier about a delivery six weeks ago, about goods that have since been sold or moved or lost, with a signed delivery note on their side and a stock figure on yours that already includes the extra.
The same reasoning is why the payment gate matters as a pair with the receiving one. Money that has left is materially harder to recover than money that has not, regardless of who was right.
The matching logic behind the payment gate is set out in what is three-way matching, the receiving paperwork in the goods receipt note, and the supplier-pattern view in scoring suppliers on evidence.
Our take
Refuse the thing that has no honest version, report the thing that usually does, and never build a control that makes correct work impossible to record. Over-receipt is refused by default here with no tolerance, counting every previous delivery against the order; short delivery is reported and never blocked. When you are evaluating any system, the test worth running is the second one: receive an order in full, then try to receive against it again. That single test separates a real receiving control from a check that only reads the page in front of it.
See the receiving controls
Over-receipt refused with a tolerance you set, every prior delivery counted against the order, short deliveries reported as exceptions, and a payment gate that every payment path has to ask.
Explore procurement controlsFrequently asked questions
What happens if a supplier delivers more than we ordered?
The receipt is refused before anything is written, so no partial record is left behind. The message names the item, what is being received, what the running total would become, what was ordered and by how much it exceeds — and points at the two legitimate ways forward: raise the over-receipt tolerance in procurement settings, or amend the order to reflect what was genuinely agreed. The default tolerance is zero percent, so out of the box any overage at all is stopped.
Does it stop us receiving a partial delivery?
No, and that is deliberate rather than an oversight. Short deliveries are reported as exceptions and never refused, because partial shipments and back-orders are ordinary commerce. A control that stops a warehouse booking in goods that are physically standing on its floor does not produce compliance — it produces a workaround, and then the record is lost entirely. The cost of that choice is that a consistently short supplier is not stopped at the door; that pattern shows up in the vendor scorecard instead, so somebody has to look.
Can the same order be received twice?
No. The guard sums every prior check-in booked against the order rather than examining only the receipt in front of it, so an order for one hundred already received in full has nothing left to receive against. This is the specific thing worth testing in any evaluation, including ours — many implementations check the current receipt in isolation, which means each individual delivery looks perfectly correct while the order is received twice over.
Is there a way around the check?
Yes, and we would rather name it than have you find it. A check-in with no purchase order behind it has nothing to be measured against, so the guard returns early — that is necessary, because opening stock, donations and customer returns legitimately have no order. It also means booking goods in without an order bypasses the control. Decide who may do that and for what, and review the list periodically rather than assuming it stays short.
What stops us paying for the extra anyway?
A second gate at the point of payment. When an order does not reconcile against what was received, payment is refused by default, and every route that pays a supplier asks that same question through the same gate rather than each screen having its own version. There is an override, because sometimes there is a real reason — it needs a permission deliberately different from the one that approves purchase orders, a written reason, and it records who and when. It also withdraws itself if the order later reconciles or the discrepancies change, so an authorisation granted for one problem cannot keep releasing money for another.
Can we pay a supplier before receiving anything?
By default yes, with a warning, because prepayments, deposits and proforma terms are legitimate and refusing them outright would break a great many working businesses. If your policy is stricter, one setting turns that warning into a refusal. The asymmetry with the discrepancy check is intentional: a mismatch between the order and the receipt has no ordinary explanation, whereas paying in advance frequently does.
