The Goods You Cannot Send Back
Goods can arrive against a purchase order, and goods can leave to a customer. The one direction our system has no path for is back to the supplier who sent them — so a rejected delivery leaves your books as a write-off, which is the one exit with nobody on the other side of it.
Stock moves in a small number of directions, and a system tends to be judged on the ones it handles. Ours handles arrival carefully: what physically turned up is counted rather than copied from the order, an over-delivery is refused against everything already received, and a short delivery is recorded and reported without ever being blocked.
It handles departure to a customer carefully too, including the reverse — a till return puts the stock back and reverses both the revenue and the cost of sales, with the cost leg conditional on whether the goods were actually fit to restock.
What it has no concept of at all is sending something back to the supplier.
What actually happens to a rejected delivery
Follow it through, because the sequence is worse than any single step in it.
The goods arrive and are received, because they physically turned up and refusing to record them would be worse. They are now stock, available, at a location. Somebody inspects them and marks them as failed — and as we have written elsewhere, that mark does not hold the stock either, so they remain available to be picked and sold while the argument with the supplier is going on.
Then the supplier agrees to take them back, which is the good outcome. And there is nowhere to record it. The goods leave the building physically, and inside the system the only mechanism that will remove them is a stock adjustment — a write-off, with a reason chosen from a list, and no link to the order they came from, the supplier who supplied them, or the credit you are now owed.
A return to a supplier is the most documented thing that happens in a warehouse and the least documented thing in our database.
What actually happened
- Goods were rejected for a stated reason
- The supplier agreed to take them back
- They physically left on a specific date
- A credit is now owed against a specific order
- The payment for that order should not be released
- A commercial event with two parties and a paper trail.
What the system records
- Stock reduced by an adjustment
- A reason code chosen from a list
- Whoever raised it, and whoever approved it
- No supplier, no order, no expected credit
- Nothing that affects what is payable
- A loss, indistinguishable from breakage.
The three things that go wrong, in cost order
The credit is not tracked by anything. The money you are owed exists only in an email thread and somebody's memory. Nothing in the system is expecting it, so nothing notices when it does not arrive, and there is no report of credits outstanding because there is no such record type.
The payment control is bypassed by accident. Our matching compares what was ordered against what was received, and a payment is blocked when they disagree. Goods that were received and then returned still count as received, so the order looks reconciled and the payment gate has no objection — you are cleared to pay in full for goods you sent back.
Your loss figures are wrong in a way that hides a supplier problem. A returned delivery lands in the same bucket as damage and breakage. So the supplier who ships you unusable goods every month shows up in your accounts as shrinkage, and in the supplier record as nothing at all — which is the same blind spot as the empty performance scorecard, arriving from a different direction.
Why we are putting this on the Gulf
Because of the length of the chain rather than anything regulatory. A great deal of what is consumed here arrives through a long import route — a supplier somewhere else, a freight leg, a port, a clearing agent, an inland movement — and every additional handover is another opportunity for what arrives to differ from what was ordered.
Long chains also make rejection expensive and slow to resolve. The counterparty is in another country and another time zone, the credit is a negotiation rather than a formality, and the goods may sit for weeks while it is settled. That is precisely the situation in which you need the system to be holding the position for you — what was rejected, when it left, what is owed, and what must not be paid in the meantime — and it is exactly the situation where a write-off with a reason code tells you none of it.
What to do today
Do not let the write-off be the whole record. Attach the supplier's acknowledgement to the adjustment, note the order in the reason or description, and keep a manual list of expected credits that somebody owns. Then hold the payment yourself, because the matching will not — the order will look reconciled. It is a procedure rather than a control, and it is the honest answer until there is a record type for this.
Two, and the first is the record that everything else hangs on
This is a genuine gap rather than a reporting one, so it needs a new record type — but a small one, and the surrounding machinery already exists.
A supplier return as a record
Linked to the order and the supplier, carrying the lines returned, the reason, the date they left and the credit expected. Stock leaves through it rather than through a write-off, so a return stops looking like breakage in your loss figures and starts appearing in that supplier's history.
Returns reflected in what is payable
The matching should treat returned quantities as not received, so the payment gate that already exists blocks payment for goods you sent back. The gate is the single definition of payability across every payment route, so this is one input to an existing control rather than a new one.
The second is what makes the first worth building. A return record that does not change what you owe is a filing improvement; a return record that stops the payment is a control.
Talk to us about supplier returnsFour questions about the direction nobody demonstrates
Show me a goods return to a supplier, end to end.
What a straight answer sounds like
A flow, or an admission. Ours is an admission.
Why it matters
Every demo shows goods arriving. Almost none shows them going back, and that is the direction with the money attached.
After a return, what does the system say is payable?
What a straight answer sounds like
A reduced figure. Ours says the full amount.
Why it matters
This is the expensive consequence — the control you are relying on is satisfied by goods you no longer have.
Where do I see credits owed to me by suppliers?
What a straight answer sounds like
A report. Ours has none.
Why it matters
Untracked credits are money that quietly does not arrive, and nobody is assigned to notice.
Do returns appear in that supplier's history?
What a straight answer sounds like
Yes, or no. Ours is no.
Why it matters
A supplier whose goods you reject monthly should look different from one whose goods you never reject. Ours look identical.
What AWRA OpsHub does today
- Customer returns at the till, with stock returned and both revenue and cost of sales reversed, the cost leg depending on whether the goods can be restocked.
- Over-receipt refused against everything already received on the order, with a tolerance you set.
- Short deliveries recorded and reported, with the order left open for the balance.
- Attachments on adjustments, which is where the supplier's acknowledgement can at least be kept.
What it does not do
- No return to supplier of any kind. No record type, no document, no flow.
- No debit note, so what you are claiming back is not expressed anywhere.
- No expected credit tracking, and therefore no report of credits outstanding.
- No link from returned goods to the order or supplier they came from, so returns are invisible in supplier history.
- Returns do not affect payability — a returned delivery still reads as received, so the payment gate is satisfied.
Not ours, by choice
- We make no claim about when a debit note is legally required or what it must contain. The instruments themselves are explained in credit notes versus debit notes; what your jurisdiction requires is your adviser's question.
- We describe no country's invoicing rules in this post, in this region or any other.
The verdict
Receiving is one of the better-built parts of this product and returning is one of the emptiest, and the two sit either side of the same doorway. The practical effect is that a rejected delivery leaves your business as a loss with no counterparty, your supplier's record looks clean, and the payment control reports itself satisfied. If your goods arrive down a long import chain where rejection is a real and recurring event, this is the gap in our procurement module we would most want you to know about before you buy — and the one question worth asking every vendor is not whether they handle returns, because they will all say yes and mean the till.
Tell us how often you send things back
How often, to whom, and what happens to the credit. We will be straight about what has to be a procedure rather than a control today, and what the return record would change for you.
Talk to us about supplier returns