The tax type on the invoice does not match the place of supply. Here is how to catch it.

Your supplier is in Maharashtra. You are in Delhi. The invoice carries CGST and SGST. That is wrong. When the seller and buyer are in different states, the tax should be IGST, not CGST+SGST. The total amount might be the same, but the tax type is wrong, and that wrong shows up at filing time.

Wrong tax type on an otherwise neat invoice shows up on scans. The supplier used the wrong template, or bill-to was not updated. The rupees still add. The regime is still wrong.

The rule is simple

If the seller state code matches the buyer state code, use CGST+SGST. If they differ, use IGST. The state code is the first two characters of the GSTIN. Seller state code 27 means Maharashtra. Buyer state code 07 means Delhi. If the codes differ, the tax must be IGST.

The rule is clear, but the error is common. Suppliers generate invoices from templates that may not be updated for every transaction. If a supplier has customers in multiple states, they might use the wrong template for a particular invoice. The result is CGST+SGST on an inter-state invoice, or IGST on an intra-state invoice.

Why this matters at filing time

When you claim ITC, the tax type on the invoice must match the regime of the transaction. If the invoice carries CGST+SGST but the transaction was inter-state, the ITC claim is suspect. The GST portal flags the mismatch. Your CA has to investigate. The investigation takes time. The time costs money.

Worse, if the mismatch is not caught and you file GSTR-3B with the wrong ITC, you may face a notice. The notice asks for explanation. The explanation takes time to prepare. The preparation costs money. All because the tax type on the invoice was wrong, and nobody checked.

How EntryLedger catches it

EntryLedger reads the seller state code from the GSTIN (first two characters) and the buyer state code from the invoice header. It checks whether the tax type on the invoice matches the regime. If the seller is in state 27 (Maharashtra) and the buyer is in state 07 (Delhi), and the invoice carries CGST+SGST instead of IGST, the regime check fails. The invoice goes to review.

This is a cross-field check. It needs data from two different parts of the invoice: the GSTIN and the buyer address. A check that only looks at the GSTIN will miss it. A check that only looks at the tax amounts will miss it. You need both. That is what makes it a cross-field check rather than a simple format check.

How often does this happen

We do not have a published corpus rate for how often this happens. You will see it more with multi-state suppliers and with scans where OCR misreads CGST vs IGST. Measure it on your paper. Do not budget from a percentage in a blog.

The fix is simple: check the seller state code against the buyer state code before posting. If they differ, the tax must be IGST. If they match, the tax must be CGST+SGST. If the invoice gets this wrong, send it back to the supplier for correction, or correct it yourself before posting.

The regime check in practice

The regime check is a cross-field check. It needs data from two different parts of the invoice: the GSTIN (which contains the seller state code) and the buyer address (which contains the buyer state code). It also needs the tax type from the invoice itself.

Here is how it works. The seller GSTIN starts with 27. The buyer address is in Delhi (state code 07). The invoice carries CGST and SGST. The regime check sees that the state codes differ (27 vs 07) but the tax type is CGST+SGST (intra-state). This is wrong. The tax should be IGST. The invoice goes to review.

The reverse also happens. The seller is in Maharashtra (27). The buyer is in Maharashtra (27). The invoice carries IGST. The regime check sees that the state codes match but the tax type is IGST (inter-state). This is also wrong. The tax should be CGST+SGST. The invoice goes to review.

Both directions are caught by the same check. The check compares state codes against tax type. If they do not match, the invoice fails. The person reviewing can see the state codes, the tax type, and the original scan. They fix it in seconds. The wrong regime never reaches Tally.

Why this matters at filing time

When you claim ITC, the tax type on the invoice must match the regime of the transaction. If the invoice carries CGST+SGST but the transaction was inter-state, the ITC claim is suspect. The GST portal flags the mismatch. Your CA has to investigate. The investigation takes time. The time costs money.

Worse, if the mismatch is not caught and you file GSTR-3B with the wrong ITC, you may face a notice. The notice asks for explanation. The explanation takes time to prepare. The preparation costs money. All because the tax type on the invoice was wrong, and nobody checked.

The regime check catches this at entry time. It takes seconds. The fix at filing time takes hours. One is process. The other is firefighting. The difference is a few seconds of validation versus hours of investigation.

Place of supply is not always “buyer GSTIN state.” Job-work, bill-to-ship-to, and SEZ make this messy. The simple two-state-code rule covers most manufacturer purchase invoices. When the invoice is bill-to-one-GSTIN ship-to-another, a naive check can false-fail. Those should go to review, not auto-export with a guess. Guessing the regime is how you create a 3B that does not match the invoice.

UTGST replaces SGST in Union Territories. If you only coded CGST/SGST/IGST and forgot UTGST, you will fail clean Chandigarh invoices. EntryLedger’s arithmetic includes UTGST in the roll-up. If you build a checker, include it. The Act does.

Do not “fix” regime by rewriting the supplier’s tax columns to match your theory of place of supply. If they printed CGST on an inter-state invoice, that is their document. Review. Ask them for a corrected invoice. Posting a rewritten tax type is a second set of facts. The gate exists to stop that, not to author it.

Clerks on a 1366×768 screen should see the seller state, buyer state, and tax columns in one glance, with the scan crop. If the UI hides the regime reason in a tooltip, they will skip it. Show the mismatch in words: “Seller MH, buyer DL, but CGST/SGST printed.” Then the click is obvious.

If you only remember one rule: same state, split tax. Different state, IGST. Everything else (SEZ, bill-to-ship-to) is a review, not an auto-export. That rule prevents most of the notices we see described as “GST type mismatch.”