Bulk GSTIN Verification: Spreadsheet or API?

Here is the short answer, before the argument. If you have a few hundred GSTINs, you need to check them once, and one person owns the task, open a spreadsheet and work through the GST portal. It will take an afternoon or two, it will cost nothing, and anyone telling you to integrate an API for that is selling you something. The decision flips when either the list runs into the thousands or the check has to repeat on a schedule — because the manual process does not slow down gracefully as it grows. It breaks, in five specific ways, and all five of them are invisible until an auditor or a reconciliation finds them.

Where the line actually sits

Most comparisons of this kind treat record count as the only variable. It is not, which is why teams with 400 vendors buy integrations they do not need while teams with 4,000 keep muddling through a workbook. Three variables move together:

• Volume. A person sustains something like 60 to 100 careful portal lookups an hour before accuracy slides. Do that arithmetic against your own list first.
• Frequency. A one-time pass over 3,000 records is a week of someone's life and then it is done. The same 3,000 checked quarterly is a week of someone's life forever — and it is the second one that justifies automation.
• Consequence. A stale GSTIN on a small vendor is an annoyance. The same error on a supplier carrying a material share of your input tax credit is a different category of problem, covered in our post on vendor GST verification and your input tax credit.

A rule of thumb: multiply records by checks-per-year. Under about a thousand lookups a year, manual is defensible. Between one and ten thousand, a spreadsheet with an add-in or a script is usually the sweet spot. Above that you are running a process, and processes want infrastructure rather than heroics.

The five ways the manual process fails

These are not hypothetical. They are what turns up when a manually maintained vendor master is checked in bulk for the first time.

Four of the five are not fixed by working harder or hiring a second person. They are structural properties of doing the job by hand.

Manual, spreadsheet, API: the honest comparison

Three approaches are genuinely in use, and each is the correct choice for some team. The differences that matter are not features — they are setup effort, cost shape, freshness, auditability, and, most importantly, how each one fails.

The failure-mode row is the one worth sitting with. Manual and spreadsheet approaches both fail quietly, so the first signal you get is a reconciliation gap or an audit question. An integration fails loudly — a job errors, a rate limit trips, a queue backs up — and loud failures get fixed. That difference is usually worth more than the time saved.

Clean the list before you verify it

This is the highest-return part of the exercise. Dirty input wastes every subsequent call — you pay to look up a string that was never going to match, then spend longer interpreting the failure than the lookup cost. Do all of this before the first call goes out:

• Strip whitespace, including the invisible kind. Trailing spaces, non-breaking spaces pasted from a web page, the stray tab from a CSV. The commonest cause of "the number is right but it will not verify".
• Force uppercase and remove separators. GSTINs are uppercase alphanumerics. Strip hyphens, readability spaces, and the leading apostrophe a spreadsheet inserts to force text formatting.
• Dedupe on the normalised string, not the vendor name. The same GSTIN routinely appears under three spellings of one company. Deduplicating on name leaves them in; deduplicating on the cleaned 15-character value removes them.
• Group by PAN before panicking about duplicates. Characters 3 to 12 are the holder's PAN, and a company registered in several states legitimately holds several GSTINs sharing one. Those are not duplicates — they are one entity, and your master should link them.
• Run the offline checksum first. The fifteenth character is a check digit computed from the first fourteen, so malformed rows can be rejected locally, instantly, for free — the algorithm is in GSTIN verification versus format validation. Filter first and you only pay for rows that could be real.

On a master maintained by hand for a few years, this pass typically removes a noticeable slice of rows before a single lookup happens. If your GSTINs arrived by someone reading them off scanned invoices, fix it upstream too — that is a document extraction problem, and cleaning it at the source stops you re-cleaning the same errors every quarter.

Setting a cadence by risk tier, not by calendar

The instinct after a first cleanup is to declare that everything gets re-verified monthly. Do not. Monthly re-verification of an entire vendor master produces a large recurring cost and a report nobody reads, and within two quarters it will be quietly switched off. Tier instead: the right cadence is a function of what a stale answer would cost you, not of how tidy a monthly schedule looks.

Two things fall out of this. The volume you actually pay to verify each month is far smaller than your total vendor count, which changes the cost conversation. And the dormant tier is free money — every record you deactivate is one you never verify again, and most inherited masters are full of them.

