How to reduce RTO on Amazon and Flipkart: a seller checklist

RTO is not the same as a normal customer return. It happens before a successful delivery: the customer refuses the parcel, cannot be reached, the address cannot be served, or delivery otherwise fails and the shipment returns to origin. Flipkart's Returns API documentation separates customer returns from courier returns and exposes the recorded reason, while an Amazon representative describes a refused delivery as a “Doorstep Reject” that becomes RTO in Amazon Seller Forums.

The useful goal is not an internet benchmark. It is a lower, profitable RTO rate for your own category, fulfilment model and order mix without cancelling valid orders.

Calculate your RTO rate and cost from your own data

Choose a resolved dispatch cohort

Use a dispatch-date cohort whose delivery and return outcomes have had time to resolve. A return recorded this month may belong to a shipment sent last month; dividing this month's returns by this month's new orders mixes two groups. Keep unresolved shipments visible and label any provisional rate rather than treating them as delivered.

RTO rate = RTO shipments in the cohort ÷ dispatched shipments in the same cohort × 100

Exclude cancellations that never shipped. Use shipment counts consistently when one order creates multiple parcels. Keep customer returns after delivery out of the RTO numerator: Flipkart's Returns API distinguishes customer_return and courier_return, and supports return and tracking identifiers. Confirm what each status means in your own export.

Split COD and prepaid, then marketplace, fulfilment model, courier, pin code, SKU and recorded reason. A COD-only RTO percentage must use COD dispatches, not all orders, as its denominator.

Build a retained-cost worksheet

Record the following for each RTO shipment, with links or references to the supporting invoice, settlement and inventory record:

• forward freight retained after confirmed credits;
• return freight retained after confirmed credits;
• consumed packaging and handling;
• other fees still retained after reversal or reimbursement;
• net inventory write-off after recovery or salvage.

Add each cost once. If repacking labour is already in handling, do not repeat it under write-off. Use one tax basis throughout, consistent with your accounting treatment; do not add tax again to a tax-inclusive invoice input. Keep unconfirmed reimbursements and unresolved fees in a separate provisional column rather than assuming either recovery or loss is final.

Shiprocket's RTO charge guidance describes courier return charges; its shipping-zone guidance explains that forward and RTO freight depend on route zones. These describe that provider's system, not a universal Amazon or Flipkart charge. Match your current programme terms to the actual transaction before deciding which costs remain.

Average retained cost per RTO = total retained cohort costs ÷ cohort RTO shipments

Estimated cohort RTO cost = cohort dispatches × RTO rate ÷ 100 × average retained cost per RTO

For an observed cohort, summing the individual shipment costs is preferable to multiplying rounded averages. When there are no RTO shipments, the observed RTO cost is zero and a cost-per-RTO average is not meaningful.

Separate write-off, blocked inventory and missed revenue

A returned product that can be resold is not automatically a full product-cost write-off. Record its condition and inventory outcome. Use unrecoverable cost for unsellable stock, net of documented recovery; track time out of stock and any evidenced carrying cost separately.

Do not multiply all returned stock by selling price and add that value to freight as a realised loss. Missed sales revenue, recoverable inventory value and retained costs answer different questions. A broader contribution analysis may include advertising and financing, but those must be explicitly defined rather than silently added to this worksheet.

Illustrative calculation, not a benchmark

Suppose a resolved cohort contains 500 dispatches and 100 RTO shipments: the RTO rate is 20%. Average retained costs per RTO are ₹60 forward freight, ₹40 return freight, ₹10 packaging and zero other fees or write-offs. The result is 100 × ₹110 = ₹11,000 for the selected period.

If return freight is fully waived or reimbursed, enter zero for that line; the same scenario becomes ₹7,000. If inspection instead establishes ₹2,000 of net inventory write-off across those 100 RTO shipments, enter ₹20 average write-off per RTO, not ₹2,000 per shipment. With the original freight inputs, the total then becomes ₹13,000.

Use the RTO Loss Calculator to run the same model. Its starting values are illustrative, not industry averages. It excludes missed revenue, resellable stock value, advertising, financing and fixed overhead; its result is neither total business loss nor guaranteed savings from an intervention.

Build an RTO reason table before changing policy

Create one row per shipment with the order ID, payment mode, marketplace, courier, destination pin code, SKU, dispatch date, promised delivery date, first-attempt date, final status and recorded reason. Keep the marketplace or courier's original reason text, then map it into a small working set:

• customer refused;
• customer unreachable or unavailable;
• incomplete or invalid address;
• delivery attempt or serviceability issue;
• delayed delivery;
• reason unclear or missing.

The working labels help analysis; they do not replace the platform's official status. Preserve screenshots, tracking events and case IDs for any dispute.

Reduce preventable RTO before dispatch

Verify the orders that carry more risk

