Fixing GST Mismatches: Reports vs Books
Every marketplace seller eventually stares at three numbers that should be identical and are not: sales per the marketplace report, sales per the books, and sales per GSTR-1. The instinct is to blame someone — the platform, the accountant, the portal. The reality is more mechanical: each system counts slightly different things at slightly different times, and without a deliberate reconciliation the drift compounds monthly. This is a field guide to the actual root causes, roughly in order of frequency, and a repeatable process for closing them.
The usual suspects, ranked
| # | Root cause | Signature |
|---|---|---|
| 1 | Date-basis drift — order date vs invoice date vs shipment date vs settlement date | Mismatch flips sign around month boundaries; annual totals nearly agree |
| 2 | Returns counted differently — operator nets returns in its period; your credit notes land in another | Operator supplies lower than books one month, higher the next |
| 3 | Missing report imports — a settlement file never loaded, or a marketplace's secondary report (giftwrap, recharges) ignored | Books persistently lower by an explainable cluster of orders |
| 4 | Duplicated imports — a corrected report loaded over the original without deduplication | Books persistently higher; duplicate invoice numbers in registers |
| 5 | Net-payout booking — only settlements booked, so gross sales never enter the books | Books dramatically lower than both report and GSTR-8 data |
| 6 | State/head mapping errors — wrong place-of-supply column used | Totals match; state-wise and IGST-vs-CGST/SGST splits do not |
| 7 | Cancellations and test orders — rows present in one system, filtered in another | Small stubborn residue after everything else reconciles |
Prevention beats archaeology. Once a month reconciles, freeze it: adopt a closing checklist under which reconciled periods are locked in the accounting system and any later marketplace correction enters through a current-period adjustment rather than silently rewriting history. Duplicate-safe importing is the technical half of this discipline; the procedural half is simply refusing to let anyone re-open a tied-out month. Sellers who adopt period-locking find that mismatches stop compounding — each month's residue is small, explained, and stays explained. The same locking habit also makes audits faster, because every historical month already carries its reconciliation and explanation, frozen at the moment the facts were freshest.
Why mismatches matter more for e-commerce
Offline businesses reconcile against their own records; marketplace sellers are reconciled against by the state. The operator's GSTR-8 gives the department an independent, GSTIN-wise statement of your supplies, and automated comparisons of GSTR-1 vs GSTR-8, and GSTR-1 vs GSTR-3B, generate notices without a human ever choosing to look at you. A mismatch you have not already explained is a notice you have not yet received — the notice-handling side is covered in our guide to common GST notices.
A closing process that converges
- Fix the date basis first. Decide (with your CA) the event that books a sale, apply it uniformly, and re-cut both sides of every comparison on that basis. Half of all "mismatches" die here.
- Reconcile order counts before amounts. Matching counts localises the problem to specific orders; matching amounts on mismatched counts is astrology.
- Work marketplace-wise, month-wise. Never reconcile the blended total — each platform's reporting quirks need isolation.
- Classify every residual order into the table above; anything that resists classification goes to an exception list with an owner.
- Document the standing differences (timing, RTO policy) once, so future months inherit the explanation.
Tooling the process
Steps 2–4 are row-level work across thousands of orders — the exact layer TallySutra automates. It imports Amazon, Flipkart, and Meesho reports into balanced TallyPrime vouchers, reconciles them against settlements, refuses duplicates on re-import (killing suspect #4 outright), and routes unclassifiable rows into an exception queue with a review trail — so the residue a human must examine shrinks from thousands of rows to a handful. The full pipeline is described on the features page.
When the mismatch is real
Sometimes the process ends with a genuine gap: supplies short-reported, tax short-paid, or excess ITC claimed. Correction paths exist — amendments in subsequent returns, differential payments — but their selection and timing carry interest and procedural consequences. That decision belongs with a qualified CA or tax professional, made before the department makes it for you. This article is educational; the reconciliation method is yours to run, and for the audit-scale version of it see our audit preparation guide.
Frequently asked questions
My marketplace report and books almost match yearly but never monthly. Why?
That signature is date-basis drift: the systems book the same orders against different events (order, invoice, shipment, settlement dates), shifting sales across month boundaries. Standardise one basis and re-cut both sides before chasing anything else.
Which mismatch is the most serious?
Net-payout booking — recording only settlements so gross sales never enter the books. It understates turnover against both the operator's GSTR-8 and your own invoices, and it destroys the fee ITC trail at the same time.
Can I just amend my returns whenever a mismatch is found?
Amendment and differential-payment routes exist, but choosing among them affects interest and procedure. Quantify the gap through reconciliation first, then let a qualified CA decide the correction path and timing.
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