An Automan screen related to this article.
A rejected return is annoying at the counter — but it’s almost always a safeguard doing its job, not a malfunction. The three most common causes:
1. Quantity beyond what’s returnable
The system tracks how much quantity may still be returned from the original transaction (minus earlier returns). Anything beyond that remainder is rejected.
The fix: check the return history on the same invoice — some items were probably returned before.
2. The replacement isn’t the same product
“Replace with goods” compensation only accepts the identical product (same-product rule). That’s deliberate: freely chosen replacements would corrupt cost prices and reports.
The fix: to hand over a different item, complete the return by the rules, then process the other item as a new transaction — both trails stay correct.
3. The transaction changed underneath you (stale tab)
If the return form sat open while the same transaction changed elsewhere (got paid, got returned from another computer), the system rejects a save built on expired data — so decisions never ride on old information.
The fix: reload the page/form, look at the transaction’s current state, and redo the return from fresh data.
The principle behind it
Every one of these safeguards protects the same things: stock, receivables/payables, and reports that still make sense after a return. See how the whole family works in returns, claims & corrections.