Marked RTO: order_reject, and every RTO code decoded.
A reason code is the courier telling you why a parcel turned around. order_reject means the buyer refused it at the door. Here is what each code means, what each one costs you, and which ones you can actually prevent.
Marked RTO: order_reject means the courier has flagged your parcel for return to origin because the buyer rejected it at the delivery point, refused a COD payment, or cancelled while it was out for delivery. Delivery never happened, so this is a pure RTO, not a customer return. The parcel now travels back to your pickup address and the sale is lost.
- order_reject = refused at the door or cancelled while out for delivery. No delivery occurred.
- Pure RTO and customer return are different events with different charges. Read the code.
- Shipper request means the platform or courier turned it around, not the buyer.
- Awaited RTO is where returns stall. It is the status worth chasing, not the loud ones.
- Once a code is stamped, the parcel is coming back. Receive it properly and check the charge.
From out for delivery to back on your shelf
The reason code is stamped once, at the moment the parcel turns around. Everything after it is just the return leg reporting progress.
Every RTO code, and what it costs you
The first four rows are reasons, the last six are progress statuses. Sellers lose money by treating all ten as one thing called an RTO.
| Code or status | What happened | What it means for your money |
|---|---|---|
| order_reject | The buyer refused or rejected the parcel at the door, would not pay COD, or cancelled while it was out for delivery. No delivery took place. | Lost sale. The forward leg and packaging are already spent. A pure RTO typically carries no separate reverse-shipping fee, so question one if it appears. |
| Customer not available or unreachable | Attempts were made but nobody answered the door or the phone across the courier attempt cycle. | Often rescuable before it becomes an RTO. Once it turns around, cost is the same as a rejection. |
| Address incomplete or incorrect | The courier could not locate the delivery point from the address on the label. | The most preventable loss on this list, and the one that repeats by pincode until you fix it at source. |
| RTO (shipper request) or returned at shipper's request | The return was started on the shipper's instruction rather than by the buyer, for example an undeliverable area, a suspended pincode, an expired SLA or a post-dispatch cancellation. | Not a buyer refusal. If you dispatched compliantly and on time, the order timeline is your case for querying any charge. |
| Awaited RTO | The decision to send the parcel back has been taken but the return leg has not started. It is sitting at a facility. | Nothing is billed yet and nothing is moving. This is where parcels go missing, so it is the status to chase. |
| RTO accepted | The return has been acknowledged into the reverse network, typically after a facility scanned it in as a return shipment. | Good news. An accepted RTO has a tracked reverse journey, which is what you need if it later goes missing. |
| RTO initiated | The reverse leg has been created against the shipment. The return booking now exists. | No action for you. Start expecting the parcel and note the date so a stall is measurable. |
| Dispatched for RTO | The parcel has physically left the facility on the return leg and is heading toward your pickup address. | Plan your inward. From here a normal reverse transit time applies for that lane. |
| RTO in transit | The parcel is moving hub to hub inside the reverse network. | Watch for repeated identical scans, which usually mean a stall rather than progress. |
| RTO delivered | The courier has recorded the parcel as handed back to you. | Verify physically before you accept the scan, then check the settlement line for that order. |
Wording varies between couriers and between the panel and the tracking page, so read the sense rather than hunting for an exact string. What never varies is the split that matters: did a delivery happen, and who turned the parcel around. Those two answers decide both what you can claim and what you can prevent.
Rejections cluster, they do not scatter
Group a month of reason codes and the shape is almost always lopsided. That is good news, because a lopsided problem has one fix rather than fifty.
Three moves that shrink order_reject
Shift the mix toward prepaid
A buyer who has already paid almost never refuses at the door. Anything that nudges a shopper from COD to prepaid removes the cheapest way to change their mind.
Catch bad addresses before dispatch
A short landmark, a working phone number and a sane pincode check at packing time turn a certain rejection into a delivery. This is the cheapest fix on the list.
Make the listing tell the truth
Most door refusals are really expectation refusals. Photos, a real size chart and an honest description mean the buyer who ordered is the buyer who accepts.
Every seller meets the phrase the same way: an order looked fine, then the tracking page said marked RTO followed by a word in code. The code is the most useful piece of information in the whole return, and most sellers never read it.
What marked RTO actually is
RTO stands for return to origin, and origin means you. When a courier marks a shipment RTO it is recording a decision: this parcel will not be delivered to the buyer, it will be carried back to the pickup address it came from. The phrase is not a charge, not a penalty and not a status you can argue with by replying to it. It is a fork in the shipment, and the reason code stamped alongside it is the courier telling you which way the fork went and why.
That reason code is stamped once, at the delivery point, and it never changes afterwards. Everything that follows it is progress reporting on the return leg. This matters because sellers routinely read a later status such as RTO in transit as a fresh event and go looking for a new cause, when the cause was decided days earlier at somebody’s front door. If you want the plain-English version of the parent phrase on its own, our what marked RTO means guide covers it without the code table.
The second thing to fix in your head is that an RTO is not a return. A return happens after a delivery: the buyer received the parcel, kept it for a while, and sent it back. An RTO happens instead of a delivery: the buyer never took possession at all. They look identical when the parcel lands back in your warehouse, and they are completely different events in your settlement. Getting the two confused is the single most expensive reading error in Meesho operations, and it is why the reason code deserves thirty seconds of your attention per order.
order_reject, in plain words
order_reject is the code for a refusal at the point of delivery. The delivery partner reached the address, presented the parcel, and the person there said no. In practice that covers a handful of real-world moments that all end the same way: the buyer refuses to accept the box, the buyer declines to pay the COD amount, the buyer says they no longer want it, or the buyer cancelled on the app while the parcel was already out for delivery and the rider was told not to hand it over. Some couriers word it as customer refused, rejected by customer or RTO customer reject. The meaning is the same and the accounting consequence is the same.
What order_reject is not is a failed delivery attempt. If nobody was home, if the phone was unreachable, if the building would not let the rider in, those are unavailability codes, and unavailability usually gets more than one attempt before the parcel turns around. An order_reject typically ends the forward journey immediately, because somebody made a decision rather than missing a doorbell. That difference tells you where to spend your effort: unavailability is a contact-details problem, rejection is an intent problem.
Intent problems have causes you can see in your own data. A buyer who refuses at the door has almost always changed their mind after ordering, and the reasons repeat: they found the same item cheaper somewhere else while waiting, the delivery took long enough that the impulse faded, the product in the photos set an expectation the parcel visibly will not meet, or the order was a casual COD tap with nothing at stake. None of those are random. All of them show up as clusters when you group a month of rejections by SKU, by pincode and by payment mode.
Shipper request is a different animal
RTO (shipper request), sometimes written as returned to origin at shipper’s request or shipper instructed RTO, means the return was started on the instruction of whoever booked the shipment, not by the buyer. On a marketplace order the shipper is the platform or its logistics arm, acting on your behalf, so this code almost never means you personally asked for anything. It shows up when an address turns out to be in a non-serviceable area, when a pincode is suspended, when a delivery window or SLA has expired, when the order was cancelled after dispatch, or when the parcel is held for a compliance reason at a hub.
Treat it differently from a rejection for one practical reason: nobody refused your product, so nothing about your listing needs changing, and the order timeline is evidence. If you dispatched inside your window with a correct label and the platform still turned the parcel around, that is a case worth putting in writing rather than absorbing quietly. The mechanics of building that case, and the exact fields to quote from the order timeline, are in our shipper instructed RTO guide.
One warning about this code. Because it sounds like it was your instruction, it is the code sellers are least likely to query, and support conversations sometimes proceed on that assumption. Read the order timeline before you accept the framing. Ask what the trigger was, on what date, and against which attempt, because a shipper-request return fired against an order you shipped correctly and on time is a very different conversation from one fired against a late dispatch.
The statuses after the code, and the one to watch
Once a parcel is marked, it moves through a short sequence of return statuses. They are easy to skim past because they all contain the letters RTO, but they carry different information about risk. Read them as a ladder: each rung means the parcel is one step closer to being physically in your hands, and a parcel that stops climbing is a parcel you may not get back.
- Awaited RTO means the return has been decided but has not started. The parcel is at a facility, unmoving, and this is where returns go to die.
- RTO accepted means a facility has scanned it in as a return shipment, so the reverse network has taken responsibility for it.
- RTO initiated means the reverse leg exists as a booking against the shipment. Note the date, because from here a stall becomes measurable.
- Dispatched for RTO means it has physically left on the return journey.
- RTO in transit means it is moving hub to hub. Repeated identical scans here mean a stall, not progress.
- RTO delivered means the courier says it was handed back to you.
The two rungs worth real attention are the first and the last. Awaited RTO is where the reverse network holds parcels that nobody is chasing, and a parcel that sits there long enough tends to come back damaged, short, or not at all. The moment you see a stale awaited-RTO scan, put the AWB in a ticket with the date of the last movement, because a written record started early is the difference between a claimable loss and an unprovable one. Our guides on RTO initiated and RTO in transit go through the normal timings so you can tell a slow lane from a genuine stall.
RTO delivered deserves suspicion for the opposite reason: it is a status that closes the loop in the courier’s records whether or not anything reached your shelf. Check every RTO delivered scan against your own inward register on the day it lands. A parcel recorded as returned to you but never received is two losses at once, the unit and any charge riding on the shipment, and the only way to contest it is a same-day discrepancy with the timestamp and your receipt log side by side.
What an order_reject actually costs you
The visible loss is the sale, and that is the smallest part. The forward shipping leg has already been flown, driven and paid for. The packaging is used. The unit has travelled a round trip it will show the wear of, and in soft categories a garment that has been through two hubs and a failed doorstep often cannot go back out at full price. On top of that sits the opportunity cost of the stock, which was unavailable to a buyer who would have kept it for however many days the round trip took.
On charges, the distinction between a pure RTO and a customer return is the one that decides your settlement. A pure RTO, where delivery never happened, typically does not attract an additional reverse-shipping fee to the seller in most categories. A customer return after delivery is charged a return-shipping fee based on the weight of the shipment. Same parcel arriving back at your door, very different lines on your statement. So when a reverse-shipping charge appears against an order whose tracking clearly says order_reject and never says delivered, that is a line worth a same-day ticket with a screenshot of the settlement row and the tracking history attached. The full anatomy of what Meesho bills and what varies by weight and lane is in Meesho RTO charges.
Then there is the slower cost. A rising rate of turnarounds affects how the marketplace treats your catalogue, because a listing that generates refusals is a listing that costs the platform money too. Nobody publishes a formula for this and you should be suspicious of anyone who quotes you one, but the direction is not in dispute: consistently high RTO rates are bad for reach, and reach is the thing you cannot buy back cheaply. The broader picture of how returns and turnarounds sit inside Meesho operations is covered in RTO in Meesho.
Match the symptom to the next action
These are the six situations that actually cost sellers money after a parcel turns around. Each one has a same-day action, and same-day is the part that matters.
The parcel is almost certainly in awaited RTO at a facility. Note the date of the last scan and raise a ticket referencing the AWB once it has been static for longer than the usual reverse transit time on that lane. The important thing is to start the clock in writing, because a parcel that never comes back becomes a lost-in-return claim and those claims have windows.
Treat the scan as a claim, not as a fact. Check your own inward record for that AWB first, then raise the discrepancy the same day with the RTO delivered timestamp and your gate or inward register. A parcel marked delivered to you that you never received is both a lost unit and a charge you should not be carrying.
Search the shipment ID across settlement periods before you conclude anything, because duplicates split across two cycles look invisible in totals. A pure RTO and a customer return are different events with different charges, so seeing both against one shipment is worth querying with the tracking history attached.
Photograph it before anything else, the unopened box first, then the contents, with the AWB label readable in the frame. A damaged-in-return parcel is a claimable loss, but only with evidence captured at the moment of receipt. Once the unit is back in your bin and the packaging has gone out with the rubbish, the claim is gone.
That is a signal, not bad luck. A repeat pincode points at address quality or a local courier problem, and a repeat SKU points at the listing: photos, size chart or description setting an expectation the product does not meet. Pull the last thirty rejections, group them, and fix the top group rather than treating each one as an incident.
The forward leg genuinely happened, so a forward shipping cost against a dispatched order is usually correct even when the buyer refused it. What is worth checking is the weight the charge was computed on and whether the same shipment appears twice. Verify before you dispute, then dispute with your recorded dispatch weight attached.
Can a marked RTO be stopped?
Almost never, and it is worth being blunt about it because sellers lose hours here. Once the reason code is stamped and the return leg is booked, the parcel is inside the courier’s reverse process. There is no button in the Supplier Panel that cancels a return, and asking the rider to try again on a parcel already marked order_reject is not a workflow that exists. The narrow theoretical window is before the reverse leg actually starts, which is to say during awaited RTO, and even then it requires the courier or the platform to intervene on the shipment rather than anything you can do yourself.
In the rare cases where it does work, the pattern is the same: a live conversation the same day, on a parcel that has not yet been scanned into the reverse network, with a buyer who has separately confirmed they want it after all. That is three conditions lining up, which is why it is not a plan. The productive version of this instinct is to move earlier in the timeline. A failed-attempt or unavailability scan is a real intervention window, because the parcel is still on the forward leg and a corrected phone number or a landmark can genuinely save it. Once the code says rejected, spend your energy on receiving the parcel cleanly and checking the charge instead.
The one thing you should always do at this point is prepare the inward. Know the AWB, know the SKU, and be ready to photograph the parcel before it is opened if there is any chance of a shortage or damage claim. The value of an RTO is whatever you can put back on the shelf, and that value is decided in the first two minutes of receiving it, not in a ticket three weeks later.
Cutting order_reject at the source
Three levers move the number, in this order of effect. The first is payment mode. A buyer who has already paid has spent their decision, and prepaid orders are refused at the door far less often than cash orders, for reasons that need no explanation. Anything that shifts your mix toward prepaid is the single biggest change available to you, and the practical tactics for doing it without hurting conversion are in prepaid conversion tactics.
The second is address quality. A surprising share of what gets recorded as a refusal starts as an address the rider could not resolve, a phone that never connected, or a delivery point that needed a landmark nobody supplied. You cannot rewrite a buyer’s address, but you can catch the obviously broken ones at packing time and you can act on the pincodes that keep coming back. The checks that are worth running before a parcel leaves your table are in address quality and RTO.
The third is expectation. A door refusal is usually a buyer discovering that the thing in the box is not the thing they pictured. Photographs that show the real fabric and the real colour in daylight, a size chart with measurements rather than adjectives, and a description that admits what the product is not, all convert slightly fewer shoppers and keep far more of the ones they convert. Under-promising is the cheapest RTO reduction programme in existence, and it costs a single afternoon per listing.
Do them in order, one at a time, and measure over full weeks rather than days. Turnaround rates are noisy enough that a three-day read will tell you whatever you want to hear. Group your rejections by SKU, pincode and payment mode every month, attack the largest group, and let the next month tell you whether it worked. That loop, run four or five times, is what separates sellers with a manageable RTO rate from sellers who treat every turnaround as an unlucky surprise.
Sources & further reading
Reason-code wording differs between courier partners and changes over time, so treat the phrasing above as the common forms rather than a fixed list. Confirm any charge against your own settlement and the official documentation:
Read the code once, check the money every time
Reading one reason code takes thirty seconds. Reading four hundred of them, matching each to its settlement line, and noticing the three that were billed as customer returns when the tracking says the parcel was never delivered, is the part nobody does by hand. Robnu is the agentic OMS for Meesho, AJIO and Amazon sellers: it runs the daily order operations, sync, processing, returns and claims, and reconciles every settlement so a wrong deduction gets found while it is still claimable.
It does not carry your parcels and it does not choose your courier. What it does is make sure the money side of every turnaround is correct. Free for every seller right now, and forever free under 25 orders a day when paid pricing launches. See the whole picture on Robnu for Meesho or the order management system overview.
RTO reason codes, answered
It means the courier has flagged your shipment for return to origin because the order was rejected at the delivery point. In practice the buyer refused the parcel at the door, would not pay a COD amount, or cancelled while it was out for delivery. Delivery never happened, so this is a pure RTO rather than a customer return, and the parcel is now on its way back to your pickup address.
The immediate act is the buyer's, they said no at the door. The pattern, though, is usually something you can influence: a price the buyer regretted after a cheaper option appeared, photos or a description that did not match the product, a long delivery time that cooled the impulse, or a COD order placed casually. A single order_reject is noise. A steady stream of them is a listing or a payment-mode problem.
It means the return leg was started at the shipper's instruction rather than by the buyer, where the shipper is whoever handed the parcel to the courier. On a marketplace order that is usually the platform or its logistics arm acting on your behalf, for example when an address is undeliverable, a pincode is suspended, an SLA has expired, or the order was cancelled after dispatch. It is not a buyer refusal, which is why it deserves a different response from you.
Awaited RTO means the parcel is sitting at a courier facility waiting for the return leg to actually begin. The decision to send it back has been taken but nothing is moving yet. It is the most common place for a return to stall for days, so it is the status worth watching, because a parcel that sits in awaited RTO for a long stretch is the one most likely to be lost or damaged before it reaches you.
RTO accepted means the return has been acknowledged and taken into the reverse network, typically after a facility has scanned the parcel in as a return shipment. Read it as the handshake between the decision to send the parcel back and the courier actually carrying it back. It is a good sign for you, because an accepted RTO has a tracked reverse journey rather than an unscanned parcel in a corner.
Dispatched for RTO means the parcel has physically left the facility on the return leg and is travelling toward your pickup address. From here it behaves like a normal shipment in reverse, moving hub to hub until it is handed to you. The next status you should expect is RTO in transit and then RTO delivered, with a receipt scan at your end.
Usually no. Once the reason code is stamped and the reverse leg is booked, the parcel is inside the courier's return process and there is no seller-side button that cancels it. The narrow window is before the return actually starts, sometimes during awaited RTO, and even then it needs a courier or platform intervention rather than an action in your panel. Plan on the parcel coming back and focus on receiving it correctly.
Generally not, because a pure RTO where delivery never happened typically does not attract a separate reverse-shipping fee to the seller in most categories, unlike a customer return after delivery. If a reverse-shipping line does appear against a never-delivered order_reject, that is exactly the kind of charge worth a same-day ticket with the settlement line and the tracking history attached.
Related seller guides
More on the operations, money and claims that decide whether a marketplace catalogue actually makes money.
ROD Meaning: What Return on Delivery Means for Sellers (2026)
ROD usually means Return on Delivery, a parcel refused or returned at the doorstep. Here is what the ROD status means, when it appears, how it differs from RTO, and exactly what each one costs a marketplace seller.
RTO Marked Meaning: RTO Accepted, Shipper Request Decoded (2026)
RTO marked means your parcel has been flagged to return to origin. Here is what RTO marked, RTO accepted, RTO (shipper request) and RTO marked in Savana each mean in your courier or panel, and what to do next.
RTO OFD meaning: out for delivery, then back to you
"RTO OFD" means your returned parcel is out for delivery back to your own pickup address. What the status means, the timeline to expect, and what to watch so you are not charged for a parcel that never arrives.
“RTO Initiated” meaning: what just happened to your order
Delivery failed and your parcel is heading back. What triggered it, what the double freight hit costs, and which part of the bill you can claim back.
RTO Full Form in Delivery, Courier, Flipkart, Meesho, Zepto and Logistics
RTO full form is Return to Origin: the parcel returns to the seller when delivery fails. Meaning in delivery, courier, Flipkart, Meesho, Zepto and logistics.
RTO Means Cancellation Before Delivery: True or False? (2026)
False. RTO does not mean a cancellation before delivery, it is a failed delivery returned to the seller. Here is the clean difference between RTO and a pre-dispatch cancellation, and why confusing them costs money.
“RTO In Transit” meaning: where your parcel is and what it costs
The reverse leg is slower than the forward one, and parcels get lost on it. Timelines, the charge accruing behind the scan, and when to treat it as lost in transit.
RTO in ecommerce: full form, meaning & true cost
RTO full form is Return to Origin. What it means in logistics and ecommerce, how it differs from a customer return, and the real cost stack for an Indian marketplace seller.