Skip to content
Robnu

RTO, RTV, DTO — three losses, one label.

They look the same on a dashboard and cost you entirely different amounts. Tracking them as one number is why most sellers cannot say which part of their returns is actually bleeding.

Free during early access · Forever free under 25 orders/day
app.robnu.com/returns/scanReceive scanAWB · return_id · forward_shipment — auto-resolvesAWB 7782115983ResolutionAWB matchedOrderReturn · OR-892Status → receivedclaim_due_at +60dscan_event writtenCtrl+KOpen scan from anywhere — global topbar shortcut
TL;DR
  • RTO = return to origin. Delivery failed; the customer never took possession.
  • RTV = return to vendor. An inventory movement back to a supplier, not a consumer return.
  • DTO / customer return = the buyer received the product, then sent it back.
  • The claim routes differ: RTO claims are about freight accuracy, customer returns about goods condition.
  • Robnu separates them automatically so you can see which one is costing you. Free while we figure out pricing.

Search interest in the difference between these terms is high for a simple reason: the words are used loosely across panels and courier systems, and getting them wrong sends your claim down the wrong route. This guide draws the lines clearly.

The dividing line

One question separates them

Did the customer ever take possession? That single question does most of the classification work. If delivery never completed, you are looking at an RTO. If the buyer received it and then sent it back, you are looking at a customer return. RTV sits outside both, describing stock going back to a supplier.

The reason to be strict about this is evidence. In an RTO the parcel was never opened by anyone, so condition disputes rarely arise. In a customer return the parcel has been opened, and what comes back may not be what went out — which opens an entirely different set of claims.

One number hides two problems
A combined returns percentage tells you that money is leaving. It does not tell you whether the cause is delivery failure or product mismatch — and those need opposite fixes.
app.robnu.com/ajio/ordersOpen ordersSynced from the marketplace · normalised into one schemaOrderSKUStageStatusManifestedManifestedConfirmedConfirmedSlip readySlip readyAwaitingAwaitingOpenOpenManifestedManifestedSlip readySlip ready
Side by side

What each one means for you

Same outcome on the surface — stock coming back. Completely different underneath.

Delivery failed

RTO

Customer never received it. Cost is freight in both directions plus lost margin. Claims centre on charge accuracy — weight, duplicates, parcels never returned. Fix the cause via addresses and prepaid conversion.

Supplier side

RTV

Goods going back to a vendor or supplier — defective stock, wrong consignment, unsold inventory under agreement. An inventory and procurement matter, not a marketplace delivery outcome.

Post-delivery

DTO / customer return

Buyer received it, then returned it. Opens condition disputes: used goods, empty boxes, swapped items. Evidence at opening is everything.

app.robnu.com/returns/claim-routesDifferent return, different claim routeUsing the wrong route is a common rejection reasonRTO - freight accuracyweight, duplicatesRTO - never returnedlost in transitCustomer return - conditionphoto + videoRTV - supplier termscontractualEach route needs different evidence gathered at a different moment.
app.robnu.com/returns/scanReceive scanAWB · return_id · forward_shipment — auto-resolvesAWB 7782115983ResolutionAWB matchedOrderReturn · OR-892Status → receivedclaim_due_at +60dscan_event writtenCtrl+KOpen scan from anywhere — global topbar shortcut
The Robnu way

Separating the losses automatically

The classification work is mechanical: check whether delivery completed, tag the return accordingly, apply the right claim route. Mechanical work done by a tired person at the end of a dispatch day is where errors and missed claims come from.

Robnu is an agentic OMS. It categorises every return by what actually happened, tracks the two loss rates independently so you can see which is hurting, and routes each claim down the correct path with the right evidence attached. Filing happens 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.

FAQ

RTO vs RTV vs DTO, answered

RTO means return to origin — a parcel that could not be delivered to the customer and is sent back to you. RTV means return to vendor, which describes goods being sent back to a supplier or vendor, typically in a stock or wholesale context rather than a consumer delivery one. RTO is a failed sale; RTV is an inventory movement. They belong in different parts of your accounts.

DTO is generally used for a direct-to-origin or customer-initiated return flow, where a buyer who has received the product initiates sending it back. The key distinction from RTO is possession: in a DTO the customer took delivery first. That difference changes the evidence available to you and the claim routes open when something is wrong with what comes back.

Because the charges and the claim rights differ. An RTO is freight-heavy and rarely involves product condition disputes, since the customer never opened it. A customer-initiated return frequently does involve condition disputes — wrong item, used item, empty box — which are claimable in ways an RTO is not. Lumping them together means you never see which category is actually bleeding.

No. RTO claims are typically about freight accuracy: wrong weight, duplicate charge, parcel never returned. Customer-return claims are typically about goods condition and require evidence at the moment of opening — photos and unboxing video. Using the wrong claim route for a case is a common reason claims get rejected.

It depends on your category, and that is exactly why separating them matters. High-value fashion often bleeds most through customer returns with condition disputes. Low-value high-volume categories usually bleed through RTO freight. Without separate tracking you cannot tell which problem you have, and you end up fixing the wrong one.

Not entirely. Terminology varies between platforms and between courier partners, and some panels use RTO loosely for any return. Rather than trusting the label, look at the underlying facts: did the customer ever take possession, and was the parcel opened? Those two questions determine the real category regardless of what it is called.

Tag every return with whether delivery completed before the return began. That single field splits RTO from customer-initiated returns cleanly and lets you compute the two loss rates independently. Most sellers keep one combined returns number, which is why the underlying causes stay invisible.

No, and treating them the same leads to the wrong fixes. High RTO points to address quality, cash-on-delivery exposure and delivery-side failure. High customer returns point to sizing, product description accuracy and expectation mismatch. The remedies share almost nothing.

build 784fa3bcf2c49040d2767e4be9bbfa4d11b7f32f · 2026-07-21T20:33:16+05:30