Reconciling GSTR-8 TCS With Your Books
GSTR-8 is the return you never file but must always check. Each marketplace files it monthly, reporting the supplies you made through the platform and the TCS collected against your GSTIN — and those numbers become your cash-ledger credit only after you accept them. Accepting without reconciling means adopting the operator's version of your sales as truth. This article gives you a concrete, repeatable method for tying GSTR-8 data to your books before you click accept.
Build the books side first: the TCS receivable ledger
You cannot reconcile against a ledger that does not exist. The foundation is a TCS receivable ledger per marketplace (Amazon TCS receivable, Flipkart TCS receivable, Meesho TCS receivable), posted from settlement reports as part of your normal monthly booking — not reconstructed at acceptance time. Each posting should carry the period it relates to, because GSTR-8 matching is period-wise.
If your books currently record only net payouts, this ledger cannot be built, and that is the real problem to fix. TallySutra constructs it automatically: importing Amazon, Flipkart, and Meesho reports produces balanced TallyPrime vouchers in which TCS is split from sales, fees, and TDS into its own receivable ledger, reconciled against the settlement totals.
The month-end matching routine
- Pull the operator data. After marketplaces file GSTR-8, open the TDS/TCS credit received statement on the GST portal for the period. Note, per operator: reported taxable supply value and TCS amount, head-wise (CGST/SGST vs IGST).
- Pull the books data. For the same period and marketplace: net taxable sales (gross minus returns) and the TCS receivable posted.
- Compare at two levels. First the TCS amount; if it differs, compare the underlying supply values — TCS differences are almost always supply-value differences at 0.5% scale.
- Accept what matches; hold what does not. Reject entries that are simply wrong (wrong GSTIN, wrong period); investigate the rest before acting.
- Record the acceptance. Move accepted amounts from TCS receivable to the electronic-cash-ledger balance in your books, so the receivable ledger always shows only unaccepted TCS.
Decoding the differences
| Symptom | Usual cause | Resolution |
|---|---|---|
| Operator reports more supplies than books | Books missed orders (unimported report, period cutoff on order vs invoice date) | Re-import and re-cut the period; duplicate-safe importing prevents double-booking on the redo |
| Operator reports fewer supplies than books | Returns netted by operator in a later period than your credit notes | Track the difference as timing; it should reverse next period |
| Head mismatch (IGST vs CGST/SGST) | Place-of-supply divergence between your books and platform data | Fix the state mapping — see place of supply rules |
| TCS reported under wrong GSTIN | Stale GSTIN on seller account, or multi-state attribution error | Reject; correct the seller-portal GSTIN; ask the operator to amend |
| Small persistent differences | Rounding conventions, shipping/gift-wrap inclusions | Quantify once, document the convention, tolerate within a defined threshold |
Give the routine a cadence and an owner. Run the match within days of the operators' filings each month, not quarterly in arrears, and track a small ageing view of pending TCS by marketplace: current items, items under investigation, and anything older than two cycles. Old differences are exponentially harder to resolve because seller-support teams work from recent data, so escalate aged items with documented tickets while the trail is warm. A ten-minute monthly ritual here protects both your cash-ledger credit and the sales-completeness evidence it silently generates. If several people touch the books, note the acceptance decision and its evidence in the same place every month, so the trail survives staff changes and portal redesigns alike.
Why the discipline pays off beyond TCS
Because TCS is 0.5% of net taxable value, a clean GSTR-8 reconciliation is simultaneously a sales-completeness check: if the operator's supply figure matches your books, your GSTR-1 sales for that marketplace are corroborated by an independent filing. The same comparison that protects your cash-ledger credit also pre-answers the GSTR-1-versus-GSTR-8 cross-check that scrutiny runs — a theme developed in our audit preparation guide. Sellers who do this monthly rarely meet a TCS surprise older than thirty days.
Scope note
This method covers the standard goods-seller case. Operator-liable supplies under Section 9(5), exempt goods in your catalogue, and cross-period amendment mechanics can complicate the picture, and portal statement layouts evolve. Keep the method, verify the specifics, and have a qualified CA or tax professional resolve differences you cannot explain — especially before rejecting operator entries or writing off receivable balances.
Frequently asked questions
Should I accept GSTR-8 TCS entries before reconciling them?
No. Acceptance adopts the operator's figures as your credit. Match the reported supply value and TCS against your per-marketplace TCS receivable ledger for the period first, and investigate or reject entries that do not tie.
Why does the operator's supply value differ from my sales for the month?
Most differences are timing: order-date vs invoice-date cutoffs, or returns netted by the operator in a different period than your credit notes. Genuine causes also include missed report imports and place-of-supply mapping errors.
What should the TCS receivable ledger show at any moment?
Only TCS deducted by marketplaces that you have not yet accepted on the portal. On acceptance, the amount moves out of the receivable into your electronic cash ledger balance, keeping the ledger a live pending-items list.
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