Exporting GSTR-1 as JSON from TallyPrime — the upload errors nobody warns you about

TallyPrime will happily generate a GSTR-1 JSON file that looks complete and then gets rejected — or worse, accepted with silent errors — at the GST portal. Most of the guidance in circulation treats this as a file-format quirk. It usually isn't. Here's the actual export-to-upload sequence, and the specific errors that stop it.

Two files, not one — what "export as JSON" actually means in TallyPrime

The most common reason a GSTR-1 upload fails isn't a bad export at all. It's that TallyPrime's GSTR-1 JSON and the rate-wise HSN/SAC summary are two separate exports, generated from two different places in the software, and it's easy to send the portal only one of them.

The main return — B2B, B2C, credit/debit notes, exports, nil-rated and the rest — is generated from TallyPrime's GST Returns export. The HSN/SAC summary is a different report (GST Annual Computation > Summary of Outward Supplies), and per TallyPrime's own export guidance it has to be pulled out as Excel or CSV, reshaped to match the GST Offline Tool's HSN template, and imported into the Offline Tool separately before a combined JSON is generated for upload. Treat the JSON export and the HSN/SAC summary as one job with two deliverables — not one file you tick off and move on from. (Tally mechanics in this article verified against Tally's own documentation as of 10 August 2026.)

Exporting the JSON: the steps in TallyPrime

If you'd rather review the numbers before anything reaches the portal, TallyPrime also supports exporting to Excel or CSV first and generating the JSON afterwards through the GST Offline Tool — useful when you want a human to eyeball the return before it becomes a file.

Uploading to the GST portal: the sequence that avoids errors

The upload itself is short, but two ordering details in it are exactly where TallyPrime's own error-resolution guidance says avoidable failures happen:

1. Log in to the GST portal and go to Services > Returns > Returns Dashboard.
2. Select the filing period and click Search.
3. Click Prepare Offline, then Upload, and select the JSON file you generated from TallyPrime.
4. Wait for the portal to finish processing before navigating away — an interrupted upload can leave a corrupted or partial submission.
5. Once processed, open the return, verify the auto-populated details against your Tally figures, and e-sign to complete filing.

The upload errors nobody warns you about

Most of what stops a GSTR-1 JSON at the portal traces to a small, repeatable set of causes. This is what TallyPrime's own error-resolution guidance flags, described here rather than quoted verbatim:

Note what all of these have in common: not one of them is actually a JSON formatting problem. Every row in that table is TallyPrime correctly reporting a value that was already wrong, incomplete or outdated on the voucher.

The pattern behind the errors is the register, not the file

That's worth sitting with, because it changes what "fixing the error" should mean. A JSON export is a faithful transcription of whatever is already in your sales register at the moment you export it. TallyPrime doesn't invent an invalid GSTIN, misclassify an HSN code, or leave a UQC blank — it reports one that was entered that way, possibly months earlier, possibly by someone who has since left the team. The upload failure is the first time anyone notices; it is rarely the first time the error existed.

Which means re-exporting the same period over and over, hoping a different JSON generation clears the same portal validation, is the wrong instinct. The fix that actually holds is catching the bad GSTIN, the missing HSN code or the wrong place of supply at the point the voucher is entered — not at the point you're trying to file. Doing that consistently, invoice by invoice, across a sales register with any real volume, is exactly the kind of checking that is painful to do manually every single filing cycle.

Why the JSON you upload matters beyond your own filing

GSTR-1 isn't only a filing you do for yourself. Every invoice in it becomes the source document for your buyer's credit: under Section 16(2)(aa) of the CGST Act, read with Rule 36(4)(b) and Rule 60(7) of the CGST Rules, a recipient can claim input tax credit only on an invoice you've furnished in GSTR-1 and that is then communicated to them in GSTR-2B. An invoice that uploads with the wrong buyer GSTIN, or fails to upload at all and quietly gets left out of a re-export, doesn't only cost you a rejected file — it's a gap your customer finds later, in their own reconciliation, with no easy way of knowing it traces back to a formatting error on your side.

Whether e-invoicing applies to you turns on turnover, not on Tally. Under Rule 48(4) of the CGST Rules — which fixes no threshold itself and delegates it entirely to notification — a registered person, other than a government department, a local authority, a Special Economic Zone unit, an insurer, a banking company or financial institution (including an NBFC), a goods transport agency, a passenger transport service, or a multiplex-cinema admission supplier, must generate e-invoices for its B2B supplies and exports (B2C invoices are outside Rule 48(4)) once its aggregate turnover has exceeded ₹5 crore in any preceding financial year from 2017-18 onwards (Notification 13/2020-Central Tax dated 21 March 2020, as amended by Notification 10/2023-Central Tax w.e.f. 1 August 2023; as of August 2026). It is a preceding-year test, not a current-year one, and coverage is permanent once crossed — turnover falling back below ₹5 crore later doesn't take you out of the regime. If it applies to you, every covered invoice needs a valid Invoice Reference Number before it reaches this export at all, and TallyPrime's own error guidance is specific about both the format and the scope for that case: open the GSTR-1 report in CSV format, and upload the files created for sections other than B2B and exports through the ordinary route. B2B and export sections are handled through the e-invoicing flow instead — IRP-reported documents already auto-populate into the corresponding GSTR-1 tables two days after generation (GSTN advisory on auto-population of e-invoice details into GSTR-1, 30 November 2020), so re-uploading them through the ordinary JSON would duplicate what the portal already holds.

If the error only shows up after you've already filed

Not every mistake gets caught at upload. A wrong inter-state classification or an incorrect taxable value can clear the portal's validation and only surface later — for instance when your own GSTR-3B Table 3.2 — the inter-state B2C/composition/UIN breakup auto-populated from your GSTR-1, GSTR-1A or IFF — carries a place-of-supply split that doesn't match reality (non-editable from the November 2025 tax period per GSTN advisory of 5 December 2025 — portal configuration, not a statutory rule; position as of August 2026). Once a GSTR-1 is filed, there's no going back into TallyPrime and re-exporting a corrected JSON for the same period. The fix lives one form upstream — via a GSTR-1A for that same period — but only while the window is open: GSTR-1A closes the moment you file GSTR-3B for that period (Rule 59(4A), CGST Rules; Notification 12/2024-Central Tax dated 10 July 2024). In the exact scenario above — the error surfacing only after the 3B is already filed — that same-period window is already gone. The correction then has to travel through the amendment tables of a later month's GSTR-1 instead, subject to the outer limit in the proviso to Section 37(3) of the CGST Act: 30 November following the end of that financial year, or the date you furnish the annual return, whichever is earlier (and, for a credit note, the same limit under Section 34(2)). Not in Tally either way — GSTR-1A and the later-month amendment tables are both GST portal filings, not something you generate from TallyPrime's export.

How Recoup fits in

Recoup doesn't replace TallyPrime's export — it works from the same registers you're exporting from, continuously reconciling your ITC against GSTR-2B and flagging register-level gaps on both sides of your reconciliation before either side ever reaches a filing screen. Every row in the errors table above is the same underlying problem: a value that was already wrong in the register, long before anyone tried to export it. Catching that upstream, invoice by invoice, is what turns "the upload failed again" into a filing that clears the first time.

Related guides