How to read the Meesho payment report.
One row per sub order, a transacted value, a stack of deductions, then a bank settlement amount with a payment date and a UTR. Learn what each column means and the report stops being a mystery and starts being evidence.
To read the Meesho payment report, download the settlement report for a date range from the Payments section of the Supplier Panel and read each row left to right: the sub order and its dates, the transacted sale value, then every deduction and credit applied to it. The last money column is the bank settlement amount, the figure actually transferred, and it is the only one that should match your bank statement.
- One row per sub order, not per order. A two-item order is two rows.
- Start from the discounted or transacted value, never the listed price.
- Bank settlement amount is the final transfer. The UTR proves it left Meesho.
- Payment date, not order date, is the number to plan cash flow around.
- Column names change between report versions. Learn the meanings, not the headers.
How a sale value becomes a bank settlement amount
Every column between the two ends is either a cost, a tax held on your behalf, or a credit. Read them in order and the final figure stops being a surprise.
What every column in the report means
Header names differ between report versions. The meanings below have been stable for years, so match on sense rather than on an exact string.
| Column | What it is | Why it matters to you |
|---|---|---|
| Sub order number | The identifier for one item inside an order. A two-item order produces two rows. | This is the key you reconcile on. Matching at order level double counts or hides items. |
| Order date | When the buyer placed it. | Useful for ageing, useless for cash flow. It never tells you when you get paid. |
| Dispatch date | When the parcel was handed to the courier. | The date your SLA was measured against, so it is the date a penalty line points back to. |
| Product name and SKU | The listing name and your own Seller SKU ID for the variation sold. | Without a clean SKU you cannot tell which product a deduction belongs to. |
| Supplier listed price | The price you set on the listing. | A reference only. Nothing on the row is calculated from it. |
| Supplier discounted price or sale amount | What the order actually transacted at, after any discount or promotion. | Your reconciliation starts here. Every deduction is applied against this figure. |
| Commission | The marketplace fee column. On many Meesho reports it reads 0, in line with the zero commission headline. | A zero here does not mean free. Confirm your own category rate card in the panel. |
| Shipping charge | The logistics cost billed against the shipment, driven by weight slab and zone. | The most common place a wrong weight quietly costs you money on every parcel. |
| GST on shipping | The statutory tax on that logistics service. | Generally available to you as input credit, so it is a cost to record, not simply lost. |
| TCS | Tax collected at source under GST, held and deposited against your GSTIN. | Your money, claimable when you file. Only lost if your GSTIN on the panel is wrong. |
| TDS under section 194-O | Income tax deducted at source on e-commerce sales, deposited against your PAN. | Appears in your Form 26AS and is adjusted when you file. Again, yours, not a fee. |
| Compensation or claims credited | Money paid back to you for a lost, damaged or wrongly charged shipment. | Good news, and worth confirming it matches the claim you actually filed. |
| Recovery | An amount clawed back from a previous settlement, including a carried-forward negative balance. | Always ask which earlier cycle it relates to. An unexplained recovery is worth a ticket. |
| Penalty | A charge for a policy or SLA breach on a specific order. | Must map to a real event on a real order. A penalty you cannot tie to anything is disputable. |
| Ads deduction | Your promotional or ads spend recovered from the payout. | Compare it to what you authorised in the ads section. It is easy to overlook in a total. |
| Final settlement amount | The net figure for that row after every deduction and credit. | Sum these across the cycle and you have what the payout should be. |
| Payment date | The date the settlement is scheduled to reach your bank. | The only date that matters for cash flow, and the one to wait on before raising a query. |
| UTR or reference number | The banking reference for the actual transfer. | Proof the money left Meesho. With a UTR the conversation moves to your bank. |
Two habits make this table useful rather than interesting. Reconcile on the sub order number, because that is the only key that is one to one with a physical item. And start every row from the discounted or transacted value, because starting from the listed price makes every downstream figure look wrong. A full walk through each deduction type sits in Meesho payment deductions explained.
What sits between the sale and the credit
The gap is normal. The size of the gap, and whether every line in it is correct, is the part worth an hour a week.
A three step weekly routine
Download and total the cycle
Pull the settlement report for the cycle, sum the final settlement column, and compare it to the credit in your bank. A gap you cannot name is the only finding you need.
Check the outliers, not everything
Sort by deduction size and read the top twenty rows. Most wrong charges are unusually large for their product, which is exactly what sorting reveals in a minute.
File while the window is open
Claim windows are short. A wrong charge found this week is recoverable; the same charge found next quarter usually is not, however obviously wrong it looks.
The payment report is the only document that tells you what actually happened to your money. Sellers who read it find wrong charges while they are still claimable. Sellers who read only the bank credit never find them at all.
Where to download it, and which file you want
In the Supplier Panel, open the Payments section. You will usually find a settlement or payment report download with a date range picker, and the file typically arrives as a spreadsheet, XLSX in most versions. That is the file this guide is about. The same area also carries tax and GST report downloads, which sellers searching for a GST report often land on by mistake: those files summarise tax for filing and do not carry the per order deduction detail, so they cannot answer the question of why one payout was smaller than expected.
Pick the date range by settlement, not by order date. This is the detail that wastes the most time. A settlement report for the first week of a month contains rows whose orders were placed weeks earlier, because the report is organised around when Meesho paid, not around when you sold. If you pull the range by order date and then compare the total to a bank credit, the two will never agree and you will spend an afternoon chasing an error that does not exist. The mechanics of the cycle itself are in the Meesho payment cycle, and if you just want to know when the next one lands, see your next payment date.
Download it as a file rather than reading it on screen, every single cycle, and keep the files. A settlement report you can still open in six months is what makes a dispute winnable, and the panel is not an archive you should rely on. Sellers who keep a folder of twelve monthly reports can answer questions about their own business that sellers who read the screen each week simply cannot.
The structure: one row per sub order
The single most important structural fact is that the report has one row per sub order, not one row per order. A buyer who orders two different items in one transaction produces two rows, each with its own dates, its own deductions and its own settlement amount. If you reconcile at order level you will either double count the shared parts or miss items entirely, and you will never work out which. Reconcile on the sub order number and everything downstream becomes tractable.
After the identifiers come the dates, and they do different jobs. Order date is for ageing and for nothing else. Dispatch date is the one an SLA was measured against, which makes it the date any penalty line points back to, so it is the first thing to check when a penalty appears you did not expect. Payment date is the only date that touches your bank account. Confusing the three is the reason so many sellers believe payments are unpredictable when they are merely delayed by a known interval.
Then come the money columns, and they read as a simple arithmetic: a transacted value, minus costs, minus tax held, plus credits, equals a final settlement amount. Everything in between is detail. Once you see the row that way, the report stops looking like forty columns of noise and starts looking like a receipt you can audit.
What is the bank settlement amount in Meesho?
The bank settlement amount is the money Meesho actually transfers to your registered bank account for that settlement, after every deduction and credit on the row has been applied to the transacted sale value. It is the last money column in the report, it carries a payment date, and once the transfer executes it carries a UTR reference too. It is the only figure in the whole file that should appear, rupee for rupee, in your bank statement. Everything to the left of it is the explanation.
Sellers search for this column by name more than almost any other, and usually for one of two reasons: the number is smaller than they expected, or it has not arrived. The first is almost always explained by the columns to its left, and the second almost always by the payment date beside it. Both are answerable from the report itself in under a minute, which is why learning this one column pays for the time spent on the rest.
A worked row, from sale price to bank credit
Take one delivered sub order: a kurta listed at a higher price, transacted after a discount, shipped at a normal weight, on an account running a small ads budget. Read it top to bottom the way the report reads left to right.
| Line | Amount | Running total |
|---|---|---|
| Supplier listed price | ₹699.00 | reference only |
| Supplier discounted price, the transacted value | ₹549.00 | ₹549.00 |
| Commission | ₹0.00 | ₹549.00 |
| Shipping charge | less ₹72.00 | ₹477.00 |
| GST on shipping | less ₹12.96 | ₹464.04 |
| Ads deduction | less ₹18.00 | ₹446.04 |
| TCS held | less ₹2.75 | ₹443.29 |
| TDS held under 194-O | less ₹0.55 | ₹442.74 |
| Final settlement amount | ₹442.74 | this is the bank credit |
The amounts above are illustrative and the tax figures depend on statutory rates that change, so confirm the current ones on the official portals rather than copying these. What is not illustrative is the shape. Note that ₹3.30 of that row is not a cost at all, it is tax held against your GSTIN and PAN and claimable when you file, which means the true cost of the sale is about ₹103, not ₹106. Sellers who treat tax withholding as a fee understate their own margin and never reclaim it. If you want to run your own numbers, the settlement calculator does this arithmetic for you, and Meesho TCS and TDS refund covers the reclaim.
Six reasons a settled payment is not in your bank
Work down the list in order. Five of the six are answered by the report itself, before you raise anything with anyone.
Then nothing is wrong and nothing is missing. A generated settlement is a promise with a date on it, not a transfer. Read the payment date column for that block of rows and plan around it. If the date has passed and there is still no UTR, that is the point at which it becomes a query rather than a wait.
A UTR means the money left Meesho and entered the banking system, so the question moves to your bank. Give it a working day, then take the UTR to your bank and ask them to trace it. A UTR is the single most useful thing you can hold in this conversation, because it turns a vague complaint into a traceable transaction.
A pending bank verification holds payouts even when settlements keep generating, and that is the most common cause of a stalled first payment. Check the bank section of the panel for a verification state rather than assuming the details are live because you typed them in.
A return lands in a later cycle than the sale it reverses, so a cycle heavy with returns can settle far below what the orders in it suggest. Sort the report by the return and RTO columns before you conclude the payout is wrong. The money is not missing, it has been given back.
If deductions in an earlier cycle exceeded the sales in it, the shortfall carries forward and is recovered from the next payout. A settlement that arrives at or near zero with sales on the report is usually this. It resolves itself as sales cover the gap, but it is worth understanding rather than treating as a fault.
Payment dates land on calendar days and banks do not. A credit due on a holiday commonly appears on the next working day, sometimes the one after. Wait one working day past the payment date before raising anything, and note which dates were holidays so the pattern does not surprise you next month.
Payment done but not showing: what to check, in order
This is the most searched payment problem on Meesho and it is almost never a missing payment. Start with the two columns at the right of the row. If the payment date has not arrived, there is nothing to chase: a generated settlement is a dated promise, not a transfer. If the date has passed and there is a UTR, the money has left Meesho and entered the banking system, so the conversation belongs with your bank, and the UTR is what makes that conversation short. Only when the date has passed and there is no UTR do you have a platform question.
At that point the usual causes are bank verification, returns and a negative balance. An unverified or recently changed bank account holds payouts while settlements keep generating, which is why a first payment so often appears stuck; check the bank section of the panel for a verification state rather than assuming the details are live, and see bank verification pending if that is what you find. Returns are the second: a return reverses a credit in a later cycle than the sale, so a return-heavy cycle can settle far below what its orders suggest, and sorting the report by the return columns shows it immediately.
The third is a carried-forward shortfall. If the deductions in a cycle exceeded its sales, the difference is recovered from the next payout, which can arrive at or near zero with a perfectly healthy sales list attached. That is a negative balance, not a fault, and it clears as sales cover the gap. If none of these explain it, our payment not received guide has the escalation path and what to attach to a ticket.
Seller payment time, and why the wait is rarely the problem
Meesho settles on a defined cycle rather than per order, so an order delivered today is paid in a future cycle. That interval is knowable, it is printed on your own report as a payment date, and it is the same for everyone in your situation. The reason sellers experience payments as unpredictable is almost never the interval itself. It is that they measure from the wrong event: from the day the buyer ordered, or the day they dispatched, rather than from the settlement the order fell into.
Fix that and your cash flow becomes plannable. Take three months of reports, list the payment dates, and you will see a rhythm you can budget against, including the way a weekend or a holiday nudges a credit to the next working day. What genuinely varies is not the timing but the amount, because returns from earlier cycles, ads spend and recoveries all land against whatever cycle they fall in. So plan the date from the calendar and plan the amount from the report, never the other way round.
One consequence worth internalising: a cycle can be smaller than its sales without anything being wrong. Returns reverse credits from weeks ago, and they arrive without regard for how good this week was. A seller who expects payouts to track weekly sales will read normal accounting as a fault every month, and will eventually stop reading the report at all, which is the outcome that actually costs money.
The GST report is not the payment report
Sellers searching for a GST report download often land in the same part of the panel and leave with the wrong file. The tax and GST reports summarise your taxable supplies and the tax collected for filing purposes. They are the right files to hand your accountant and the wrong files for asking why a payout was short, because they carry no per order deduction detail. The settlement report is the operational document; the GST report is the compliance document.
Download both, for different reasons and on different cadences. The settlement report weekly, to catch wrong charges while they are claimable. The tax reports at filing time, reconciled against the TCS statement on the GST portal and the TDS entries in your Form 26AS, so the tax held from your payouts is actually claimed rather than quietly abandoned. Those two habits together are the difference between knowing your margin and guessing it.
Reconciling the report against your bank statement, weekly
Weekly is the right cadence, and the reason is not diligence, it is deadlines. Claim windows for wrong charges are short and defined, so an error found in the same week is recoverable while the identical error found next quarter is simply a donation. The routine itself is short: download the settlement report for the cycle, sum the final settlement column, and compare that total to the credit that landed. If they agree to the rupee, you are finished in five minutes.
When they do not agree, resist the instinct to audit every row. Sort by deduction size instead and read the top twenty. Wrong charges are almost always anomalous for their product: a shipping charge far above what that weight should cost, a penalty on an order you dispatched early, a recovery with no cycle named, an ads deduction larger than the budget you set. Sorting surfaces all four in a minute, and it is a far better use of your attention than reading four hundred correct rows to find three wrong ones. The full method, including what to keep as evidence, is in the payment reconciliation guide.
Keep one more record while you are there: your own dispatch weight per parcel. Almost every recoverable shipping overcharge is a weight dispute, and a weight dispute without your own recorded weight is an opinion. A weighing scale by the packing table and a column in a spreadsheet is the entire investment, and it turns the single most common wrong charge on Meesho from unarguable into documented.
Which lines are recoverable, and which are not
Not everything in the gap is worth a ticket, and knowing the difference saves you from spending goodwill on charges that will stand. Commission, where it applies, follows a rate card and is not negotiable per order. Shipping on a delivered parcel at the correct weight and zone is a real service you consumed. Tax withheld is statutory and belongs at the tax department, not in a dispute.
What is recoverable is anything computed on the wrong input or applied twice. A shipping or return charge calculated on an inflated weight. The same shipment charged in two settlement periods, which is effectively invisible unless you search the shipment ID across cycles. A reverse charge on a parcel that never came back to you. A penalty against an order you can show was dispatched inside its window. A recovery with no identifiable origin. An ads deduction above your authorised spend. The penalty types and what each one needs as evidence are listed in Meesho penalty charges.
Sources & further reading
Column names and report versions change, and tax rates are set by statute rather than by Meesho. Confirm both against the official sources before you rely on a figure:
Read one row yourself, let software read four hundred
Reading a single settlement row is a five minute skill worth having, because it is how you know what to look for. Reading every row of every cycle, matching each deduction to its shipment, and catching the duplicate that split across two settlement periods, is the part nobody finishes 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 charge surfaces while the claim window is still open.
It does not file your GST return and it does not move your money. It makes sure the number that arrives is the number you earned. Free for every seller right now, and forever free under 25 orders a day when paid pricing launches. See it on Robnu for Meesho or read the order management system overview.
The payment report, answered
The bank settlement amount is the final figure Meesho actually transfers to your registered bank account for that settlement, after every deduction on the row has been applied to the sale value. It is the last money column in the payment report and the only one that should match your bank statement. Everything to the left of it explains how the sale value became that number.
In the Supplier Panel, open the Payments section and look for the settlement or payment report download for a date range. It typically comes as a spreadsheet, usually XLSX, with one row per sub order. The panel also carries tax and GST report downloads in the same area, which are separate files with a different purpose, so make sure you have taken the settlement report rather than a tax summary.
Meesho has long built its supplier proposition around a zero commission headline, so on many payment reports that column simply reads 0. It does not mean selling costs nothing. Shipping, return and RTO charges, penalties, ads spend and tax withholding all still appear on the row, and category-based fees can apply, so confirm your own rate card in the panel rather than assuming either way.
Work through five causes in order: the settlement was generated but the payment date has not arrived yet, your bank details are unverified or stale, returns in that cycle reversed an earlier credit, a negative balance is being recovered from this payout, or a bank holiday moved the credit by a day or two. Check the payment date and the UTR reference on the report first, because a UTR means the money left Meesho.
Meesho settles on a defined cycle rather than per order, so money from an order delivered today lands in a future cycle rather than immediately. The payment report carries the payment date attached to each settlement, and that date, not the order date or the dispatch date, is the one to plan cash flow around.
Supplier listed price is the price you set on the listing. Supplier discounted price, sometimes labelled as the sale amount or the final sale value, is what the order actually transacted at after any discount or promotion applied. Deductions and tax are calculated against the transacted value, not the listed one, so the discounted price is the number your reconciliation should start from.
No. They are prepaid tax held from your payout and deposited against your GSTIN and PAN. TCS shows up in your GST portal statement and is claimed against your GST liability, while TDS under section 194-O appears in your Form 26AS and is adjusted when you file income tax. They only become a real loss if your GSTIN or PAN on the panel is wrong, because then the credit sits against the wrong account.
Yes, and that is the main reason to learn the meanings rather than memorise the headers. Report versions get renamed columns, new deduction lines and occasionally a different column order. The underlying structure has been stable for years: one row per sub order, a transacted value, a stack of deductions and credits, then a final settlement amount with a payment date and a UTR.
Related seller guides
More on the operations, money and claims that decide whether a marketplace catalogue actually makes money.
Meesho Payment Deductions Explained Line by Line (2026)
Every deduction on a Meesho settlement explained: commission, shipping and logistics, return and RTO costs, penalties, TCS and TDS, and adjustments. What each line means, which ones are wrong most often, and how to spot an incorrect dedu...
Marketplace deductions glossary: every settlement term decoded
Every deduction on an AJIO or Meesho settlement in plain English, commission, GST on fees, RTO, weight adjustments, TCS, TDS, negative balance, with the disputable lines flagged.
Meesho payment cycle: when you actually get paid
The settlement timeline, every deduction applied before payout, and why your bank credit never matches your order value, plus how to tell a normal gap from a wrong one.
Meesho payment not received: trace where the payout went
A diagnosis ladder for a missing Meesho payout, settlement cycles, return-window holds, penalties that consumed it, bank re-verification, and the escalation path that gets a reply.
Meesho seller charges & deductions: every line on your payout
Commission, shipping, SLA penalties, cancellation charges, return and RTO reversals, TCS and TDS, every charge on a Meesho payout, what each means, and which ones you can claim back.
TCS & GST on marketplace sales: a seller's guide
TCS, TDS and GST explained for AJIO and Meesho sellers, current rates after the 2024 revisions, where the money goes, and how to reclaim the tax that's prepaid on your behalf.
TCS Reconciliation: From Marketplace Reports to Your GSTR
The TCS a marketplace deducts should equal the TCS it deposits against your GSTIN, but only reconciliation proves it. Here is how to match TCS collected to TCS credited, from settlement report to GST return.
Meesho Commission by Category: What Each Costs (2026)
Meesho commission varies by category and changes over time, so no fixed table is reliable. Here is how commission works, why it differs by category, how to read your exact rate in the supplier panel, and how commission plus shipping plus...