“Set RTO” on DTDC, decoded.
Courier scans use their own vocabulary, and it rarely matches what your marketplace panel says. Here is what each DTDC return scan means for a seller — and which ones are worth challenging.
- Set RTO = the courier has flagged your shipment for return. Delivery will not be re-attempted.
- RTO Accepted = the return has entered the reverse network and is moving.
- RTO Delivered = the courier says it handed the parcel back to you. Verify, do not assume.
- 'Shipper instructed to RTO' often does not mean you instructed anything — query it.
- Robnu matches every courier scan against what you were actually charged. Free while we figure out pricing.
If you sell on Indian marketplaces, a share of your parcels move on DTDC and you will read these scans on tracking pages. The language is operational rather than seller-friendly, and the gap between what a scan says and what actually happened is where recoverable money tends to sit.
Courier language vs panel language
Your marketplace panel and your courier tracking describe the same journey in different vocabularies. Meesho might show RTO Locked while DTDC shows Set RTO. Neither is wrong; they are describing the same shipment from different systems.
This matters when you dispute a charge. The courier scan history is often your strongest evidence, because it carries timestamps and weight records that the marketplace deduction line does not show.
The DTDC return scans you will see
Four scans cover almost every return journey. Each tells you something different about where your parcel and your money are.
Set RTO
The return has been flagged. Delivery attempts stop here. This is your earliest warning that a reverse charge is coming, and the best moment to note the shipment for later verification.
RTO Accepted
The reverse network has taken the shipment in. The parcel is now genuinely moving back rather than sitting at a delivery hub awaiting a decision.
RTO In Transit
Travelling back. Slower than the forward leg. A shipment that stalls here for weeks is a likely lost-in-transit case.
RTO Delivered
The courier says you have it. Check against your inward record — this is the scan most worth verifying, because it closes the journey and starts the claim clock.
Matching scans to deductions
The verification job is conceptually simple: for every RTO scan, confirm a parcel came back and confirm the charge matched the shipment. Doing it across every courier and every order, weeks after the scan, by hand, is not realistic.
Robnu is an agentic OMS. It follows each shipment through its scans, notices the returns that were charged but never arrived, and reconciles the reverse-freight line on your settlement against the weight and lane the parcel actually travelled. Mismatches become claims automatically — with a rare approval click while fully-autonomous filing rolls out.
You sell. Robnu runs the rest — and makes sure every rupee is paid correctly.
DTDC RTO scans, answered
Set RTO is a courier-side scan indicating that the shipment has been flagged for return to origin. Delivery will no longer be attempted and the parcel is being routed back to the sender — you. It is the DTDC equivalent of an RTO being initiated, and it marks the point where the shipment stops being a delivery and becomes a return.
Usually the courier, acting on a delivery outcome: repeated failed attempts, a refused cash-on-delivery parcel, or an undeliverable address. It can also be triggered by the marketplace after a cancellation, and occasionally by an explicit shipper instruction. The tracking history is what tells you which of these applied to a given shipment.
RTO Accepted means the return has been formally taken into the reverse network — the shipment has been received into the return flow and is being processed for the journey back. It is a step forward from Set RTO, confirming that the return is moving rather than merely decided.
RTO Delivered means the courier has recorded handing the returned parcel back to you at your pickup address. Treat it as a claim to verify rather than a fact: it records a delivery event, not proof that you received a correct and intact parcel. Check it against your own inward record.
Raise it promptly, because the claim window is short. Collect what you can — your inward register showing no receipt, any gate or camera evidence, and the tracking history itself. Being billed reverse freight for a parcel that never came back is exactly the kind of charge that is recoverable if challenged in time.
That scan indicates the return was triggered by an instruction attributed to the sender rather than by a failed delivery. Sellers frequently find this confusing because they gave no such instruction — it can originate from a marketplace-side cancellation or an operational decision upstream. If you did not request it and the order was live, it is worth querying.
Reverse freight is generally borne by the seller, and it appears as a deduction on your marketplace settlement rather than as a direct courier bill for marketplace-managed shipments. What you should verify is that the amount matches the actual weight and lane — reverse charges billed on an inflated weight are common and disputable.
Work from evidence: the original dispatch weight, the tracking history, and the settlement line showing what you were charged. Where the charge does not match the shipment, raise it through the marketplace channel that handles deductions rather than with the courier directly, since the marketplace is who deducted it. Do it inside the claim window.