Blanket calls on every order add delay and cost. Start with segments that your own history shows have higher RTO: for example, a repeated customer-contact problem, an incomplete address, a specific SKU, or a courier and pin-code combination with enough orders to judge.

Where your fulfilment model and marketplace rules permit seller contact, ask the customer to confirm the product, amount, address landmark and intention to accept the parcel. Do not move marketplace customers to an external channel, request off-platform payment or override platform-controlled delivery details. Amazon's seller-forum guidance recommends confirming COD orders and verifying delivery address and contact details before dispatch. Shiprocket's RTO support guidance similarly describes order confirmation, address verification and targeted action on higher-risk orders.

Do not treat non-response as fraud. Define a documented follow-up and cancellation rule that fits the marketplace's policies and your dispatch deadline.

Validate address details

Check whether the pin code, city and state agree; whether the house or building detail is usable; and whether the phone number has the expected length and format. Ask the buyer to correct missing information before handover where the platform permits it.

Carrier tools can add a risk signal, but they should not become an unexplained automatic rejection rule. Delhivery's RTO Predictor documentation says its score uses inputs such as address, phone number, product, shipment value and payment method, then allows confirmation or payment-mode actions on higher-risk COD orders. Treat a score as one input and measure false positives.

Set accurate delivery expectations

Make the product title, images, size, quantity, compatibility and included items unambiguous. A buyer who receives what the listing promised has less reason to refuse at the door. Amazon's RTO guidance explicitly includes accurate listings among its recommended actions.

Share the expected delivery window and tracking updates through channels the customer agreed to receive. Avoid promising a faster delivery date than the carrier or marketplace shows.

Act on non-delivery reports while delivery is still recoverable

Review the NDR or failed-attempt records available in your fulfilment model daily. A D2C carrier dashboard does not imply the same controls are available for marketplace-managed deliveries. Confirm the reason with the customer, correct permitted address details, and request a re-attempt when the customer still wants the order. Shiprocket's support documentation describes NDR workflows that allow sellers to contact the customer, request re-attempts or report a disputed attempt.

Track these outcomes separately:

• delivered after intervention;
• returned despite intervention;
• returned with no intervention possible;
• cancelled before dispatch after verification.

This distinguishes a useful process from activity that merely creates more calls and messages.

Choose couriers and COD rules from sufficient evidence

Compare RTO within the same pin code, payment mode and similar product group. A courier's account-wide average can be misleading if its route mix differs. Set a minimum order count before changing a courier or blocking COD for a pin code, and review the decision regularly.

Use a controlled test where possible. For example, apply confirmation to one defined higher-risk segment for four weeks while leaving a comparable segment unchanged. Track dispatch rate, delivery rate, RTO rate, cancellation rate, cost per delivered order and customer complaints. This is an illustrative test design, not a promised result.

Audit returned parcels and settlement entries

When an RTO parcel comes back, record the date, condition, seal or packaging state and inventory outcome. Match the return ID or tracking ID to the settlement entry. Flipkart's returns documentation exposes return and tracking identifiers plus the return reason; those are the starting points for a reproducible audit.

If the physical return, scan history or charge does not match the record, preserve the evidence before opening a case. Amazon's guidance advises including specific order IDs when reporting suspected delivery or scan issues. Describe the documented mismatch rather than claiming courier fault before the case is reviewed.

A weekly RTO control routine

1. Export dispatched, delivered and RTO shipments.
2. Recalculate COD and prepaid RTO rates using the same denominator.
3. Rank reasons, couriers, pin codes and SKUs by both count and cost.
4. Review new NDRs and open evidence-backed cases.
5. Apply one defined intervention to one defensible segment.
6. Record cancellations and false positives as well as avoided returns.
7. Reconcile returned parcels and settlement entries.

Check whether the intervention pays for itself

Compare retained cost per dispatched shipment and per delivered shipment across comparable, resolved cohorts. Add the intervention's actual verification costs, discounts and extra handling before calling the difference a saving. Track valid orders cancelled after verification and customer complaints too: a lower RTO rate achieved by cancelling good orders is not automatically an improvement.

The process should produce an audit trail: what changed, which orders were affected, and whether delivery economics improved. It should not rely on an unsupported industry percentage or a guarantee that one tactic will work for every seller.

Source review and operating limits

Sources were rechecked on 16 October 2026. Flipkart's API page shows no publication date; the Amazon moderator reply displays “7 months ago” without an exact date. Shiprocket's charge article was modified on 6 February 2019, its zone article on 13 December 2022 and its RTO-controls article on 14 July 2024. Delhivery's predictor documentation was published on 15 January 2024 and updated on 3 April 2025.

These sources support status definitions and available workflows, not a current universal fee, RTO benchmark or guaranteed result. Confirm the terms and permissions for the account and fulfilment model being reviewed. The worksheet and examples above are our operational calculation framework, not a marketplace accounting standard.