Which GSTR-1 upload error do you hit most often?

The most time-consuming GSTR-1 upload errors (RET191150, RET191205, RET191115, and RET191113) stem from master data mismatches, invoice numbering format violations, and post-tax discount calculation errors. Preventing them before generating the JSON requires implementing automated regex validation for 16-character invoice limits, verifying Place of Supply logic against state codes, and enforcing line-item level rounding rules.

RET191150 stands out as the one I’d expect to cause the most repeated troubleshooting, especially when the GSTINs and place of supply look correct but the portal interprets the transaction differently.

RET191205 also seems common because small rounding differences are easy to miss when checking the source invoice against the JSON.

For prevention, I’d validate GSTIN, place of supply, invoice number format, tax head, and tax calculations before generating the JSON. That should catch most of these before upload.

Thank you — the master data point is the part I hadn't framed properly.

I've been treating each flagged invoice as its own problem. But if the GSTIN or state code is wrong in the customer master, one bad record produces twenty bad invoices, and showing them as twenty separate errors is the wrong output entirely. The fix is one edit, not twenty.

Do you find it's usually the customer master, or the item master (HSN and rate) that causes more of it?

Also, on the post-tax discount point — is that mostly a system configuration issue, or people applying discounts manually after the tax line?

Agreed on RET191150 — the frustrating part is that the GSTINs often do look correct, because the tax type is legally decided by place of supply rather than the buyer's registration state. Same-state GSTIN with delivery to another state is the case that catches people.

RET191205 and RET191150 together consume the most time in our experience.

BEST PRE-UPLOAD VALIDATION APPROACH:

Before uploading the JSON to GSTN portal:

1. RUN IT THROUGH THE OFFLINE TOOL first , GST offline tool (downloadable from GST portal) flags most schema errors including RET191115 (invoice number length) before you hit the portal
2. FOR RET191205 ROUNDING: Apply rounding AT INVOICE LEVEL, not line level. GSTN computes tax on taxable value at invoice level. Summing rounded line-level taxes = rounding error.
3. FOR RET191150: Check if any B2C supply in your JSON has both IGST and CGST/SGST populated , one should be zero based on place of supply
4. MULTI-GSTIN WORKFLOW: Maintain a naming convention for JSON files (GSTIN_PERIOD_v1.json) to prevent the wrong-GSTIN error (RET191113)

RET191115 is entirely avoidable with an invoice numbering policy , max 16 alphanumeric/hyphen/slash characters per Rule 46(b).

Apply rounding at invoice level, not line level" is easy to get wrong precisely because line-level rounding looks correct when you check it. Each line individually reconciles, so a manual review passes it, and the mismatch only appears when GSTN recomputes on the aggregated taxable value. Summing rounded line taxes and summing taxable values then rounding once are different numbers, and only the second matches what the portal does.

I'll say plainly that this is a gap in how most pre-upload validation is done, including my own — line-by-line checking will clear an invoice that GSTN then rejects. I'm changing that to check both levels.

On RET191150, one thing I'd add from the other direction: it has a mirror, RET191179, where IGST is charged but the place of supply equals the supplier's own state. The failure I see most often isn't people getting the tax type wrong in isolation — it's that the place of supply was recorded wrongly, and then someone "fixes" the error by changing the tax heads to match the wrong PoS. That clears the upload and leaves the buyer's ITC sitting under a head they can't use.

Also worth pairing with your multi-GSTIN naming convention: when the same defect appears across several invoices to the same counterparty, it's usually the customer master rather than the invoices. One wrong state code there produces twenty wrong tax heads, and fixing twenty invoices individually leaves the twenty-first still wrong next month.

A question, if you have a moment — on the offline tool: in your experience does it catch RET191205 rounding mismatches, or only structural/schema issues like the 16-character invoice number? My understanding was the latter, but you'd know better from actual filings.

RET191150 is probably the one I see most often. Wrong GSTIN or the system treating a transaction as inter-state causes a lot of confusion. We usually catch these with a basic GSTIN and place-of-supply check before generating the JSON.

Thanks — that matches what others in this thread have said.

The confusion you're describing has a specific root: the tax type is legally decided by place of supply, not by the buyer's GSTIN. Sections 7 and 8 of the IGST Act compare the supplier's location against the place of supply — the buyer's registration state is only a proxy, and it's the cases where the two differ that catch people. A buyer registered in Karnataka taking delivery in Maharashtra is intra-state, even though both GSTINs suggest otherwise.

Worth pairing your check with its mirror, RET191179 — IGST charged where the place of supply equals the supplier's own state. Same root cause, opposite symptom, and people often "fix" one by breaking the other.

The more useful thing in this thread

Following up — you were right about invoice-level rounding, and it was a genuine gap in what I'd built. I was checking each line against its own taxable value and nothing else, so an invoice where every line reconciles but the slab total drifts would have passed. It now recomputes per rate slab on the aggregate, the way GSTR-1 does. Thank you — that was the most useful correction I've had.

Still curious about the offline tool question if you get a moment: does it surface RET191205 rounding mismatches, or only structural issues?