One Refusal and One Record
Receive more than you ordered and the system refuses, counting every earlier delivery so a split consignment cannot creep past the order one lorry at a time. Receive less and it never refuses at all. The asymmetry is deliberate, and the reasoning behind it is worth more than the feature.
A receiving door is where a procurement system either earns its place or becomes something people work around. Ours refuses in one direction and never refuses in the other, and it is worth understanding why before you decide whether you agree.
Too much: refused, before anything is written
A receipt for more than the order allows is checked before the movement is recorded. Nothing is written, so a refusal leaves no half-finished record to clean up afterwards.
The check counts what has already been received against that order. This is the detail that makes it a control rather than a formality: without it, an order for a hundred could be received as sixty, then sixty again, and each individual receipt would pass because each is under the ordered quantity. Split deliveries are exactly how an over-receipt gets in.
There is a tolerance, set per organisation, because a supplier shipping a full pack when you ordered a partial one is ordinary rather than suspicious. And the block itself can be switched off — but even then, an over-receipt is recorded as an exception rather than passing unnoticed. Turning off the refusal does not turn off the observation.
A control you can disable and still be told about is a better control than one you can only disable entirely.
Too little: reported, never refused
A short delivery is recorded as a shortage and the receipt goes through.
This is the decision worth arguing about, so here is the argument. The goods are physically on the floor. A storekeeper standing in front of sixty units, with a lorry waiting, told by a screen that they may not book them in, has three options: leave the goods unrecorded, wait for somebody with authority, or book in a hundred to get past the screen.
Every one of those is worse than recording sixty. The third is the worst of all, and it is the one that will happen, because it is the only one that lets everybody go home. A control that can only be satisfied by lying to the system is a control that produces lies.
So the shortage is recorded, the order stays open for the balance, and the discrepancy is visible to the two-way match and to the payment gate behind it. Nothing was refused and nothing was hidden.
Why this reads differently in South African distribution
Because receiving here is frequently done at a site where the person at the door has no authority to make a commercial decision, and the person who does is in another city and not answering their phone at four in the afternoon.
That gap between physical authority and commercial authority is the thing the design is really about. A refusal is only useful where somebody present can resolve it. Where nobody present can, a refusal converts into a workaround within a fortnight, and the workaround is permanent.
| At the door | Who can resolve it there? | So the right behaviour is |
|---|---|---|
| More than ordered arrived | Yes — refuse the excess, or accept and record it as an exception | Refuse by default, with a tolerance and an override |
| Less than ordered arrived | Nobody — the missing goods are not there to be argued with | Record what came, keep the order open, flag it |
| Nothing has arrived yet | Nothing to do | Treat the order as open, not as short |
| The wrong goods arrived | Sometimes | Not distinguished — this is a gap, and it is covered below |
Four questions about a receiving control
Receive sixty against an order for a hundred, twice. What happens on the second?
A good answer sounds like
Refused, because prior receipts are counted.
What it actually means
This is the test. A per-receipt check that ignores history is not a control, and it is the common implementation.
What happens when I refuse a receipt — is anything written?
A good answer sounds like
Nothing.
What it actually means
A refusal that leaves a partial record behind creates a cleanup task and, eventually, a reconciliation problem.
Can I switch the block off and still see over-receipts?
A good answer sounds like
Yes, as exceptions.
What it actually means
All-or-nothing controls get switched off entirely the first time they are inconvenient.
Are short deliveries blocked?
A good answer sounds like
No, and a reason why not.
What it actually means
A vendor who blocks short deliveries has not thought about who is standing at the door. Ask them what the storekeeper does next.
What AWRA OpsHub does today
- Over-receipt blocked by default, checked before anything is written, counting every prior receipt on the order so a split delivery cannot creep past it.
- A per-organisation over-receipt tolerance, and a switch to allow rather than block — with over-receipts still recorded as exceptions when the block is off.
- Short deliveries recorded as shortages, never blocked, with the order remaining open for the balance.
- An unreceived order treated as open rather than as a shortage, so new orders do not fill the exception queue.
- File attachment on the receiving record, which has always been available.
- A two-way match and a payment gate behind the receipt, so a discrepancy reaches the money rather than only a report.
What it does not do
- Any inspection or quality gate at receipt. A batch carries a quality status you can set, and nothing holds stock pending inspection before it becomes available.
- A wrong-goods distinction. A substitution is received as whatever it was booked in as.
- A return-to-supplier flow. Rejected goods can only leave as a stock write-off, with no link to the order, the supplier or the credit owed.
- A required attachment. The file can always be provided and can never be demanded.
Not ours, by choice
- The asymmetry between the two directions is deliberate and we would defend it. It is the most transferable idea in the module: design controls around who is standing there when they fire.
- The quality gate is the real gap here, and it compounds with the missing return flow — goods that failed a check are still available to sell while the dispute runs.
- Nothing here is South African. It is about the distance between physical and commercial authority at a receiving door.
What is not built for South Africa today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in South Africa. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If SARS-shaped return output, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
SARS output and e-invoicing
VAT201-shaped return output from live records, a maintained rate history rather than a single preset, and e-invoicing against any prescribed interface — with retries, a failure queue and a reconciliation report.
Banks, EFT and card acquirers
Bank statement feeds, EFT and debit-order files, and card acquirer settlement reports pulled into the Payments Register so receipts match invoices without anyone re-keying a statement.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
EMP201 and EMP501 schedules, UIF declarations and COIDA returns produced in the layout your filing body expects, generated from live payroll records instead of rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedSet the tolerance, and decide who overrides
Two settings and one named person, agreed before go-live. Get those right and the receiving door stops being the place your data goes wrong.
Set it up properlyFrequently asked questions
What tolerance should I set?
Start from how your suppliers actually ship. If they round to full packs, the tolerance needs to cover a pack on your smallest ordered quantity. If they ship exactly what you ordered, set it low — a tolerance wide enough to swallow a real error is not a tolerance, it is a hole.
If I turn the block off, what changes?
Receipts above the ordered quantity are accepted rather than refused, and they are still recorded as exceptions. So you lose the refusal and keep the visibility, which is a reasonable position for a business whose suppliers routinely over-ship by agreement.
What happens to goods we want to reject outright?
There is no return-to-supplier flow, so the only route out is a stock write-off, which carries no link to the order or the supplier and no record of the credit you are owed. That is a real gap and it is the one to plan around: keep the rejection conversation and the expected credit outside the system, and reconcile it deliberately.
