Upload your invoice export and find every invoice that will be rejected — before it reaches GSTR-1. Up to 100 invoices per batch. Upload your CSV export Tally, Zoho, Busy or a GSTR-1 export. One row per line item. What your file needs One row per line item. Repeat the invoice-level fields on every row of the same invoice — we group by invoice number. Required columns: invoice_number, invoice_date, supplier_gstin. Everything else is optional but improves coverage. Include your stated totals (invoice_total, invoice_tax_total) if you have them — that lets us reconcile them against the line items rather than deriving them. Common header spellings from Tally, Zoho, Busy and GSTR-1 exports are recognised automatically. What the batch check does It reads a CSV of invoices and runs the same sixteen statutory checks over every row that a single check runs over one — GSTIN structure and state code for both parties, the tax head against place of supply, whether CGST and SGST split evenly, HSN presence and length, the rate against the permitted slabs, the tax recomputed line by line, line totals against the invoice total, invoice number length and characters, date sanity, reverse charge consistency, and rounding at both line and invoice level.

Results come back worst first. The point of a batch is not to read every row — it is to find the handful that will fail on upload, so you can fix those and file. Every flag names the rule or section it comes from, so a practitioner can check the reasoning rather than take it on trust. What file to give it A CSV export from Tally, Zoho Books, Busy or the GSTR-1 offline tool works as it comes. Column names do not have to match ours — common variations are recognised, so Invoice No , Invoice Number and Inv No all read the same. One row per line item; rows sharing an invoice number are grouped back into one invoice before the checks run, which is what lets invoice-level totals and rounding be checked at all. Up to 100 invoices per upload, and the file stays under 2MB. Nothing is written to a database — a free batch is processed in memory and discarded. Why run it before filing rather than after A GSTR-1 upload fails on the JSON as a whole. One malformed invoice number or one tax head that contradicts the place of supply returns an error code against that record, and the practical effect is a return you have to unpick and resubmit under time pressure — usually on the 10th or 11th. The errors that cause it are mechanical and almost all of them are visible in the data before submission. Catching them the week before costs a few minutes. Catching them at the portal costs an evening, and sometimes a late fee under Section 47 plus interest under Section 50 if the return slips past the due date as a result. For a practice filing across many clients, the same argument applies with more force: the mechanical layer is the one that scales badly and the one a person should not be spending review time on. If the portal has already rejected a return Every GSTR-1 upload error has a code, and the code says exactly which field the portal objected to. Look up a GSTN error code — RET191113, RET191150, RET191205 and the rest, each with what actually triggers it.