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.
The CGST vs IGST post is the short version: same state, CGST+SGST; different states, IGST. This page is the longer one. "Same state" according to what?
On a clean e-invoice the place of supply is a field. On a photocopy it may be a printed line, a header that still says the supplier's home state, or nothing. Bill-to can be a factory in Karnataka while the GSTIN on the invoice is Delhi. Ship-to can be a job-work shed in a third state. The rupees still add. The regime can still be wrong.
Seller state = seller GSTIN prefix (or an extracted seller state code). Place of supply = extracted POS state if present, else the buyer GSTIN prefix. Intra-state CGST+SGST, or inter-state IGST. Fails the check and cannot auto-export. That is check_tax_regime. It does not decide POS for services or SEZ. That is the Act, not a validator.
What the law means, and what this blog will not do
Place of supply is a statutory determination under the IGST Act (goods and services have different rules). CBIC publishes the Act and later circulars. Read those. A factory AP post is not a substitute for the current text on services, immovable property, or special cases.
I will not paste a "POS is always the delivery address" slogan as if it covered installation, bill-to-ship-to, and SEZ in one sentence. If your invoice is a service, or the goods never enter your plant, stop and ask the CA. The gate is for ordinary purchase tax invoices of goods, which is most of the photocopy pile.
GSTIN state is simpler. It is the first two characters of a 15-character GSTIN. 27 is Maharashtra. 29 is Karnataka. 07 is Delhi. The list we validate against is in validators/gstin.py (01-38, plus 97 and 99). That list is a checksum/format helper. It is not the IGST Act.
Bill-to, ship-to, and one blurry address
Many small-supplier invoices print one address block. OCR may read it as seller, buyer, or neither. A Maharashtra seller billing a Delhi GSTIN but delivering to a Maharashtra job worker is a POS question. Our extractor may never see three clean fields. Then the regime check falls back to GSTIN prefixes. That is conservative for "did CGST vs IGST match the two GSTINs." It is not a court-ready POS memo.
seller GSTIN state vs POS state
Extracted place_of_supply_state_code wins over the buyer GSTIN.
seller GSTIN vs buyer GSTIN
Same prefix: CGST+SGST expected. Different: IGST. Address text is not geocoded.
Both CGST/SGST and IGST on the same invoice is a conflict either way.
A worked mismatch, without pretending it is your factory
Seller GSTIN starts 27. Buyer GSTIN starts 07. Invoice prints CGST and SGST, no POS line. Effective POS becomes 07 (buyer). Seller 27 != 07, but only CGST/SGST is charged. The check fails. Status is NEEDS_REVIEW. A person looks at the scan. Maybe the template is wrong. Maybe the buyer GSTIN was mis-read. Maybe POS really is Maharashtra and the paper never said so. The human decides. The file does not auto-export an IGST fiction or a CGST fiction.
The reverse also fails: 27 vs 27, but only IGST on the page.
UTGST sits with CGST/SGST in the same bucket for this check (utgst counts as the intra-state pair). Union Territory paper is still regime, not a separate product. Confirm UT codes on the GST portal when you care about a specific UT.
What we do not decide
We do not compute POS for services, SEZ, or OIDAR. We do not parse "bill to ship to" paragraphs into a state code unless the extractor filled place_of_supply_state_code. We do not override a printed POS with an address model. If those are your invoices, they should hit review, and the CA should treat them as POS work, not OCR work.
Checksum can still pass. Arithmetic can still close. Wrong regime is a different failure. That is the point of splitting the posts. Link GSTIN and totals if you need those gates. This page is only "which state did we use, and did the tax type match."
- CBICcbic-gst.gov.in
Acts and circulars on place of supply. Read the current text. This page is not it.
- GST portalgst.gov.in
Taxpayer search and GSTIN state.
- EntryLedger/blog/cgst-sgst-igst-regime-check
The short regime post. Code:
validators/cross_field.pycheck_tax_regime.
Do you compute place of supply?+
No. Printed POS state if we extracted it. Else buyer GSTIN prefix. No geocoder.
Bill-to says Karnataka, GSTIN says Delhi?+
The check follows POS/GSTIN fields. The address still needs a person. That is review.
Is this legal advice?+
No. IGST Act and CBIC circulars are. We only say what the validator compares.