A duplicate GSTIN check on its own does not catch every case of the same vendor sitting twice in a vendor master. Where vendor creation happens at the plant or branch level rather than through a central master, the duplicate often shows up as a different PAN-GSTIN combination for the same entity, not a repeated GSTIN. Each of those records creates a live second payment path and fragments the purchase register the GST portal cannot cleanly match against a single GSTIN-level GSTR-2B.
When we ran VCR-003 (duplicate PAN plus GSTIN check) as part of a vendor master diagnostic at a mid-market company with over 5,000 active vendor records, 772 records came back flagged. Across four vendor master diagnostics where this check has run, the flagged count ranged from 12 to 772, concentrated wherever vendor creation happens at the site or business-unit level instead of through one central master. The company at 772 scored 90 out of 100 on the overall diagnostic. The flagged records did not move that number.
Why a Single-Identifier Check Misses This
A duplicate GSTIN check compares one field across vendor records. It catches the case where two vendor IDs carry an identical GSTIN value. It does not catch the case where a vendor entity was re-entered with a data entry error on the GSTIN field, a different PAN attached, or both fields differing slightly from the original record while still tracing to the same legal entity. That second pattern requires comparing PAN and GSTIN together, not one field in isolation.
Most ERP duplicate-vendor logic was not built to make that comparison. In SAP, the GSTIN sits in field LFA1-STCD3, which standard duplicate-vendor checks at creation do not reference. The system checks vendor name and vendor code, not tax identifier fields, and checks them independently rather than together. A vendor record entered with a matching PAN but a mistyped GSTIN passes the same way a vendor with a matching GSTIN but a different PAN would. The first article in this series covered the single-identifier version of this problem in detail; see Duplicate GSTINs in Your Vendor Master: How They Cause Duplicate Payments. For the missing and invalid GSTIN pattern this check is often run alongside, see GSTIN Validation in Your Vendor Master: What Indian Diagnostics Actually Find. This check extends the single-identifier finding to the combined case a GSTIN-only comparison leaves open.
How Multi-Source Vendor Entry Creates the Pattern
The 772-record concentration traced back almost entirely to multi-source vendor creation. Vendor codes in that master carried prefixes tied to different origin systems, plant-level entry, branch-level entry, and at least one historical migration batch, each maintaining its own vendor records without checking against a shared master before creating a new one. A supplier onboarded once at the corporate level and again at a plant, months or years apart, ends up as two records that share a legal identity but not an identical field set.
This is a structural consequence of how the ERP is used, not a one-off data entry mistake. For the same reason vendor master data decays after go-live rather than staying clean, see ERP Data Quality in India: Why the Numbers Your Finance Team Trusts Are Already Wrong. Wherever more than one business unit or system can create a vendor record independently, the same entity accumulates variants over time, and PAN plus GSTIN divergence is one of the clearest markers that accumulation has already happened.
What Duplicate PAN and GSTIN Actually Costs
An invoice already posted against one vendor ID can be re-entered against the other, producing a duplicate payment that neither record shows as an error on its own.
GSTR-2B is generated at the GSTIN level on the GST portal, not at the vendor-ID level inside an ERP. When one entity’s purchase history splits across two vendor IDs, the ERP-side purchase register fragments in a way the portal-side GSTR-2B does not. Automated 2B matching either fails outright or produces mismatches that require manual tracing back to the correct vendor. Where the same invoice posts under both IDs, the fragmented register can push both entries into the GSTR-3B claim, and the same ITC gets claimed twice against a single tax invoice. As typically interpreted, that exposure sits under Section 50, carrying interest on the excess credit claimed, not under Rule 37A, which governs a supplier’s failure to file GSTR-3B after reporting an invoice in GSTR-1 and has no bearing on a buyer’s own duplicate vendor records.
Splitting one vendor’s payment history across two IDs also corrupts age-wise AP tracking. A payment posted against ID-2 does not offset an invoice sitting against ID-1, so the invoice can appear unpaid past 180 days even though the vendor was paid. That is the same Rule 37 mechanism covered in the duplicate GSTIN article referenced above; duplicate PAN plus GSTIN records compound it the same way. It also disrupts TDS threshold tracking under sections such as 194Q and 206C, producing Form 26AS and AIS mismatches that surface after the return has already been filed.
None of these costs are visible from inside either vendor record on its own. They surface at reconciliation, at TDS return filing, or at audit, by which point the duplicate has usually been in the master for months.
If you want to know how many duplicate PAN and GSTIN records sit in your vendor master and which ones carry live reconciliation exposure, the IQSS Diagnostic runs VCR-003 alongside 12 other vendor master checks and produces a prioritised remediation list within five working days.
Key observations
- A duplicate GSTIN check alone misses vendor entities re-entered under a different PAN-GSTIN combination, a pattern that requires comparing both fields together, not one field in isolation.
- At a mid-market company with over 5,000 active vendor records, VCR-003 flagged 772 duplicate PAN plus GSTIN records. Across four diagnostics, the flagged count ranged from 12 to 772, concentrated wherever vendor creation happens outside a single central master.
- The compliance exposure runs through GSTR-2B reconciliation breakdown and double ITC claims under Section 50, plus a Rule 37 mis-trigger risk from corrupted age-wise AP tracking. Rule 37A does not apply, since it governs supplier non-filing of GSTR-3B, not a buyer’s own duplicate vendor records.
- Splitting one vendor’s history across two IDs also disrupts TDS threshold tracking under sections such as 194Q and 206C, producing Form 26AS and AIS mismatches after the return has already been filed.
- Multi-source vendor creation, plant-level, branch-level, or from a historical migration batch, is the structural cause. The fix starts with comparing PAN and GSTIN together across the full vendor base, not adding another single-field check.