Verifying a Customer's GSTIN Before You Invoice

Most GSTIN verification advice is written for buyers: check your supplier before you pay, so your input tax credit is safe. The sell side gets less attention, but the same fifteen characters matter just as much when you are the one issuing the invoice. The customer GSTIN you type into your billing system is what routes the credit to your customer, what decides whether you charge IGST or CGST plus SGST, and what the e-invoice portal checks before it will register the invoice. Get it wrong and the cost lands on you, as amendments, credit notes and a customer who will not pay until it is fixed.

What a wrong customer GSTIN actually breaks

When you file GSTR-1, every B2B invoice is reported against the recipient GSTIN you entered. The portal uses that GSTIN to place the invoice in the recipient's GSTR-2A and in their GSTR-2B, the static statement they use to claim input tax credit. Your customer can only take credit for invoices that show up there, under Section 16(2)(aa) of the CGST Act.

So the failure modes are concrete:

• A typo that produces another real GSTIN. The invoice lands in a stranger's GSTR-2B. Your customer sees nothing. The stranger sees an invoice they never received.
• A number that does not exist. The portal will generally refuse a GSTIN that fails validation, so this one tends to surface at filing time, the last minute to discover it.
• A cancelled GSTIN. The customer shut that registration and moved to a new one, or was cancelled by the department. Invoicing the old number means the credit goes nowhere useful.
• The right PAN, the wrong state. A customer with registrations in several states gives you their head-office GSTIN when the goods went to a branch. That is also a place-of-supply problem, covered below.

Your own output tax is usually not the issue: you declared the supply and paid the tax. The problem is commercial. Your customer's accounts team runs its GSTR-2B reconciliation, finds your invoice missing, and holds the payment or asks you to fix it. Because they carry the ITC risk, they are right to.

Fixing it after the fact: amendments and the GSTR-3B lock

Once an invoice has been reported with the wrong recipient GSTIN, the fix happens on your side, in your returns. The table below is the practical map.

GSTR-1A exists to fix the current period before GSTR-3B is filed, but it is built for adding missed records and amending values, not for moving an invoice to a different counterparty. Plan on a later-period amendment for a wrong recipient GSTIN, and confirm the current portal behaviour before you rely on either route.

This has become more of a problem since GSTR-3B's outward-supply liability started being auto-populated from GSTR-1, GSTR-1A and IFF and locked against manual edits. That lock is about values rather than counterparties, but it removes the old habit of filing a messy GSTR-1 and tidying up in GSTR-3B. The cleaner your GSTR-1 is on day one, the fewer amendment cycles you run.

If you e-invoice, the IRP checks it for you — once

If your turnover puts you under e-invoicing (the threshold is ₹5 crore aggregate turnover), every B2B invoice goes through the Invoice Registration Portal before it is valid. The IRP validates the buyer GSTIN against the GST register and rejects a request where the number is invalid or not in a state that can receive the invoice. That catches the non-existent and the cancelled number at generation time.

It does not catch a typo that happens to hit another valid, active GSTIN. The IRP has no way to know you meant someone else. It also only fires when you raise the invoice, after the customer master, the quote and the order were set up with the bad number, so the rejection shows up as a blocked invoice at the moment someone is trying to dispatch goods.

The state code decides more than the address line

The first two digits of a GSTIN are the state code of the registration. Your billing system very likely uses that code, compared with your own, to choose between IGST and CGST plus SGST. For many B2B supplies of services, where the default rule makes the place of supply the location of the registered recipient, that comparison is exactly right.

So a wrong GSTIN can mean the wrong tax head, not just the wrong name. Give a Maharashtra customer's invoice a Karnataka GSTIN by mistake and your system charges IGST on what should have been an intra-state supply. The recipient cannot use a head that should not have been charged; the fix is a credit note and a fresh invoice, with the tax paid under the wrong head recovered through the refund route the law provides.

For goods, place of supply follows where the movement ends, which can differ from the billing GSTIN's state. A verified GSTIN gives you a trustworthy state code to start from; it does not replace the place-of-supply rules. The state code finder maps codes to states if you need to check by hand.

Where in your process to check

The right moment is the earliest point the GSTIN enters your system, plus a recurring check for customers you keep.

• Customer master creation. This is the check that pays for itself most. Every quote, order and invoice inherits the master record, so a bad GSTIN there propagates everywhere.
• B2B checkout. If you sell online, the "add your GSTIN for a tax invoice" field is free text typed by a customer in a hurry. Validate it before the order is placed; the Shopify version of this is in GST verification on Shopify.
• Before the first invoice. For customers created long ago or imported in bulk, verify the GSTIN the first time an invoice is raised against it.
• Periodic re-check. Registrations are cancelled and suspended after onboarding. A monthly or quarterly batch over active customers catches the ones that changed. For large lists, the bulk verification route is built for this.

If you build or buy invoicing software, GST checks inside invoicing software covers the same hooks from the product side.

How to check: format first, then the register

Split the check into two stages, because they answer different questions and cost different amounts.

Stage one runs on the client, for free. Normalise the input (trim, uppercase, strip spaces), test it against the GSTIN pattern, and compute the check digit. That catches most typos instantly and never leaves the browser. GST number validation in forms has working code for React, Django, Laravel and plain JavaScript.

Stage two asks the register. A well-formed GSTIN can still be unissued, cancelled or someone else's. A live lookup returns the registration status and legal name, so you can confirm the GSTIN is Active and that the legal name matches the company you think you are billing. Use the response to fill the legal name and principal place of business in your customer record rather than having someone type them. The legal name versus trade name distinction matters here: the invoice should carry the legal name.

The flow, in outline:

on customer GSTIN entered:
    gstin = normalise(input)
    if not matches_pattern(gstin) or not checksum_ok(gstin):
        show "Check the GSTIN - it is not a valid format"   # no API call, no cost
        stop

    info = GET /api/get-taxpayer-info/{gstin}   (X-API-Key header)

    if info.taxpayer_data.status_code == 0:
        block save; show "No GST registration found for this number"   # not charged
    elif info.taxpayer_data.status != "Active":
        block save; show status and date to the user
    else:
        prefill legal name (taxpayer_data.name) and registered address (taxpayer_data.pradr)
        ask the user to confirm the legal name is their customer
        store gstin, status, verified_at on the customer record

On our API that lookup is one GET /api/get-taxpayer-info/{gstin} call with an X-API-Key header, returning legal and trade name, status and status dates, jurisdiction, places of business, e-invoicing status and GSTR filing history together. A GSTIN that fails format or check-digit validation is not charged; a successful lookup is ₹0.50, or ₹0.40 once a single purchase crosses 2,500 credits. The Python client is in GST verification API in Python, and the endpoint reference is in the docs.

Frequently asked questions