In practice the event triggers in the right-hand column matter more than the cadence. A scheduled check tells you about a problem on the first of the month. A trigger on "large payment about to be released" tells you while you can still do something, which is the only moment the information has leverage. If you need return-filing history as well as status, that is a slightly different call — see checking GST return filing status programmatically.

Presenting results so procurement actually acts

A run that produces a 3,000-row file with a status column has not finished the job. It has moved the job to somebody with less context and less time than you. Three rules separate a file that gets acted on from one that gets filed.

Sort by exposure, not alphabetically

Nobody reads to row 800. Put the largest spend and the worst status at the top and the person opening the file sees the five rows that matter before they lose interest. An alphabetical list buries a cancelled critical supplier between two dormant ones.

Three buckets, not six statuses

Collapse the raw result into an action, because "status: suspended" is information and "hold the next payment" is an instruction. Act now (cancelled or suspended, or a name mismatch on a vendor you are about to pay), Ask (filing gap, or a legal name that differs in a way that might just be a group entity), Fine (active, name matches, filings current). Everyone can hold three buckets in their head.

Every row carries an as-of date and an owner

Two columns doing most of the work. "Verified as of 14 Oct" is a fact with a shelf life, which is what a verification result actually is. An owner column turns a report into assignments. Without them you have a document; with them you have a worklist.

How to price this against your own record count

No numbers here, because verification pricing changes and a stale figure in an evergreen post is worse than no figure. What is stable is the shape of each cost, and you can price your own list against these in ten minutes.

• Manual is labour cost. Records ÷ realistic lookups per hour × fully loaded hourly cost × checks per year. Use a realistic rate, not a heroic one, and add the errors you will not catch.
• Add-in and tool pricing is usually seat-based or bundled. That makes it insensitive to volume — good value if you verify a lot, poor if you verify occasionally. Check whether seat count or a row cap is the real constraint.
• API pricing is typically per-call and tiered. The unit rate falls as volume rises, so the meaningful number is your annual call count after tiering and deduplication, not your headline vendor count. Ask specifically whether failed or non-existent lookups are billable — on a dirty list that is a real line item.

Then compare like for like. A structured walkthrough of what to ask providers is in our GSTIN API pricing comparison, and the discipline you would apply to any recurring tool spend applies here too — the questions in our SaaS subscription audit piece work fine on a verification contract.

One point on sourcing. GST registration data is administered by the Goods and Services Tax Network under the framework set by the CBIC, and every provider is ultimately surfacing that same data. The differentiators are throughput, whether there is a real bulk endpoint rather than a loop over a single-record one, how non-existent numbers are billed, and what the response contains. Our own GSTIN API is built around a bulk job endpoint for exactly this case.

Common questions

Can I verify GSTINs in bulk in Excel? Yes, with a macro or an add-in that calls a verification service row by row and writes results back. It is a reasonable middle option for low thousands of records checked occasionally. The caveats are that it has no owner, no tests and no error handling by default, and that a workbook is a poor system of record for something an auditor may ask about later.

How many GSTINs can one person check manually in a day? Somewhere around 300 to 600 with reasonable accuracy, and accuracy falls off well before stamina does. The practical limit is not typing speed but attention: transposition errors and row-misalignment rise sharply after the first couple of hours. Multiply your own list by that rate before deciding the manual route is free.

How often should a vendor master be re-verified? Not uniformly. Tier by exposure: monthly for critical vendors and before large payments, quarterly for regular active vendors, on-use for occasional ones, and deactivate dormant records rather than verifying them forever. A single monthly sweep over everything costs more and gets abandoned faster than a tiered schedule that someone can defend.

What should I clean before running a bulk check? Strip leading and trailing whitespace and non-breaking spaces, force uppercase, remove hyphens and the spreadsheet apostrophe, deduplicate on the cleaned 15-character string rather than on vendor name, group registrations that share a PAN as one entity, and run the offline checksum to drop malformed rows locally. Each dirty row you remove is a call you do not pay for.

Where does the underlying data come from? GST registration data is administered by the Goods and Services Tax Network under the rules framed by the CBIC. Verification tools surface that registration data; they do not create it. Because the rules and the portal both change, confirm current requirements against official GSTN and CBIC sources rather than relying on any third-party summary, including this one.