A vendor master data governance audit tests three things independently of any specific invoice or payment: whether duplicate vendor records exist in the master — the same legal entity recorded under two or more vendor codes, often with minor variations in name, address, or bank account — whether vendor records that have had no transaction activity for an extended period remain active and payable rather than being deactivated, and whether the approval trail for creating a new vendor or changing an existing vendor's bank account details shows independent verification rather than a single person's unilateral entry.
Duplicate vendor detection
- Run a fuzzy match on vendor name, address, PAN, and GSTIN across the full vendor master, not an exact-string match alone — duplicates are usually created through minor spelling variations, abbreviations, or a missing suffix, not identical re-entry.
- Cross-check bank account numbers across vendor codes — two vendor codes resolving to the same bank account is a stronger duplicate signal than a name match alone and is harder to explain as coincidence.
- Where a duplicate is confirmed, check whether payments were split across the duplicate codes in a way that kept each individual payment below an approval threshold that would have applied to the combined amount.
Stale records and the approval trail
| Check | Evidence | What it catches |
|---|---|---|
| Dormant but active vendor records | Vendor master status flag against last transaction date | Records left payable long after the business relationship ended, a common entry point for fictitious payments |
| New vendor creation approval | Vendor onboarding workflow log, approver identity | Vendor created and immediately paid by the same person with no independent review |
| Bank detail change approval | Change log on vendor master with before/after values and approver | Bank account changed shortly before a large payment, a classic vendor-impersonation fraud pattern |
| Segregation between master maintenance and payment approval | User role mapping in the ERP | The same user able to both create/edit a vendor and approve payment to that vendor |
A bank account change on a vendor master record immediately followed by a payment to that vendor, with no independent confirmation of the change, is one of the most common vectors for payment diversion fraud. This pair of events — change, then payment — is worth a specific full-population test rather than relying on sample-based purchase testing to surface it.
How we think about this
Fuzzy-matching names and cross-checking bank accounts across thousands of vendor records is exactly the kind of exhaustive, pattern-matching work that does not get smaller or slower as the vendor master grows, if it is run with the right tooling. Deciding whether a flagged pair of records is a genuine duplicate, two related but distinct entities, or an innocent coincidence is where the auditor's judgement is needed.
This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.
Related resources
- Purchase & AP auditWhy duplicate vendor payments go undetected until someone looks for themA duplicate payment doesn't announce itself. Nothing in a normal accounts payable process is actually built to notice one.
- Purchase & AP auditVendor reconciliation in statutory auditHow to select vendors for confirmation, the seven categories every difference falls into, how to handle non-responses, and what an unconfirmed balance is worth.
- Purchase & AP auditDuplicate invoice detection during auditWhy exact matching finds almost nothing, the six match rules that do work, and how to tell a duplicate booking from a duplicate payment.
- Internal audit & IFCTesting segregation of duties: a practical approachThe classic SoD conflicts, how to test for them in a small finance team where perfect separation is not realistic, and how to document the compensating controls that stand in.
Free tools, no signup
Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.