Here is a true pattern, with the numbers rounded for privacy. A seller doing roughly 300 orders a month across AJIO and Meesho checked her payments the way most sellers do: panel total versus bank total, once a month. The two matched within about 2%, which felt fine — 2% is rounding, surely. When we ran the same month order by order, the “rounding” decomposed into eleven double-charged return fees, two penalties with no matching late event, and four delivered orders that had never settled at all. The total was quiet. The orders were screaming.
That is the entire case for payment reconciliation in one paragraph: a single bank credit covering 300 orders is a place where errors go to hide. Marketplace settlement systems are mostly right — but “mostly right” across thousands of automated fee, penalty, reversal, and adjustment events means a steady drip of individually small mistakes. Each one is too small to notice in a total and too real to ignore in aggregate. This guide is the complete method for finding them: the three-way match, the aging buckets, and the discipline of turning unexplained gaps into disputes filed inside the window.
Why one number for 300 orders hides everything
Totals fail for three structural reasons. First, errors are symmetric-looking: a ₹40 short-payment here and a legitimate ₹40 adjustment there cancel inside a five-digit sum while one of them is wrong. Second, cycles bleed: any payout mixes this week's matured orders with last month's return reversals and a claim outcome from six weeks ago, so the total never maps cleanly to a period you can reason about. Third — and most expensive — missing orders make no sound. A delivered order that never enters any settlement produces no line, no debit, no anomaly in the total. It is just revenue that silently never arrived. From sellers we've sat with at 5–25 orders/day, the missing-settlement case is the single most common five-hundred-plus-rupee find in a first reconciliation, and it is literally invisible to total-versus-total checking.
The three-way match
Reconciliation done properly matches three documents against each other, per order:
- Your order ledger. What you actually shipped: order ID, dispatch timestamp, item, expected payout under your rate card. If you do not have an expected payout per order, build it — reconciliation without an expectation is just reading.
- The settlement statement. What the marketplace says happened: gross, fees, taxes, penalties, reversals, net. This is the platform's claim about reality, order by order.
- The bank credit. What was actually paid. Statements occasionally promise what the transfer does not deliver; the bank line is the ground truth the other two answer to.
The triangle matters because any two legs can agree and still be wrong. Statement matches bank? You still miss orders that never settled. Ledger matches statement? You still miss a transfer that bounced or netted oddly. The match runs ledger → statement → bank for every order, and the residue — the lines that do not tie out — is your work queue.
Building the expected-payout number
The three-way match has a prerequisite most guides skip: leg one only works if your order ledger carries an expected payout per order, and that number has to be built, not wished for. The construction is mechanical. Start from the sale price. Subtract the contractual lines you can compute in advance — commission at your rate-card percentage, the logistics fee for that weight band, 18% GST on both. Subtract the statutory lines — GST TCS and income-tax TDS at current rates. What remains is the number the settlement should pay if nothing happened to the order. Returns, penalties, and adjustments then become explained departures from that expectation rather than noise. Build it once as a formula keyed to category and weight band, and every new order gets its expectation for free. Two practical notes: refresh the formula whenever your rate card or a category mapping changes, because a stale expectation generates false alarms that erode your trust in the whole system; and keep the expectation per order, not per SKU — the same kurta settles differently at different sale prices, and averaging across them re-creates exactly the blur you are trying to remove.
What the match turns up: the six discrepancy types
Run the triangle for a month and the residue sorts into a small taxonomy. In rough order of how often sellers find them (illustrative shares, but the ranking is stable in our experience): delivered orders missing from every settlement; return or RTO fees charged twice for the same order; penalties applied with no matching event in your timestamps; commission or fee rates that drifted from the signed rate card; reversal credits that never arrived after a won claim; and tax lines that do not tie to Form 26AS or the GST portal. The first three are pure process failures on the platform side — and they are the ones with strong dispute win rates, because the evidence is documentary: an order ID, two statement lines, a timestamp.
Aging buckets: how gaps become urgent
A gap you found is only worth something if you act inside the dispute window — so every unresolved line needs an age. The buckets we use: 0–7 days (normal — the cycle simply has not matured; watch, do not chase), 8–21 days (attention — the order should have settled; verify delivery status and check for a silent hold), 22–45 days (action — this is now a dispute candidate; assemble evidence and file), and 45+ days (escalation or write-off — file if any window remains, otherwise log it as a known loss so the pattern stays visible). The buckets do two jobs: they stop you panicking about normal lag, and they stop normal-feeling lag from quietly becoming a dead claim.
The bucket boundaries are not sacred — tune them to your marketplaces' observed cycles, not their stated ones. What is sacred is that every unresolved line has exactly one bucket and the buckets get reviewed on a schedule. A seller we worked with kept a beautifully accurate gap list and still lost a quarter's worth of disputable charges, because the list had no ages on it: everything felt equally non-urgent until everything was equally expired. Aging is what converts a list into a queue.
Classify before you fight
Not every gap is an injustice. The fastest way to burn credibility — and hours — is disputing correct deductions. Every residue line gets one of four labels: explained (a real fee or reversal you simply had not mapped — update the expectation), reclaimable tax (GST on fees, TCS, TDS — recovered through filings, not disputes), dispute candidate (documentary evidence says the platform is wrong), or accept-loss (a real defect, a real mis-pick, a timestamp that is genuinely yours). The honest classification is the whole craft. Sellers who dispute everything get slow outcomes on the claims that matter; sellers who dispute nothing fund the platform's error rate out of their margin.
A classification habit worth stealing: when a gap resolves as “explained,” write down what explained it. Three explained gaps with the same cause — a weight-band fee you had not mapped, a new packaging charge, a category re-mapping — are not three explanations; they are one change to your expected-payout formula. The explained bucket is where your model gets smarter, which is why sellers who skip the writing-down step find themselves re-investigating the same “mystery” every month.
The monthly workflow (run weekly at volume)
The full ritual, end to end: pull every settlement statement and the bank statement for the period; match each order through the triangle; age everything unresolved into the four buckets; classify each gap into the four labels; dispute the candidates with evidence attached, inside the window; and track outcomes so your recovery rate and your repeat-offender categories are visible. At 1–5 orders/day this is a genuine 30–60-minute monthly session in a spreadsheet. Past roughly 10 orders/day across two marketplaces, the row count and the adjustment-chasing outgrow a human — which is the point where the method either gets software or gets abandoned. We wrote up the spreadsheet breaking point separately in Robnu vs spreadsheets.
Where Robnu fits
Robnu is an agentic OMS — it runs daily marketplace operations itself, and the same order ledger that processes your AJIO and Meesho orders powers automatic reconciliation: every order carries its expected payout, gets tied to its settlement line and bank credit, and unexplained gaps surface as flagged orders with the paper trail already attached. Dispute candidates flow into claims filed for you — autonomous filing is rolling out now, and we will be straight with you: the occasional marketplace flow still wants a human, so you sometimes get a one-click approval instead of zero clicks.
Robnu is free for everyone right now — every feature, every order, no card, no trial timer — while we figure out paid pricing. When it launches, sellers under 25 orders/day stay free forever, and today's users get grandfathered locked rates. But the method above works with or without us. Pull last month's statements tonight, match twenty orders by hand, and see what the residue says. If it ties out clean, sleep well. In our experience, it rarely does.