The GSTIN passes checksum. Is it the right supplier?

Both of these strings pass

Look at the two GSTINs in the figure. They are synthetic examples, not taxpayer records or numbers you should use for filing. Both pass the shipped format and mod-36 checksum checks. They are not the same string.

That is the limit I want you to understand before treating a green checksum result as supplier verification. The calculation tests the relationship between the characters. It does not consult the original invoice or the taxpayer register.

If a source prints A and a reader produces B, the checksum alone cannot tell the reader it chose the wrong identity. That is not a reason to remove the check. It is a reason to avoid claiming the check answers a different question.

The GSTIN validation guide explains why checksum is better than a length or shape check. This page adds the counterparty boundary: mathematical validity is not independent identity evidence.

First compare with the source

Put the extracted GSTIN beside the full source page. Locate its party label. A correctly read buyer GSTIN assigned to the seller is still the wrong counterparty field, even if every character passes checksum.

Compare all characters, not just the state prefix or the familiar PAN segment. Small differences near the end can matter. In the synthetic example, the entity character and check character differ while much of the identifier looks identical.

A clean digital text token can make this comparison easier. A blurry scan can make it genuinely uncertain. In the uncertain case, request a clearer source or appropriate supplier confirmation rather than allowing the passing checksum to close the review.

The better-source guide is useful when the label or character is obscured. More agreement between readers using the same damaged pixels is not necessarily independent evidence of correctness.

Keep seller and buyer roles separate. An invoice can carry several registrations in a footer, a branch list or bill-to/ship-to blocks. The first valid GSTIN found on the page is not automatically the seller's.

Then compare with the approved supplier record

An approved vendor master gives you another reference. Check the legal supplier and relevant registration, not merely a similar name. The PAN and vendor-master guide explains why trading names and registrations need disciplined mapping.

A mismatch is a question to resolve. The source might be misread. The supplier might have billed from a different relevant registration. Or the master might be outdated. Automatically overwriting the source with the master conceals which of those happened.

Use the PO and supplier onboarding trail to establish the intended counterparty. For a multi-plant transaction, the bill-to/ship-to review may be needed as well. A familiar address does not settle the legal registration.

If the supplier confirms a correction, retain that response and the corrected document where appropriate. A console edit corrects your record; it does not itself correct the supplier's original invoice or portal filing.

Do not make one invoice's resolved mismatch a universal alias without review. A similar vendor name can hide different entities. Master changes can affect future recovery decisions, so they need their own authorised control.

The portal answers another question

Use the official GST portal when you need taxpayer information or status. Match the returned details to the intended supplier and retain the date of the check under your process.

A registration lookup and an invoice comparison are complementary. The portal might show that a number corresponds to a taxpayer; it does not prove that this invoice printed that number or that you ordered from that taxpayer.

Likewise, the source printing a GSTIN does not establish that its registration is active or that every statutory ITC condition is met. The cancelled/inactive registration article addresses the status check separately.

Do not collapse those checks into a badge saying “GST verified.” A reviewer should know which question was asked, what evidence was used and what remains unresolved.

A plausible repair must be able to abstain

When a raw read fails checksum, changing a lookalike character can produce a valid neighbour. Sometimes more than one equally plausible neighbour validates. Choosing the first one merely because it appears first in a list can substitute the wrong identity.

EntryLedger now abstains on ambiguous best-cost GSTIN repairs rather than choosing the first valid candidate. The unresolved raw reading and audit record remain available for review. Unique repairs and already-valid strings have different behaviour; this safeguard is not a claim that every valid-but-wrong value is automatically caught.

Nor is an exact valid string silently replaced simply because another supplier identity seems more likely. That is the distinction between repairing an invalid transcription under bounded rules and overriding a checksum-valid counterparty.

The accuracy contract still requires the validation gate or explicit human confirmation before book-ready preparation. The checksum's limit does not weaken that gate; it tells the reviewer why source and identity checks remain important.

Some source-bound checksum-disqualified digital PDFs go directly to review without a model re-read. That narrower route is not applied to these passing synthetic strings merely because they differ. Do not generalise a disqualification rule into a full identity verifier.

Before approving a suspiciously familiar GSTIN, compare the source label and the approved supplier record. Keep the passing checksum as one piece of evidence, not the answer to who sold you the goods.