Meesho Settlement & Payment Statement Explained
Meesho pays suppliers in bank transfers that bundle hundreds of sub orders, and the payment statement is the only document that explains what each transfer contains. Read it correctly and your books reconcile to the rupee; skim it and you will book net receipts as sales, lose your tax credits, and never know what selling on Meesho actually costs you. Here is the statement decoded, field by field.
The anatomy of a statement row
Each row describes the settlement of one Sub Order No, Meesho's unit of fulfilment. The key fields:
| Field | What it means | Accounting significance |
|---|---|---|
| Sub Order No | Unique sub order identifier | Links settlement to the sale in the GST report; duplicate-detection key |
| Payment Date | Date of the bank transfer | Receipt voucher date |
| UTR | Bank transfer reference | The join key to your bank statement |
| Final Settlement Amount | Net amount paid for this sub order | The only figure that reaches your bank |
| Meesho Commission (incl. GST) | Meesho's fee, stated inclusive of GST | Needs splitting: base to expense, GST to input credit |
| GST on Commission | The GST portion of the fee | Input tax credit candidate (confirm with your CA) |
| TCS | GST collected at source u/s 52 (0.5%) | Asset: TCS Receivable |
| TDS | Income-tax deduction u/s 194-O (0.1%) | Asset: TDS Receivable |
The equation every row must satisfy
Conceptually: sale value minus commission (with its GST) minus TCS minus TDS, adjusted for any return or RTO recovery, gives Final Settlement Amount. When you sum Final Settlement Amount across all rows sharing a UTR, that total must equal one credit on your bank statement. This is the reconciliation identity that everything else hangs off. Negative rows appear when a previously settled sub order is returned or RTO'd and Meesho recovers money in a later cycle; they reduce the UTR total and are the single most common reason a supplier's reconciliation "doesn't tie".
The commission-GST split trap
Because Meesho states commission inclusive of GST and also provides the GST on Commission figure separately, the correct posting is: commission net of GST to the expense ledger, GST portion to an input credit ledger. Suppliers who post the inclusive figure as expense overstate costs and silently forfeit input credit month after month. The claimability of that credit depends on your registration; it is a question worth five minutes with your CA, because the answer compounds across every order you ever ship. The full posting pattern sits in our Meesho commission accounting guide.
From statement to Tally vouchers
Per UTR group, the balanced entry set looks like: debit bank for the UTR total, debit Meesho Commission (net), debit Input GST on Commission, debit TCS Receivable and TDS Receivable, credit the Meesho party ledger for the gross value being settled. Combined with sales vouchers posted at Total Invoice Value from the GST sales report, the party ledger nets down to only unsettled sub orders. Where a row is negative, the same logic runs in reverse against the return or RTO credit note.
Doing this at Meesho volume
A statement with three thousand rows across four UTRs is not a manual job. TallySutra reads the payment statement you export from the supplier panel, file upload only, since Meesho offers no public seller API, performs the UTR grouping and the commission-GST split automatically, routes TCS and TDS to receivable ledgers, and generates the whole voucher set as Tally XML with duplicate-safe re-import by Sub Order No. Rows that break the settlement equation are quarantined in an exception queue for your CA to review rather than imported wrong; the features page shows that pipeline end to end. Whether you automate or not, the standard is identical: every UTR on your bank statement should decompose, sub order by sub order, into sales you can point to in the GST report. That is what "reconciled" means, and this statement is the document that makes it possible.
Keep every statement you ever download. The panel shows a window of data, but disputes, GST queries and year-end audits reach back further than any panel view, and the archived files are your evidence. A dated folder of unedited exports, one per settlement cycle or month, costs nothing to maintain and settles arguments instantly. Pair it with the reconciliation working described above and you can reconstruct any payout, sub order by sub order, years after the fact, which is precisely what an assessing officer or a lender will one day ask you to do.
Frequently asked questions
Why is my bank credit smaller than my Meesho sales for the period?
Because the bank receives only Final Settlement Amount: sale value minus Meesho commission including its GST, minus 0.5% TCS, minus 0.1% TDS, and minus recoveries for returned or RTO'd sub orders settled in that cycle. Sales belong in your books at invoice value from the GST sales report; the deductions each get their own ledger entry rather than vanishing into a netted figure.
What is a UTR and why does it matter for reconciliation?
The UTR is the unique reference of the bank transfer that paid a batch of sub orders. Rows sharing a UTR in the payment statement should sum exactly to one credit on your bank statement. Grouping by UTR is therefore the mechanical basis of Meesho payout reconciliation: it turns thousands of sub order rows into a handful of verifiable bank-level checks.
How should negative rows in the statement be booked?
A negative row is a recovery: a sub order settled earlier has been returned or RTO'd and Meesho is clawing the payment back in this cycle. Book the underlying event, a credit note for a customer return or your RTO treatment for undelivered goods, and let the recovery reduce the receipt side. Never delete or net them away; they are why UTR totals differ from gross sales.
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