“Shipper instructed to RTO” — but you never asked.
The scan says the sender requested the return. You requested nothing. Here is what really triggers it, why the charge still lands on you, and how to build the case for getting it back.
- The scan means the return was ordered by instruction, not caused by failed delivery attempts.
- 'Shipper' usually resolves to the marketplace, not to you personally.
- Most common cause: the order was cancelled after you had already dispatched it.
- The reverse freight still typically lands on you as a settlement deduction.
- Robnu tracks post-dispatch cancellations and flags the charges worth challenging. Free while we figure out pricing.
This scan generates a particular kind of frustration, because it appears to assign responsibility to the seller for something the seller did not do. Understanding what the words actually mean in courier terminology turns it from an accusation into a documentable case.
Who the “shipper” really is
In courier terminology the shipper is whoever booked the shipment. On a marketplace order, that booking is made through the marketplace’s logistics arrangement — so the shipper of record is effectively the marketplace, even though the goods and the cost are yours.
When the marketplace cancels an order that has already left your premises, it issues a return instruction to the courier. The courier records that instruction against the shipper account. Nothing in that chain involves you making a decision — but the scan text reads as though you did.
The three records that make the argument
A dispute here succeeds on timeline, not on indignation. You need to show a compliant dispatch followed by a cancellation you did not initiate.
Your dispatch proof
Handover scan and timestamp showing you shipped within your SLA window. This establishes you did your part correctly.
The cancellation timestamp
Order status history from the panel showing when the order was cancelled and by whom. If it postdates your dispatch, the return was not your doing.
The courier scan trail
The instruction scan and its timestamp, showing the return was ordered rather than caused by exhausted delivery attempts.
Catching the returns you did not cause
Each of these cases is winnable and each requires assembling three records from three different systems within a short claim window. One case is annoying. Ten a month is a part-time job nobody has time for.
Robnu is an agentic OMS. It holds the dispatch record, watches for orders cancelled after dispatch, and ties the courier scan trail to the settlement deduction. When a reverse charge lands for a return you did not cause, it assembles the timeline and files the claim — a rare approval click while fully-autonomous filing rolls out.
You sell. Robnu runs the rest — and makes sure every rupee is paid correctly.
Shipper-instructed RTO, answered
It is a courier scan recording that the return was triggered by an instruction attributed to the shipper — the sender of the parcel, which on a marketplace order means you or the marketplace acting on your behalf. It distinguishes the return from one caused by a failed delivery attempt. The parcel is being sent back because someone asked for it, not because the customer could not be reached.
Because 'shipper' in courier terminology usually resolves to the marketplace, not to you personally. When a marketplace cancels an order after dispatch — for a customer cancellation, a payment failure, a policy action or a fraud check — the return instruction is issued by the marketplace but recorded against the shipper account. From the courier's perspective the sender asked for it back; from your perspective nobody asked you anything.
In most marketplace arrangements the reverse freight still lands on the seller as a settlement deduction. This is precisely why the scan is worth understanding — you may be absorbing the cost of a return that was triggered by a cancellation entirely outside your control, and that is the basis for querying it.
It is worth raising, particularly where the underlying cause was a customer-side or platform-side cancellation rather than any action of yours. Build the case on the order timeline: when the order was placed, when you dispatched, when the cancellation occurred, and when the return was instructed. If the cancellation came after your dispatch and was not your doing, that is the argument.
A normal RTO follows failed delivery attempts — the courier tried and could not complete. A shipper-instructed RTO short-circuits that: the return is ordered without exhausting delivery attempts. Practically, the parcel often comes back faster, but the cost treatment is usually the same and the cause is quite different.
It generally counts as a return outcome in your metrics, which is part of why it is frustrating — a cancellation you did not cause can read as a delivery failure in your numbers. Where these are frequent and traceable to platform-side cancellations, it is worth raising as a pattern with seller support rather than case by case.
The full courier scan history showing the instruction and its timestamp, your dispatch record showing you shipped on time, and the order status history from the marketplace panel showing when and why the cancellation occurred. Together these establish that the return was instructed after a compliant dispatch.
You largely cannot prevent post-dispatch cancellations — they originate with the customer or the platform. What you can do is catch them: track which orders were cancelled after dispatch, verify the reverse charge for each, and challenge the ones where the cost should not sit with you. The prevention lever is reconciliation, not operations.