Meesho RTO & Returns: Accounting Treatment in Tally
RTO, return to origin, is the tax Meesho suppliers pay for cash-on-delivery India. Orders that never reach the customer, refused at the door or undeliverable, come back to your warehouse, and on Meesho the rates can be brutal: RTO is widely acknowledged as one of the biggest cost factors in the model. Accounting for it wrongly makes a marginal business look profitable until the cash disappears. This guide separates RTO from customer returns and gives both a correct home in TallyPrime.
RTO vs Return: two different events
The Meesho GST sales report marks each sub order row with an Event Type: Sale, Return or RTO. The distinction matters because the physical and legal facts differ:
| Customer Return | RTO | |
|---|---|---|
| What happened | Delivered, then sent back by customer | Never delivered; courier returned it |
| Was there a supply? | Yes, then reversed | Delivery failed; sale is reversed |
| Document | Credit note against original invoice | Credit note / sale reversal per your CA's position |
| Stock condition risk | High (used, damaged, swapped) | Moderate (transit wear, packaging loss) |
| Settlement impact | Payment clawed back, fees partly reversed | Payment not made or recovered; logistics cost may apply |
GST treatment of RTO reversals, particularly invoice cancellation versus credit note and the timing across filing periods, has genuine nuance; agree the documentation pattern with your CA once and apply it consistently.
The entries, event by event
- Original sale: sales voucher at Total Invoice Value with rate-wise tax split, per the GST report's Sale row.
- RTO event: credit note reversing the sale value and output GST, referencing the original sub order; stock re-entry via a receipt note or stock journal so inventory reflects the goods physically back with you.
- Settlement recovery: if the sub order was settled before the RTO, the payment statement shows a negative row recovering it; this nets against the credit note through the party ledger.
- RTO cost: any courier or handling charge attributable to the failed delivery goes to a dedicated RTO Expenses ledger, never merged into general freight.
- Restocking loss: goods that come back unsellable get written down via a stock journal to a damages ledger, at cost.
Why a dedicated RTO ledger changes decisions
The point of separating RTO cost is that it is controllable. RTO percentage varies dramatically by pincode profile, product category, price point and how aggressively you accept COD orders. When your P&L shows RTO Expenses and RTO-driven write-downs as their own lines, you can compute the real contribution of each SKU: some "best-sellers" turn out to lose money once one in four shipments boomerangs. Aggregate freight ledgers hide this completely. Suppliers who track it per month typically start pruning high-RTO SKUs within a quarter, which is the entire commercial payoff of doing the accounting right.
Handling RTO at volume
The clerical problem is that every RTO is three or four entries across two reports, matched by Sub Order No. TallySutra's Meesho import automates the matching: upload the GST sales report and the payment statement from the supplier panel (file upload only; Meesho has no public seller API and TallySutra never scrapes the panel), and RTO rows are converted into the credit note and recovery entries automatically, tied to their original sales by Sub Order No. RTO rows that cannot be matched to a booked sale, or recoveries without a visible original settlement, land in the exception queue for a human call instead of being imported blind. The same matching is what makes payout reconciliation tie out in RTO-heavy months.
A monthly RTO review in four numbers
- RTO rate: RTO sub orders divided by shipped sub orders.
- RTO cost: the RTO Expenses ledger total plus write-downs.
- Top RTO SKUs: the five products driving the most RTO events.
- Recovery lag: RTO'd goods not yet physically received back.
Ten minutes on these four numbers each month, straight out of properly structured Tally data, does more for a Meesho supplier's margins than most pricing changes. RTO is not going away; unmeasured RTO is the part you can fix.
One operational tie-in completes the loop: reconcile physical RTO receipts against booked RTO events weekly rather than monthly. Goods in transit back to you are working capital in limbo, and the gap between RTO events booked and parcels actually received is where inventory quietly leaks. A simple pending-receipt list, driven from the same Sub Order Nos your credit notes already reference, keeps the warehouse and the books telling one story instead of two.
Frequently asked questions
Is an RTO treated the same as a customer return in my books?
The paperwork is similar, both reverse the sale and its output GST via a credit note referencing the original sub order, but they should be tracked separately. RTO means the goods never reached the customer, so stock re-entry is near certain and the driver is delivery failure, not product dissatisfaction. Separate ledgers and event tagging let you measure and manage the two problems independently.
How do I account for RTO goods that come back damaged?
Re-enter the stock at cost first, then pass a stock journal writing down the unsellable portion to a damages or stock-loss ledger. This keeps the inventory records honest and shows RTO's full cost: the failed delivery expense plus the value destroyed in transit. Consistent write-down practice also matters at year-end when closing stock is valued. Confirm valuation treatment with your CA.
Why does my Meesho payout drop so much in high-RTO months?
Two effects stack: RTO'd sub orders from the current period are not paid, and sub orders settled in earlier cycles that later RTO'd appear as negative recovery rows in the payment statement, reducing the UTR totals. Matching recoveries to their original sub orders, by Sub Order No, is the only way to see how much of the drop is each effect, which is exactly what reconciliation is for.
TallySutra turns Amazon, Flipkart and Meesho reports into reconciled, reviewed TallyPrime vouchers — duplicate-safe, with every rupee traceable to its source row.
Book a 30-minute demo