GSTIN Validation vs Verification: Two Different Questions

Validation and verification are used interchangeably in almost every GST product listing on the internet. They are not the same thing, and the gap between them is where fake invoices get paid.

Validation asks whether a number could exist. Verification asks whether it does — today, and whose name is on it. One is arithmetic on a string. The other is a lookup against the government register. Neither replaces the other, and knowing which one a given tool performs is the difference between a control and the appearance of one.

Two questions, not one

Put the two questions side by side and the distinction stops being subtle:

	Validation	Verification
Question asked	Could this number exist?	Does it exist, right now, and whose is it?
Where the answer comes from	The string itself	The government register
Network call	None	Required
Cost	Zero, unlimited	Per lookup
Latency	Microseconds	Hundreds of milliseconds
Answer shape	A boolean	A record: name, status, jurisdiction, filings
Shelf life	Permanent — arithmetic does not change	A snapshot; status changes without notice

The last row is the one people miss. A validation result is true forever, because the arithmetic never changes. A verification result is true as of the moment you asked, and a registration cancelled next Tuesday makes it stale without anybody sending you a note.

What validation actually proves

Validation is two checks. First, does the string match the GSTIN pattern:

^[0-9]{2}[A-Z]{5}[0-9]{4}[A-Z][1-9A-Z]Z[0-9A-Z]$

Two digits of state code, ten characters of embedded PAN, an entity code, a literal Z, and a final check character. Every position is picked apart in the GSTIN format breakdown.

Second, does the fifteenth character agree with the first fourteen? It is a modulus-36 Luhn variant — the credit-card algorithm widened to cover letters as well as digits. The checksum algorithm article derives it in full and, more usefully, measures what it is worth by exhaustive search:

• It catches every single-character typo — 0 of 490 substitutions went undetected.
• It catches every adjacent transposition except swapping 0 and Z, a pair that is essentially unreachable in a well-formed GSTIN.
• A random string that already matches the format pattern has roughly a 2.8% chance of also passing the checksum — so the check digit makes a fabricated number about 36 times less likely to slip through.

That is a genuinely strong guarantee against the most common failure mode in accounts payable: somebody fat-fingered a character while keying an invoice. Validation catches that for free, in microseconds, across a million rows, with no network call. Do not dismiss it — it is simply answering a narrower question than people assume.

The four things validation cannot see

These are not weaknesses in the algorithm. They are limits of arithmetic. No offline check, in any language, written by anyone, can see any of the following.

What is actually true	Why validation says "valid"
The registration was cancelled or suspended	The check digit is computed from characters 1–14, and those do not change when a business deregisters. A cancelled GSTIN keeps a correct checksum forever. An invoice from a cancelled GSTIN does not support an input tax credit claim — see what suspended and cancelled actually mean
The number was never issued	00AAACR5055K1ZN has a correct check digit. 00 is not a state code the government issues, so nothing was ever registered under it. The arithmetic has no opinion about which state codes are real
It belongs to somebody else	The GSTIN may be entirely real, active and well-formed — and belong to a different company than the one printing it on the invoice. Only the register carries the name
It was fabricated deliberately	The algorithm is public. Anyone can generate a checksum-correct GSTIN in twenty lines of code, or a spreadsheet formula

The third row is the one that survives a careless verification too. Checking status without checking the name catches an invented number and a cancelled one, but not a real active GSTIN borrowed from an unrelated business. Checking whether a GST number is fake walks through that gap step by step.

What this costs in practice

The failure is rarely dramatic. Here is the ordinary version.

A supplier is onboarded eighteen months ago. Their GSTIN is checked at the time, it looks fine, it goes into the vendor master. Last quarter their registration is cancelled — for non-filing, or a restructure, or because the business wound up. Nobody tells you. Their invoices keep arriving, carrying the same GSTIN, and that GSTIN still passes every offline check you can run against it, because the first fourteen characters did not change and neither did the arithmetic over them.

You claim input tax credit against those invoices. The mismatch surfaces later, in GSTR-2B reconciliation, because the supplier's invoices are not appearing there. The credit is reversed, with interest. The supplier-compliance conditions that govern this are covered in the input tax credit rules.

Nothing about the number itself ever looked wrong. There was no typo to catch, no malformed string, no failing checksum. The information needed to prevent it existed only in the register, and nobody asked.

What verification returns

Verification is a lookup against the government register, and it returns a record rather than a boolean:

• Legal name and trade name — the fields that let you compare the name on the invoice with the name on the register.
• Registration status — Active, Cancelled or Suspended.
• Taxpayer type — Regular, Composition, and the rest.
• Constitution of business and date of registration.
• Principal and additional places of business, and the jurisdiction the registration sits under.
• E-invoicing applicability and return filing history.

