Three Places This System Will Refuse You
Every procurement system advertises controls. The question worth asking is narrower: where will it actually stop you? Ours stops you in exactly three places. Everywhere else it warns, records, or does nothing — including on a budget overrun.
There is a difference between a control and a screen where a control could be configured, and almost every procurement evaluation confuses the two. The test is simple and nobody applies it: ask the vendor to make the system say no.
Our answer to that test
Three refusals. You cannot raise an order against an unapproved request. You cannot receive more than you ordered, counting every earlier delivery. You cannot pay an order whose documents disagree. Everything else — including a budget overrun — warns or records. Design your governance around those three and around what you enforce with people.
Refusal one: the unapproved request
A purchase order cannot be raised against a requisition that has not been approved. Not warned about, not flagged for review — refused. The request must be in an approved or already-procured state before the chain can continue.
That is the most important of the three, because it is the one that makes everything downstream mean something. A system where an order can be raised without a request has no procurement process; it has a purchasing form with an audit trail.
Refusal two: the over-receipt
More than the order allows is refused at the receiving door, before anything is written, counting what was already received so a split delivery cannot creep past one lorry at a time. There is a tolerance you set, and the refusal can be softened to an exception, but the default is a stop.
Its mirror image is deliberately not a refusal: a short delivery is always accepted and recorded, because refusing goods that are physically on the floor produces a lie rather than a stop. That reasoning is set out in One Refusal and One Record.
Refusal three: the payment
A single gate decides whether an order may be paid, and every payment path in the product calls it — the web, the API, manual vendor payments, two mobile-money routes and the card processor. A discrepancy between what was ordered and what was received blocks payment by default.
The override is the interesting part. It needs a dedicated permission that is deliberately not the one that approves purchase orders, plus a written reason recorded with who and when — and it is pinned to the discrepancy count it authorised, so if the documents change into a different problem the authorisation withdraws itself. A stale approval cannot keep releasing money.
Three refusals, one of which took finding six separate payment doors to build. That number is the honest measure of how hard a real control is.
And the one everybody assumes is a refusal
A budget overrun is a warning. There is no hard stop, no percentage threshold ladder, and no escalation. Approved orders count as commitment against the budget and the burn rate is reported, and if you spend past the number the system tells you and lets you.
We are stating this plainly because a feature page of ours once claimed otherwise, and the claim was corrected rather than quietly removed. Budgets here are a measurement instrument, not a gate.
Why a transit economy needs to know exactly where the stops are
Because in a port and logistics economy a large share of procurement is not routine replenishment. It is time-critical: a part for a vessel, a component for a handling system, a consumable for a client's consignment that is on a clock.
In that setting, knowing where the system will stop you is not an academic question about governance. It is operational planning. A refusal you did not expect at eleven at night, with nobody available to override it, is a delay with a cost attached — and a refusal you expected is a five-minute conversation before anybody is standing at the door.
The practical implication is about who holds the override permission and when they sleep. The payment gate's override is the one that will bite out of hours, and it needs more than one holder.
A fourth refusal, if you need one
The refusals above are the ones we built because they prevent the losses we could evidence. Where an organisation needs another, the honest position is that it is a build rather than a setting, and the two most often asked for are these.
A hard budget stop
A refusal rather than a warning when an order would take a budget past its limit. Straightforward mechanically; the hard part is the override policy, because a hard stop with a freely available override is a warning with extra steps.
A quality gate at receipt
Holding received stock as unavailable until an inspection passes. A batch already carries a quality status and stock already has hold states, so the pieces exist and are not wired to each other.
A value-tiered approval ladder
Different approvers above different amounts, on the requisition. Approval today is by permission and by named steps rather than by value bands.
No dates on a public page. If a specific refusal is a governance requirement — a donor condition, an audit finding, a board resolution — describe it and we will come back with a written scope, timeline and cost.
Scope a controlWhat AWRA OpsHub does today
- REFUSES: raising an order against a requisition that is not approved.
- REFUSES: receiving beyond the ordered quantity plus tolerance, counting prior receipts, before anything is written.
- REFUSES: paying an order whose ordered and received quantities disagree beyond tolerance, on all six payment paths.
- WARNS: paying before receipt, which is legitimate for prepayments and can be switched to a block per organisation.
- RECORDS: short deliveries, over-receipts where the block is disabled, and every override with its reason, actor and time.
What it does not do
- A hard budget stop. An overrun is a warning; there are no percentage thresholds and no escalation ladder.
- A quality or inspection gate at receipt.
- A value-tiered approval ladder on the requisition.
- Any refusal based on supplier performance, because no performance figure is ever computed.
- A refusal when a supplier document has expired — the dates are stored and nothing reads them for suppliers.
Not ours, by choice
- Three refusals is not a small number for this class of product, and the payment gate in particular is stronger than the norm. This page is a map, not a complaint.
- Every refusal here has an override or a switch except the requisition one. That is deliberate: a control nobody can pass is a control that gets removed.
- Nothing here is Djiboutian. It is a map of the stops; a transit economy is simply where knowing them in advance is worth the most.
The evaluation question almost nobody asks
Make the system say no. Any control you like — you choose.
A good answer sounds like
A live refusal, on screen, with the message it produces.
What it actually means
A vendor who cannot produce one refusal in a demonstration has configuration screens rather than controls.
Is a budget overrun a stop or a warning?
A good answer sounds like
One word.
What it actually means
This is the single most over-claimed control in procurement software. Ours warns, and we correct our own copy when it says otherwise.
Who can override each refusal, and is it the same permission as approving?
A good answer sounds like
Different permissions, named.
What it actually means
An override sharing a permission with the approval it overrides is not a separation of duties.
Does an override expire, or does it stand?
A good answer sounds like
Pinned to what it authorised.
What it actually means
Ours self-withdraws when the discrepancy changes. A standing override is a permanent hole with a reason attached.
Decide who holds the override, and when they sleep
Three refusals, three override policies, and at least two people for each. An hour of role design before go-live is worth more than any feature on this page.
Design the rolesFrequently asked questions
Can the requisition refusal be turned off?
No, and it is the one refusal with no switch. That is deliberate — an order raised without an approved request would make every control downstream of it decorative.
If a budget only warns, what is it for?
Measurement and commitment. Approved orders count against the budget rather than only paid ones, so the figure reflects money promised, and the burn-rate warning tells you when consumption is outpacing time elapsed. That is genuinely useful management information, and it is not a gate.
What happens if nobody with the payment override is available?
The payment waits. That is the correct outcome and it is also an operational risk you should plan for by granting the permission to more than one person — the gate is doing its job, and a gate with a single keyholder is an availability problem rather than a control.
