Automated Daily Vendor GSTIN Monitoring

Most procurement teams verify a vendor once — at onboarding — and never again. That is the right first control and an insufficient last one, because the thing you checked is a property that changes. A supplier onboarded in March with an Active registration can be cancelled in September, and nothing in a typical purchase-to-pay flow will tell you. You find out when input tax credit is denied.

Continuous monitoring closes that gap, and the design that works is not "verify everything every day". It is a rotating job over the master, an unconditional check at the decision points, and an exception rule set narrow enough that the alerts stay credible.

Why onboarding checks are not enough

The exposure is specific and quantifiable. If a supplier's registration is cancelled and they keep invoicing you with GST charged, several things follow at once: your input tax credit on those invoices is at risk, your GSTR-2B will not reconcile the way you expect, and the longer it runs the more invoices are affected before anyone notices. The mechanics are in input tax credit rules and GSTR-2B and the Invoice Management System.

Time to detection is the whole game. Discovering it in the same week costs you a conversation. Discovering it at the annual reconciliation costs you a quarter of disputed credit and a supplier who may no longer be answering the phone.

What actually changes, and how fast

Only the first row justifies anything approaching daily attention, which is exactly why a rotating design beats a brute-force one: you get days-level detection on the field that matters without paying for daily checks on four fields that do not move.

Designing the daily job

1. Take the vendor master as the source of truth, with a stored last_verified_at and last-known status per GSTIN.
2. Select today's slice. Everything whose last_verified_at is older than the tier's window: high-spend or previously flagged vendors on a short window, the long tail on a monthly one. This naturally spreads the master across the cycle.
3. Add the unconditional set — vendors with an invoice entering a payment run today, vendors onboarded today, and anything flagged since the last run. These are checked regardless of when they were last seen.
4. Deduplicate and format-filter before spending anything, as in bulk verification throughput.
5. Verify through a queue with worker-side rate limiting, retries with backoff, and idempotent writes keyed on GSTIN.
6. Diff against the stored record. Unchanged results update last_verified_at silently. Only differences continue.
7. Raise exceptions into a system with owners — not an email digest.
8. Schedule it off-peak, away from the 11th, 13th and 20th when the upstream systems are busiest.

The exception rules that matter

What daily monitoring costs

Verifying all 5,000 every single day instead would cost roughly ₹60,000 a month and improve detection by a couple of weeks at most — a poor trade, and the reason rotation is the default recommendation rather than a cost-saving compromise. The arithmetic behind these figures is in GST API pricing explained.

Rolling it out without stopping procurement

1. Run in shadow mode for two to four weeks. Log every exception, block nothing. You need to know your real exception rate before it gates a payment run, and it is almost always higher than expected on the first pass because the master has never been cleaned.
2. Fix the data first. The initial run surfaces years of accumulated mess — duplicates, typos, PANs in the GSTIN column, vendors who ceased trading. That cleanup is a one-off and is most of the first month's value.
3. Turn on the hard block last, and only for Cancelled. Everything else starts as a flag.
4. Give each exception type an owner before go-live. An alert with no owner is an alert that gets muted.
5. Review the rules after a quarter. Tighten what produced noise, and add rules for the incidents you actually saw rather than the ones you imagined.

The onboarding-time counterpart to this is in GST verification for vendor onboarding, and the payment-run integration in vendor verification in accounts payable.

Frequently asked questions