Your Meesho panel says the payment for a ₹499 rayon kurti set — delivered to a buyer in Indore last Wednesday — will be credited on Tuesday. Tuesday comes, the bank pings, and the credit reads ₹389. Somewhere between “delivered” and “credited,” ₹110 left the building. The Meesho payment cycle is not complicated, but it is layered — and if you only ever look at the lump-sum bank credit, you will never see which layer took what.
This post walks the full cycle to the rupee: when Meesho pays, what gets deducted before the money reaches your bank, how to read the payment advice line by line, and why the credited amount so often refuses to match the panel. Every rupee figure here is illustrative — fee structures vary by category, claim history, and policy revisions — but the mechanics are the mechanics. (Robnu is independent software built for Meesho sellers; we are not affiliated with or endorsed by Meesho.)
How the Meesho payment cycle actually works
Meesho's cycle is anchored to delivery, not dispatch. The clock starts when the courier marks the sub-order delivered, and payment is credited roughly seven days later — for COD and prepaid alike, since Meesho fronts the COD collection risk and settles you on the same schedule. The panel shows an expected payment date against each sub-order, and payouts arrive as batched bank transfers covering every sub-order that matured in that window.
The part that trips up new sellers: each sub-order matures on its own clock. An order delivered Monday and an order delivered Thursday land in different payouts even if they were dispatched in the same manifest. And three other clocks run alongside the payment clock — the return window, the exchange flow, and the claim-resolution timeline. A return raised on day 6 can claw back a payment that was due on day 7, or, more confusingly, get netted against a future cycle as an adjustment.
Practical implication: never plan cash against “Meesho pays weekly.” It doesn't — it pays continuously, sub-order by sub-order, in batched transfers. The useful mental model is a conveyor belt: every delivered sub-order gets on the belt, rides for about seven days, and drops into whichever payout happens to be leaving next. Your job is not to predict the payouts; it is to know, for every sub-order, where on the belt it is — and to notice the ones that fell off.
What leaves the payment before it reaches your bank
Meesho markets itself on low selling commission, and that is broadly true — but commission was never the whole story on any marketplace. Between the ₹499 list price and the ₹389 credit, five distinct lines take their cut. In our illustrative kurti order:
- Platform and shipping-linked fees — ₹76. The operational charges tied to getting the parcel moved and the order serviced. The exact construction varies by category and policy version; treat your own rate card as the source of truth.
- GST on those fees — ₹14. 18% tax charged on the fee line. This is not money lost — it is input credit you can claim against your GST liability, but only if it makes it into your filings.
- GST TCS — ₹2. Tax collected at source on the taxable value, deposited by Meesho against your GSTIN. Recoverable through the GST portal (as of writing the rate is 0.5% — verify current rates at gst.gov.in).
- Income-tax TDS — ₹1. Section 194-O deduction on gross sales, visible later in your Form 26AS, adjustable against your income-tax liability at filing.
- Adjustments — ₹17. The line with teeth. Here, an RTO shipping charge from a sub-order two cycles ago, netted against today's payout. Nothing to do with this kurti at all.
Reading the payment advice line by line
The payment advice (the statement behind each bank credit) is downloadable from the supplier panel, and it is worth pulling every cycle — not skimming on screen. The shape is consistent even when the label names shift between policy versions: a sale amount, a fee block, a tax block, an adjustment block, and a net payout. Figure 3 annotates each line of our illustrative order.
Two reading habits matter. First, read the tax block as reclaimable, not as cost — the GST-on-fees and TCS lines flow back to you through GST filings, and TDS offsets income tax. Sellers who mentally write these off overstate their losses; sellers who never file for them turn timing costs into real ones. Second, chase every adjustment to its source order. An adjustment line that says “RTO charge” should name a sub-order; pull that sub-order and confirm the RTO actually happened. From sellers we've sat with at 5–25 orders/day, the adjustment block is where genuine errors — double-applied return fees, reversals that never reversed — hide most often.
Why the bank credit never matches the panel
The panel's sale figures are gross; the bank credit is net — that much is obvious. The subtler reason the two diverge is cycle bleed. Any given payout is a sandwich of this cycle's matured orders, last cycle's adjustments, and occasional claim outcomes from a month ago. A payout of ₹23,412 covering 60 sub-orders tells you nothing about whether sub-order 47 was short-paid by ₹40. The only reconciliation that works is order-level: expected amount per sub-order versus settled amount per sub-order, with every difference explained or disputed. That is the discipline our payment reconciliation approach is built around, and it is the subject of its own complete guide.
Does COD slow down Meesho payments?
Short answer: no, and the reason matters for your cash planning. On Meesho, the marketplace fronts the cash-on-delivery collection — the courier collects from the buyer, but your settlement clock runs from delivery on the same roughly-seven-day cycle whether the order was COD or prepaid. The float risk sits with the platform, not with you. What COD does change is the order's probability of completing at all: doorstep rejection converts an expected payment into an RTO event, which means no payout for that sub-order plus, depending on policy, a charge that shows up later as an adjustment. So when sellers say “COD delays my money,” what is usually happening is that COD is shrinking the share of orders that ever reach the payment clock — a real cost, but a different one, with a different fix (address confirmation and listing accuracy, not payment chasing). For cash-flow modelling, treat COD and prepaid identically on timing, and treat COD's extra RTO probability as a volume haircut. Getting this distinction right stops you optimising the wrong end of the funnel.
What a clean month looks like
To make the discipline concrete, here is an illustrative month for a seller doing about 220 Meesho sub-orders. Expected payout, summed from list prices minus mapped fees: ₹81,400. Actual bank credits across nine payouts: ₹78,950. The gap — ₹2,450 — decomposes on inspection into: ₹1,610 of return and RTO adjustments that check out against real events (cost of doing business, logged); ₹540 of GST-on-fees and TCS that is reclaimable through filings (parked, not lost); ₹86 of TDS (visible in 26AS, parked); and ₹214 on two sub-orders where a return charge was applied twice. Those two became a support ticket with statement lines attached, and the ₹214 came back in the next cycle. That is the whole game: a month where every rupee of the gap has a name, a category, and — where it should — a refund. The sellers who get burned are not the ones with bigger gaps; they are the ones whose gap is a single unexamined number.
Five habits that keep the cycle honest
None of this requires software, just discipline — though discipline at 20 orders/day is exactly what software is for. The ritual: download every payment advice the day it lands, not at month-end. Match every sub-order's settled amount against its expected amount. Trace every adjustment to a named source order and verify the event happened. Tally the month's TCS and TDS lines and confirm they appear on the GST portal and in Form 26AS. And log every unexplained short-payment as a dispute candidate with the order documents attached — because the difference between “weird, whatever” and recovered money is usually nothing more than a ticket filed inside the window.
Where Robnu fits
Robnu is an agentic OMS with Meesho operations live today — it runs the daily processing, keeps every sub-order tied to its slips, manifests, and expected payout, and computes per-order profit from settled rupees rather than sticker prices. When a payment lands short, you see a flagged order with its paper trail attached, not a mystery inside a lump sum. The recoverable ones become claims; autonomous claim filing is rolling out now, with the occasional one-click human approval where a marketplace flow demands it.
Robnu is free for everyone right now — every feature, every order, no card, no trial timer — while we figure out paid pricing. When paid pricing eventually launches, sellers under 25 orders/day stay free forever, and today's users get grandfathered locked rates. If Meesho payments are currently a lump sum you squint at, that is a fixable problem.