Verify Tally GST Reports After Marketplace Imports
An import that finishes without errors is not the same as an import that filed-ready books came out of. GST is where sloppy marketplace imports surface — a rate mapped wrong on one SKU, a batch of credit notes missing, inter-state sales booked as intra-state — and the cheapest time to catch all of it is right after the import, not during filing week. This is the verification routine we recommend to sellers and CAs, straight after each marketplace batch lands in TallyPrime.
The three reports to open first
- GSTR-1 view — TallyPrime summarises outward supplies by section. For marketplace sellers the B2C tables and the credit note detail are where your import shows up.
- GSTR-3B view — the summary of outward tax liability and input credit for the period.
- HSN summary — rate- and HSN-wise totals, which expose SKU-level rate mapping mistakes instantly.
TallyPrime also flags transactions with incomplete or conflicting GST information in its return views — resolve that exception list to zero before comparing totals; those vouchers are excluded from the totals you are about to check.
Work the exceptions in a fixed order: missing or invalid GSTIN details on party masters first, then rate and HSN gaps on stock items, then vouchers with conflicting tax analysis. The order matters because master-level fixes clear whole groups of exceptions at once, while voucher-level fixes are one-at-a-time work. Most marketplace-import exception lists trace back to a handful of masters created in a hurry — fixing the master once beats clearing the same exception every month.
Tie out against the marketplace's own GST reports
The platforms produce GST-oriented reports precisely so you can cross-check: Amazon's MTR (Merchant Tax Report), Flipkart's GST reports, Meesho's tax summaries. The comparisons that matter:
| Check | Compare | Mismatch usually means |
|---|---|---|
| Taxable value | Marketplace GST report vs Tally GSTR-1 view | Missing vouchers, or shipped-vs-invoiced timing |
| Tax by rate | Rate-wise totals both sides | Wrong GST rate on a stock item or sales ledger |
| Inter vs intra state split | IGST vs CGST+SGST totals | Place-of-supply mapping errors on imports |
| Credit notes | Return totals vs credit note section | Returns imported as journals, or missed entirely |
| Voucher counts | Report row counts vs Day Book counts | Partial import — rejected vouchers never re-imported |
Do not forget the TCS side
Marketplace operators file GSTR-8 for the TCS they collect, and that credit appears for your acceptance on the GST portal. Verify that the TCS booked in your books for the period matches what the portal shows before accepting — differences usually trace to settlement-period boundaries. TCS accepted on the portal becomes cash-ledger credit; how you offset it in filings is your CA's call, and the treatment is worth confirming rather than assuming.
Timing explains most TCS differences that look alarming at first. The operator's GSTR-8 follows the platform's settlement calendar, while your books follow voucher dates; an order settled on the first of the next month carries its TCS across the boundary. Before raising a dispute with a marketplace, reconcile one month later — the difference usually resolves itself into the adjacent period.
A monthly rhythm that holds up
- Import and verify each marketplace batch as it arrives (counts, totals).
- Clear the GST exception list in Tally the same day.
- At month close, run the table above for each marketplace.
- Reconcile input credit on fee invoices against GSTR-2B.
- Hand your CA books that already tie to the marketplace reports.
The whole routine is thirty minutes when imports are clean — and it is the difference between filing from your books and filing from downloaded spreadsheets while your books lag behind. Put the five steps on the calendar against the filing dates, with names attached — a rhythm without an owner is a suggestion.
Cleaner inputs make cleaner checks
Every mismatch class above is preventable at import time, which is where TallySutra concentrates: it derives vouchers from Amazon, Flipkart and Meesho report data with rate and place-of-supply mappings you approve once, reconciles batches against settlement totals before your CA approves them, and re-imports are duplicate-safe, so counts stay honest. Books built that way tend to sail through this checklist — see the reconciliation features and the CA workflow. For the non-GST half of post-import checking, use the bulk import verification guide, and remember our returns piece — credit notes for marketplace returns — when the credit note section refuses to tie.
Frequently asked questions
Which marketplace report should I reconcile GSTR-1 against?
Use the platform's tax-oriented report — Amazon's MTR, Flipkart's GST report, Meesho's tax summary — rather than settlement files. Those reports are built on invoice values and rates, which is what GSTR-1 needs to match.
Why do my Tally GST totals differ slightly from the marketplace report?
The usual causes, in order: vouchers rejected during import and never re-imported, timing differences between shipment and invoice dates at period edges, wrong rate mapping on a few SKUs, and returns booked without proper credit notes.
How does marketplace TCS reach my GST filings?
The operator files GSTR-8; the collected TCS then appears on the portal for your acceptance and lands in your cash ledger. Match it against the TCS Receivable in your books first, and let your CA confirm the offset treatment.
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