Every order. Every portal.
Every rupee — accounted for.

One workbook per client and per portal, with every order on it — what you invoiced, what came back as a return, each charge the marketplace took, what finally reached your bank, and a remark saying why the two differ. Every summary on the other sheets is built from those rows, so any figure you query can be traced back to the orders behind it.

Four, mostly. Realisation ratio — what you were paid against what you sold, after returns. Pending payment — how many orders and how much value the marketplace still owes you. Return rate by value, not just by count. And charges as a share of sales, which is worth reading three ways: on one real client charges were 13% of gross sales, 24% of net sales, and 38% of what was actually realised. The third number is the one that changes decisions.

Yes — return percentage by state and by pincode, worst first, each shown beside that area's own sales value so an insignificant one is visible as insignificant. A minimum order count is applied and printed on the sheet, because the median pincode has only a couple of orders and an unfiltered ranking is just every one-order-one-return pincode sitting at 100%. Available for Myntra and Meesho today.

A month-by-month P&L: gross sales, returns, net sales, commission, forward and return logistics, other charges, settlement, TDS/TCS, total realisation and what is still pending. Alongside it sits a change column and a plain-language remark — Higher Commission %, Lower Return % — comparing the latest month with the one before. Each charge is compared as a percentage of that month's own gross sales, so a busy month does not read as a worse one.

A dashboard sheet: sales against returns with the return rate over it, realisation and its ratio, the charge mix, an order-status breakdown, and your top states and SKUs. Built for Myntra today; the other portals get the tables but not yet the charts.

Profit or margin. Marketplace data carries no cost of goods and no advertising spend, so any profit figure would be invented rather than calculated. There are cost rows on the monthly P&L for you to type your own figures into — and what you type survives the next reconciliation — but the tool will not guess them. It also flags an overcharge; it does not file the claim for you.

GSTR-1 is prepared from the same compiled data, split one file per registration, so the month you file is the month you reconciled. There is also an indicative net GST position month by month, including the input credit on marketplace charges. Indicative is the right word: marketplace data has no input credit on stock or expenses, so it is a cross-check against your books, not a return.

Sale takes the marketplace's GST or sales export; Payment takes the settlement files. Those two are required — everything else is built from them. Order Report and Non-Order Settlement are optional and add columns rather than rows — order status and SKU where that marketplace publishes them, and the ads and fees charged to the account rather than to any one order. Each card names what it wants and shows what you have already put in it.

This is the one that costs the most time. Opening an export in Excel and saving it again rounds long order numbers to scientific notation — 1.00254E+11 — and thousands of real orders collapse into a handful. One real month came through as 56 orders instead of 3,194. The tool spots the pattern and names the file, but the original digits are gone: the only fix is a fresh export that nothing has re-saved.

Settlements arrive as many files, sometimes thirty or more for a single month. Upload a few and the charges and realisation come out far too low — which reads exactly like a problem with your payouts rather than a problem with the upload.

Exports have a way of piling up in one place. Any file whose name clearly carries a different month is skipped automatically, and files with no recognisable date are kept, which is the safe default. The other months still need uploading as their own months if they are to be reconciled at all.

It does not replace it. If the wrong files went up, clear that card first and upload again — otherwise both sets are read and everything doubles.

The workbook is cumulative, not rebuilt each time: each month is merged into the running one. Reconcile April before May and the totals follow the business. Jump around and they still add up, but the month-on-month comparison stops meaning anything.

Marketplaces pay on their own cycle and returns land weeks after the sale, so the newest month on the sheet is always the worst-looking one. Check pending orders and pending value before reading it as a shortfall — that is timing, not money lost.

Orders marked pending payment are the ones to chase. Orders where the invoice and the settlement disagree are flagged separately — most turn out to be a return settling next month, but the rest are worth a human's attention, and those are the claims worth raising with the marketplace.

Rebuild From Scratch archives the existing workbook with a timestamp — it is never deleted — and recompiles every month cleanly. New columns only appear for months processed since they were added, so a rebuild is what backfills the history.