Name matching is the step manual processes skip, because it requires reading the response rather than glancing at a green Active badge. It is also the only check that catches a real, active GSTIN printed on somebody else's invoice.

A lookup that returns nothing is its own signal, though not always the one people assume — the reasons a genuine-looking GSTIN comes back empty are covered in "no record found" on the GST portal. For the mechanics of calling a register lookup programmatically, see what a GSTIN verification API is or the API documentation.

The two-stage funnel

The correct posture is not choosing between the two. It is ordering them.

1. Validate offline, on everything. It is free, so there is no threshold to apply. It removes typos before they cost anything, and a malformed number should never reach a billed API call.
2. Verify against the register for what survives and matters. A new supplier. An invoice about to be paid. A GSTIN going onto a return.

Stage one exists to make stage two cheap. It is not a substitute for it. In code the shape is simply an early return:

from gstin_api import GstinApiClient, is_valid_gstin

client = GstinApiClient(api_key="YOUR_API_KEY")


def check(gstin: str):
    # Stage 1 — free, offline, microseconds. Never spend a call on a typo.
    if not is_valid_gstin(gstin):
        return {"ok": False, "reason": "malformed"}

    # Stage 2 — the register. Only reached by well-formed candidates.
    record = client.lookup(gstin)

    return {"ok": record.status == "Active", "name": record.legal_name}

The Python package is pip install gstin-toolkit and the Node equivalent is npm install @dlminds/gstin-api, exposing isValidGstin alongside client.lookup. Both are MIT-licensed and dependency-free, so the validation half costs nothing to adopt even if you verify elsewhere. If you only need an answer for one number, the GSTIN validator runs entirely in your browser and the GST number search hits the register.

Ordering the stages this way is also the single largest lever on lookup spend, which is the subject of reducing GST verification API costs.

Verify once, or keep checking?

A verification result is a snapshot, not a permanent fact. Registration status changes — cancellations, suspensions, reinstatements — and nothing in the process notifies the counterparties who depend on it. A GSTIN verified at onboarding tells you what was true at onboarding.

So the practical cadence has three points:

When	Why
At onboarding	Establishes that the supplier exists, is active, and that the name matches the paperwork before anything is committed
Before a high-value payment	The point of maximum exposure, and the cheapest possible moment to spend one lookup
On a schedule, across the active list	Catches the cancellation nobody told you about. Monthly is a common compromise; more often for high-risk or high-value counterparties

The scheduled sweep is the one that would have caught the scenario above, and it is straightforward to automate — automated daily vendor GSTIN monitoring covers the mechanics, and vendor GST verification in accounts payable covers where it belongs in the payment run.

If you want to try the register side of this, 20 free verification credits are enough to run a handful of suppliers through and see which fields you actually end up reading.

Frequently asked questions

What is the difference between GST validation and GST verification?

Validation is arithmetic performed on the string itself: does it match the fifteen-character GSTIN pattern, and does its check digit agree with the first fourteen characters? Verification is a lookup against the government register: does this GSTIN exist, is it active today, and whose name is on it? Validation is offline, free and instant. Verification requires a network call and returns facts no algorithm can compute.

Can a GSTIN be valid but not verified?

Routinely. A cancelled registration keeps a perfectly correct check digit forever, because the check digit is computed from characters 1-14 and those do not change when a business deregisters. Fabricated numbers pass too — the algorithm is public, so a checksum-correct GSTIN takes about twenty lines of code to generate.

Is a "GST validation API" the same as a "GST verification API"?

Not necessarily, and the marketing language is genuinely interchangeable across vendors. Some products sold as validation or verification only run the checksum, which you could do offline for nothing. Check the documented response fields: if it does not return legal name and registration status, it is not talking to the register.

Do I need to verify every GSTIN, or is validation enough?

Validate everything, because it costs nothing and removes typos before they reach a billed call. Verify what survives and actually matters: a new supplier, an invoice about to be paid, a GSTIN going onto a return. Stage one exists to make stage two cheap; it is not a substitute for it.

How often should I re-verify a supplier GSTIN?

Verification is a snapshot, not a permanent fact — registration status changes without anybody telling you. Verify at onboarding, re-verify before high-value payments, and re-check the active supplier list on a schedule. Monthly is a common compromise; more often for high-risk or high-value counterparties.

What does a verification lookup actually return?

Legal name, trade name, registration status (Active, Cancelled or Suspended), taxpayer type, constitution of business, date of registration, principal and additional places of business, jurisdiction, e-invoicing applicability and return filing history. The legal name is the field that lets you compare the invoice in front of you with the register.