Vendor GST Verification and Your Input Tax Credit

Most finance teams treat the GSTIN column in the vendor master as reference data. Somebody typed it in when the vendor was set up, it has a GSTIN-shaped value in it, and nobody has looked at it since. That framing is the problem, because the GSTIN column is not reference data. It is a running financial exposure.

Why your credit depends on someone else

The structural feature of GST that catches people out is this: your entitlement to input tax credit is not settled by you paying the tax. It is conditional on your supplier having reported the supply, so that the invoice flows into the auto-drafted statement you reconcile against — your GSTR-2B. If the supplier does not report it, the credit is not there to take.

Read that again with a vendor master in mind. Every supplier who quietly stops filing is, from your side, a slow leak. You pay the invoice including tax. The credit never arrives. The gap surfaces weeks or months later during reconciliation, by which point the money has moved and your leverage over that vendor is whatever is left of the relationship.

The three checks that carry the weight

There are plenty of things you could verify. In practice three of them account for almost all of the value, and they are worth separating because they fail in different ways and on different timescales.

1. Legal name match

The registration carries the legal name of the entity it was issued to. Your vendor record carries whatever name someone typed. When those disagree, it is occasionally fraud and much more often a group structure nobody documented — you are paying one company and holding the GSTIN of its sibling. Either way, an invoice in the wrong entity's name is a reconciliation problem waiting to happen.

This check is cheap and it is the one people skip, because a GSTIN that "looks right" feels verified.

2. Registration status

Active, cancelled, suspended. A cancelled registration cannot validly charge you GST, and an invoice from one is not a basis for credit. Nothing about the number changes when the status does, so there is no way to notice from your side except by looking.

3. Filing history

The forward-looking one. A vendor with consistent recent filings is behaving normally. A vendor with a three-month gap is telling you something before it costs you anything — and that window is the only point where you have options, because you can hold a payment, ask a question, or shift volume to another supplier while the invoice is still unpaid.

The mechanics of getting these three fields out of a system are covered in our developer-facing post on GSTIN verification versus format validation. This post is about what to do with them.

Why onboarding-only verification fails

Consider an ordinary sequence with no bad actors in it at all:

Nobody in that story did anything unusual. The process failed because it recorded a point-in-time result as a permanent property.

Cleaning a vendor master you inherited

Before building any ongoing process, run the existing list once. This is almost always the highest-yield thing available, because the list has accumulated for years and has never been checked in bulk.

What a first pass typically surfaces: vendors whose registration is no longer active, duplicate records for the same PAN across different states that were never linked, names that do not match the registration, GSTINs that fail the format check outright because of a transcription error, and a tail of suppliers nobody has transacted with in years who should be deactivated regardless.

Doing that through a UI, one number at a time, is how the project dies at row 200. It wants to be a batch job: submit the list, let it process, get a file back. Our GSTIN API takes up to 10,000 numbers per job, processes them asynchronously and returns results as JSON or CSV — the bulk endpoints are documented here, and at ₹0.40–0.50 per verification the cost of checking a few thousand vendors is not what will stop you. The thing that stops most teams is that nobody owns it.

A verification process that survives contact with reality

The design constraint that matters: checks nobody acts on are worse than no checks, because they produce a report that gets filed and a false sense that the problem is handled. Every check below is paired with a decision.

The row that pays for the whole exercise is the fourth one. Everything else is hygiene; that one converts information into leverage, and only while the payment has not gone out.

Where to automate, and where not to

Automate the checking. It is mechanical, it is high volume, and a human doing it is a human doing it badly by row 50. The monthly sweep over active vendors should be a scheduled job that writes results back to the vendor record with a timestamp.

Do not automate the consequences, at least not at first. An automatic block on any vendor with a filing gap will, on day one, block a supplier your operations team cannot function without, and the process will be switched off by the end of the week. Flag, notify, and require a decision. Once the flags are trusted and the false-positive rate is known, tighten selectively — starting with new vendors, where there is no incumbency to fight.

Practically, this lands in whatever system already owns the vendor master. If that is an ERP, the check belongs in the vendor record's lifecycle rather than in a spreadsheet beside it — which is the kind of thing we build into CRM and ERP systems for clients, and the reason we built the verification layer as a product rather than rewriting it on every engagement.

Common questions

Can I lose input tax credit because of my supplier? Yes. That is the central point. Credit depends on the supply being reported by the supplier so it reaches your GSTR-2B, so a supplier who stops filing creates a shortfall on your side even though you paid in full. Your own advisor should walk you through how this applies to your filings.

How often should vendors be re-verified? Monthly for active vendors is a reasonable default, plus a fresh check before any unusually large payment. The right frequency is a function of exposure, not of the calendar — a vendor you pay ₹50,000 a year to does not need the same cadence as one you pay ₹5 crore.

What if a vendor's GSTIN is cancelled? Stop raising new purchase orders against that record and get finance and procurement in the same conversation before the next payment. Whether specific past invoices are affected is a question for your tax advisor; the operational point is that you should find out from your own process, not from a reconciliation three months later.

Is checking the GST portal manually good enough? For a handful of vendors, yes. It stops scaling at roughly the point where the checks need to be routine, which is also the point where they start being valuable. The break-even is lower than most teams assume — it is the recurring monthly sweep, not the one-off lookup, that is impossible by hand.

Does this replace GSTR-2B reconciliation? No, and it is not meant to. Reconciliation tells you what already went wrong. Verification tells you which vendors are likely to make it go wrong next month. They are different instruments and you want both.

How much does bulk verification cost? On GSTIN API, ₹0.40 per verification above 2,500 credits and ₹0.50 below it, with no charge for invalid or non-existent numbers. Current rates are on the pricing page. For a few thousand vendors that is a rounding error against a single lost credit.