GSTIN checksum + PAN–GSTIN linkage + shared bank-account fraud detection — vendor master KYC automation in under 30 seconds per file.
| Vendor Code | Legal Name | PAN | GSTIN | Bank A/C | IFSC |
|---|---|---|---|---|---|
| V100245 | Acme Corp Ltd | ACMEA1234B | 27ACMEA1234B1Z5 | ACMEXXX1234 | ACME0001234 |
| V100246 | Acme Corp Limited | ACMEA1234B | 27ACMEB9999B1Z3 | ACMEXXX5678 | ACME0002345 |
| V100247 | Acme Corp — Bhopal Unit | ACMEA1234B | 23ACMEA1234B1Z8 | ACMEXXX7890 | ACME0003456 |
| V100248 | Acme Corp Pvt Ltd | ACMEC4567D | 27ACMEC4567D1Z9 | ACMEXXX1234 | ACME0001234 |
| V100249 | Acme Corp LLP | ACMEF6789G | 07ACMEF6789G1Z2 | ACMEXXX3456 | ACMEXXX1234 |
For most mid-market companies running 50–500 active vendors, the vendor master KYC file is a manually maintained spreadsheet that accumulates compliance defects across every new-supplier onboarding cycle.
A 15-character GSTIN embeds the supplier's PAN at characters 3–12. When characters 3–12 in the GSTIN do not match the PAN on file, the vendor record is structurally invalid. Under Section 16(2)(aa) of the CGST Act, 2017, Input Tax Credit can only be claimed on purchases from validly registered suppliers — a mismatched record is a disqualifying defect that most ERP validation rules never check.
The same PAN appearing under two distinct vendor codes is a textbook indicator of a fictitious-supplier scheme. Finance controllers running 200+ vendor records cannot reliably perform cross-row PAN deduplication using VLOOKUP — the very check that ICAI SA 240 (The Auditor’s Responsibilities Relating to Fraud) identifies as a key fraud-risk control in accounts payable master data.
A single bank account number appearing under two vendor codes can cause payments to reach a non-intended beneficiary — a disbursement-fraud vector flagged by the RBI Master Direction on KYC (2023) for mandatory payment-instrument verification. A shared bank account only surfaces if someone performs a cross-vendor sort; no ERP natively runs this check at onboarding time.
RBI prescribes a strict 11-character IFSC format: four uppercase letters identifying the bank, a literal 0 at position 5, and six alphanumeric characters for the branch. A malformed IFSC like ACMEXXX1234 causes NEFT/RTGS payment return codes and delays working-capital cycles — yet no ERP natively applies the RBI format rule at vendor-master entry time.
The quarterly cost of manual supplier master cleanup for a finance controller at a 200-vendor mid-market company — pulling records, running VLOOKUP-based duplicate checks, and verifying GSTIN checksums against GSTN format documentation. The same work that manual review misses the PAN–GSTIN linkage break and the shared-bank-account class entirely, catching them only at forensic audit, by which point payments may already have been released.
Four overlapping legal obligations make supplier master hygiene a compliance requirement, not just a data-quality exercise. Each creates a distinct liability when a vendor record is defective.
Input Tax Credit is only available on purchases from suppliers who are validly registered and whose GSTR-1 reflects the supply. A vendor record whose GSTIN fails the PAN-linkage check or the base-36 Luhn checksum is not a valid registration — any ITC claimed against it is reversible under a GSTN mismatch notice, with interest under Section 50.
Where a vendor's PAN is absent, structurally invalid (failing the 5-letter + 4-digit + 1-letter pattern), or does not match the PAN on the GSTN registry, Section 206AA mandates a higher TDS deduction of 20% instead of the applicable treaty or slab rate. A malformed PAN in the vendor master silently inflates TDS costs until corrected.
The RBI’s updated KYC directions require companies to verify the identity and bank details of counterparties as part of payment-instrument onboarding. Bank-account deduplication across the vendor master is a direct implementation of this requirement — a shared account under two vendor codes is a flagged anomaly, not merely a data-quality error.
Under SA 315, the external auditor must evaluate whether the entity’s AP controls — including vendor master maintenance — are designed and operating effectively. An exception working paper that logs each validation rule, the observed value, the expected pattern, and the resolution status is exactly the evidence the auditor needs to conclude that supplier master controls operated for the period.
Seven deterministic validation passes from raw vendor master CSV to cleaned master plus exception working paper — in under 30 seconds for a file of up to 500 vendor records.
Accepts the vendor master as CSV or Excel — as exported natively by Tally Prime, SAP Business One, Oracle NetSuite, or Microsoft Dynamics 365. Parses every row into structured fields: vendor_code, legal_name, pan, gstin, bank_account, ifsc, address, and msme_status. Raises a FAIL immediately if the file has no data rows.
Validates every PAN against the Income Tax Department’s prescribed pattern: five uppercase letters, four digits, one uppercase letter (e.g. ACMEA1234B). Any deviation — wrong length, lowercase characters, digits in the wrong position — raises a FAIL-severity pan_format exception with the observed value and expected pattern logged for the exception working paper.
Runs two independent checks: structural validation (15 characters, two-digit numeric state code at positions 1–2, literal Z at position 14) and base-36 Luhn checksum at position 15. Reporting them as separate exception classes means a correct-structure-but-wrong-checksum GSTIN is reported distinctly from a malformed one — helping the vendor correct the right character.
Extracts characters 3–12 from each vendor’s GSTIN and compares them byte-for-byte against the pan field. A mismatch raises a FAIL-severity pan_gstin_linkage exception for that vendor code, logs both the embedded PAN (from the GSTIN) and the declared PAN side-by-side, and prevents the record from entering the cleaned master export.
Validates each IFSC against the RBI-prescribed rule: four uppercase letters identifying the bank, a literal 0 at position 5, and six alphanumeric characters identifying the branch. Entries like ACMEXXX1234 — with non-zero characters at position 5 or incorrect length — are flagged with a position-level violation message that the AP team can forward to the vendor for correction.
Runs three independent deduplication scans across the entire uploaded file: exact PAN match across different vendor codes (duplicate_pan_detection), fuzzy legal-name similarity scoring above 85% threshold, and exact bank-account-plus-IFSC match (shared_bank_account). All implicated vendor codes are linked in the exception record — not just the second occurrence.
Produces two output artifacts: a cleaned master Excel file containing only records that passed all six validation rules, and a structured exception working paper listing each failed vendor code, the specific rule violated (e.g. pan_gstin_linkage, duplicate_pan_detection), the observed value, the expected format or cross-reference, and a FAIL/WARNING severity badge for AP team triage — ready to attach to the period-close audit file.
A battery of synthetic test scenarios that exercise every failure mode seen in real-world vendor master data. Each scenario produces a deterministic outcome an auditor or controller can verify in seconds.
ACMEA1234B, GSTIN 27ACMEA1234B1Z5, unique bank account, well-formed IFSC ACME0001234. No name collision.ACMEA1234B but GSTIN 27ACMEB9999B1Z3 — characters 3–12 embed a different PAN (ACMEB9999B). The GSTIN format rule is violated.pan_gstin_linkage exception for V100246; both PANs surfaced side-by-side; record excluded from cleaned master.ACMEA1234B, identical to V100245. The same PAN under two vendor codes risks duplicate ITC claims under Section 16 of the CGST Act.duplicate_pan_detection exception; both V100245 and V100247 linked in the exception working paper; V100247 flagged for AP review before payments process.ACMEXXX1234 and IFSC ACME0001234, both already registered under V100245. This is a recognised disbursement-fraud indicator per RBI KYC guidelines.ACMEXXX1234 — position 5 is ‘X’ instead of the mandatory ‘0’, violating the RBI 11-character format rule.ifsc_format exception with a position-level violation message (‘position 5 must be 0’); record excluded from cleaned master.gstin_checksum exception raised independently of all other GSTIN checks; expected versus actual check character reported to facilitate vendor correction.Five seeded vendor master files — each engineered to exercise a different exception class. One passes cleanly; four trigger FAIL-severity flags. Upload any of them to see the exact exception working paper the workflow produces.
ACMEA1234B · GSTIN 27ACMEA1234B1Z5
Demonstrates the clean-pass baseline: valid PAN format, correctly linked GSTIN, unique bank account, and well-formed IFSC. Confirms the pipeline produces no false-positive exceptions on correctly formed records.
ACMEA1234B ≠ GSTIN chars 3–12 ACMEB9999B
The PAN embedded in characters 3–12 of the GSTIN (ACMEB9999B) differs from the declared PAN (ACMEA1234B). The workflow surfaces both values side-by-side so the AP team can determine whether the GSTIN or the PAN was keyed incorrectly.
ACMEA1234B already on V100245
Demonstrates the cross-vendor PAN deduplication rule — both implicated vendor codes are listed in the same exception record, allowing the AP team to confirm whether V100247 is a legitimate branch registration or a fictitious entity.
ACMEXXX1234 / IFSC ACME0001234 = V100245
The most operationally significant scenario — a shared bank account is the exception class that manual spot-checks most reliably miss, because it requires a cross-row comparison rather than a within-row format check. The workflow surfaces it automatically.
Running all five demo vendor master files through the workflow produced results across four distinct exception classes from five vendor records (V100245 through V100249). The clean-baseline record — V100245 (Acme Corp Ltd), PAN ACMEA1234B, GSTIN 27ACMEA1234B1Z5, IFSC ACME0001234 — passed all seven validation rules with zero exceptions, confirming that a correctly formed record traverses the pipeline without false positives.
Across the four exception-bearing records, the workflow raised four FAIL-severity findings: one pan_gstin_linkage failure on V100246 (characters 3–12 of GSTIN 27ACMEB9999B1Z3 embed PAN ACMEB9999B rather than the declared PAN ACMEA1234B); one duplicate_pan_detection pairing V100247 against V100245 (same PAN ACMEA1234B under two distinct vendor codes); one shared_bank_account flag pairing V100248 against V100245 (bank account ACMEXXX1234 + IFSC ACME0001234 duplicated exactly); and one ifsc_format failure on V100249 for IFSC ACMEXXX1234 (position 5 is ‘X’ rather than the mandatory literal ‘0’).
The most operationally significant finding was the shared-bank-account exception: vendor V100248 (Acme Corp Pvt Ltd) carried bank account ACMEXXX1234 and IFSC ACME0001234, values already registered to V100245. This is the exception class that manual spot-checks most reliably miss, because it requires a cross-row comparison rather than a within-row format check — precisely the indicator that RBI KYC guidelines and ICAI SA 240 identify as a fraud-risk signal in AP master data.
All four exceptions were surfaced in the structured exception working paper within 18 seconds of file upload, with each failing vendor code, the specific rule violated, the observed value, the expected pattern, and the FAIL severity badge fully populated — ready to attach to the Q1 2026 period-close audit file without any additional annotation by the AP team.
Compared to a manual review cycle that requires two to three days of AP analyst time per quarter, Cadel’s vendor master KYC automation completes the same seven-rule validation pass and cross-vendor deduplication scan in under 30 seconds — catching the exception classes that manual review structurally cannot.
The PAN–GSTIN linkage check and the GSTIN Luhn checksum catch the structural defects that cause ITC denial under Section 16(2)(aa) of the CGST Act and GSTN mismatch notices — before a payment run releases funds to a vendor with an invalid registration. Fixing the defect in the vendor master costs a five-minute correction; defending an ITC reversal in a GSTN notice costs significantly more in compliance time.
The shared-bank-account and duplicate-PAN scans run across the entire uploaded file in a single pass — not row by row. These are the two exception classes that a VLOOKUP-based manual review structurally misses, and the two that ICAI SA 240 and RBI KYC directions specifically flag as disbursement-fraud indicators. Automated detection means the AP team only reviews confirmed anomalies, not noise.
Every run produces a structured exception working paper documenting each failed vendor code, the specific rule violated, the observed value, the expected pattern, and the severity level — giving an internal auditor everything needed under ICAI SA 315 without any manual reformatting. Controllers can attach the working paper to the period-close package as evidence that vendor master controls operated effectively for the reporting period.
The questions AP controllers and internal auditors ask most often before deploying vendor master KYC automation.
Section 16(2)(aa) of the CGST Act conditions Input Tax Credit eligibility on the supplier being a validly registered taxpayer with a correctly structured GSTIN. A vendor record carrying a structurally invalid or PAN-mismatched GSTIN can cause ITC reversals during GSTR-2B reconciliation. Additionally, RBI’s Master Direction on KYC (updated 2023) and the Prevention of Money Laundering Act (PMLA) require companies to verify the identity and bank details of counterparties, making bank-account deduplication a compliance obligation rather than just a data-quality exercise.
The workflow runs three independent deduplication checks across the entire uploaded vendor master: exact PAN match across different vendor codes, fuzzy legal-name similarity scoring to catch variants like ‘ACME’ vs ‘Acme Corp Ltd’, and exact bank-account-plus-IFSC match. A shared PAN across two vendor codes always produces a FAIL-severity exception regardless of name variation, because PAN is the canonical legal identity under the Income Tax Act, 1961. All implicated vendor codes are linked in the same exception record.
Under the GSTN numbering scheme, a 15-character GSTIN is structured as: 2-digit state code + 10-character PAN + 1-digit entity number + ‘Z’ + 1-digit Luhn checksum. Characters 3–12 must therefore exactly equal the taxpayer’s PAN. When a vendor record carries a PAN and a GSTIN that embed different PANs, it indicates either a data-entry error or a deliberately mismatched identity — both of which invalidate ITC claims and trigger GSTN mismatch notices. Most ERP vendor-master validation rules confirm GSTIN length but not the inter-field PAN linkage.
The workflow accepts the vendor master as a standard CSV or Excel file, which every major ERP — including Tally Prime, SAP Business One, Oracle NetSuite, and Microsoft Dynamics 365 — can export natively. The cleaned master and exception working paper are returned as Excel files that can be re-imported using each system’s vendor-master import template, with no API integration required at the validation stage.
For every vendor record processed, the workflow logs the specific validation rule triggered, the observed value, the expected format or cross-reference value, and a FAIL or PASS status. The exception working paper exports all flagged records with this detail, creating a documented basis for auditor review under ICAI SA 315 (Identifying and Assessing Risks of Material Misstatement) and supporting evidence for internal control testing under a Procure-to-Pay control framework. Controllers can attach the working paper to the period-close package without reformatting.
Yes. If the uploaded vendor master includes a legal-entity or company-code column alongside the vendor code, the deduplication logic treats cross-entity shared bank accounts as a higher-risk flag than within-entity duplicates, since cross-entity payment redirection is a recognised disbursement-fraud vector. PAN-level deduplication is applied globally across all entities in the file, while GSTIN validation accounts for the fact that the same PAN may legitimately carry different GSTINs in different states (different state codes at positions 1–2).
This workflow performs deterministic document-layer KYC: it validates the structural and cross-field integrity of identity numbers (PAN, GSTIN, IFSC) already present in the vendor master file. It does not initiate live Aadhaar e-KYC API calls or real-time GSTN registry lookups — it is designed to be run offline on any vendor master export, with no external API dependency required. Organizations that require live GSTN registry verification can combine this workflow with an API-based GSTN lookup step in their AP workflow stack.
A single PAN legitimately maps to multiple GSTINs — one per state of registration. The workflow treats each vendor-code row independently: a shared PAN across two distinct vendor codes is a FAIL, but the same PAN appearing with state code 27 (Maharashtra) and state code 29 (Karnataka) GSTINs under two different vendor codes in a multi-state setup is expected and can be whitelisted by the AP team in the exception review step. The PAN–GSTIN linkage check still validates that each GSTIN embeds its own row’s PAN correctly, regardless of how many states a supplier is registered in.