When a vendor master check finds two or more vendor records sharing the same bank account number, it flags one of three scenarios: a data entry error, a legitimate subsidiary or branch relationship, or an insider fraud signal. The AP team cannot tell which scenario applies from the vendor master alone. Each scenario carries a different financial consequence, and the triage process is the same regardless of which ERP is in use.
VCR-005 scans every active vendor record for duplicate IFSC and account number combinations. A hit means at least two vendor codes in your master file route payments to the same bank account, and nothing in that output tells you why.
Finance teams running this check for the first time typically find a small number of hits across an active vendor master. Each hit requires manual triage before the next payment run, and most AP teams have no triage sequence for this finding because the ERP never raised it as a problem before.
Why Standard ERP Controls Do Not Catch This
ERP duplicate payment controls check three things: invoice number, vendor code, and amount. A payment that passes all three checks is processed. The bank account the payment routes to is not part of that check.
This means two vendor records with different vendor codes, different invoice numbers, and different invoice amounts can both pass duplicate payment validation and both route to the same NEFT or RTGS destination. SAP, Oracle, and Tally all treat the bank account field as independent per vendor record. There is no cross-vendor bank account uniqueness validation in standard configuration.
A shared bank account hit in the vendor master is invisible to the payment run. It only becomes visible when someone looks at the master file directly, and most AP teams do not look at the master file at that level of detail between onboarding events.
The same logic that causes duplicate GSTIN records to generate duplicate payments applies here: the ERP processes what it is told, and what it is told is shaped entirely by the data in the vendor master.
The Three Scenarios and What Each One Costs
When VCR-005 returns a hit, one of three things is true.
Scenario 1: Data entry error. The same vendor was onboarded twice, under two different vendor codes, with the same bank account. This is the most common finding. It creates duplicate payment risk on every invoice processed against either record. Recovery after a duplicate payment goes out via NEFT or RTGS is possible but not instant. The receiving bank must return the funds, the vendor must cooperate, and the timeline is typically three to seven working days. In the interim, the cash is gone from your account.
Scenario 2: Legitimate subsidiary or branch. A parent company and its subsidiary or branch office share a central treasury account by design. Payments to both vendor codes correctly route to the same destination. This is not a risk, but it requires documentation to confirm. Without an onboarding record that establishes the relationship, the shared account is indistinguishable from Scenario 3 during an internal or statutory audit. An auditor who finds this without documentation will treat it as a control failure.
Scenario 3: Insider fraud signal. A vendor record was created with a bank account belonging to an employee, a related party, or a colluding external party. Payments processed against this vendor code transfer funds outside the intended payee. This is the lowest-frequency scenario in a diagnostic, but the highest-consequence one, because the internal actor who created the record may still have access to the vendor master and the payment approval chain.
The escalation sequence has two stages. The first is an immediate referral to Internal Audit, whose mandate is to verify the bank account match against payroll records, extract transaction logs for both vendor codes, and freeze the records without alerting the suspected employee. Internal Audit is the right first responder when the signal is unconfirmed and the suspected employee is not in a senior role.
The threshold to move to an external forensic engagement is crossed when Internal Audit confirms the initial fraud indicators, or when specific risk conditions are present: the suspected employee is a Key Managerial Personnel or has access to the finance or IT control chain; there are indicators of collusion between an internal employee and an external party bypassing segregation of duties; or the company intends to pursue criminal prosecution, asset recovery, or insurance claims, all of which require a chain-of-custody-protected forensic report that an internal team cannot produce.
Under Section 143(12) of the Companies Act, 2013, read with Rule 13 of the Companies (Audit and Auditors) Rules, 2014, as typically interpreted, mandatory disclosure obligations are triggered by a “reason to believe” standard, not by confirmed proof. The reporting timeline and authority depend on the amount involved:
| Fraud amount (approximate) | Reporting authority | Timeline and mechanism |
|---|---|---|
| INR 1 Crore or more | Central Government (Ministry of Corporate Affairs) | Report to Board/Audit Committee within 2 days of discovery; await Board comments for 45 days; submit via Form ADT-4 within 15 days of Board comments |
| Less than INR 1 Crore | Audit Committee or Board of Directors | Report within 2 days of discovery; disclose nature, approximate amount, and parties involved |
The “reason to believe” standard means reporting cannot be deferred until forensic proof is complete or a confession is obtained. A professional, evidence-backed suspicion is sufficient to trigger the obligation. Per NFRA mandates as currently applied, the statutory auditor is required to report via Form ADT-4 independently, even if management or internal audit discovered the fraud first. A legal opinion obtained by management does not delay this pipeline.
The Companies Act interpretation above reflects general professional practice as of June 2026. Confirm with your statutory auditor or legal counsel before acting on specific thresholds or timelines.
The three scenarios differ in financial exposure and first action required:
| Scenario | Financial exposure | First action |
|---|---|---|
| Data entry error | Duplicate payment on next invoice run | Merge or deactivate the duplicate vendor code |
| Legitimate subsidiary | None, if documented | Confirm onboarding file; add relationship note to both records |
| Insider fraud signal | All payments processed to the fraudulent record | Freeze both vendor codes; escalate before next payment run |
What Happens After the Check Finds a Hit
The triage sequence is the same for every hit, regardless of which scenario you suspect.
First, freeze payments to both vendor records until triage is complete, not just the flagged record. If the hit is a data entry error, you cannot know which record holds the correct invoices until you look. If it is Scenario 3, processing any further payment to either record during the investigation creates additional exposure.
Second, pull the full payment history for both vendor codes going back 24 months. Look for invoice amounts, payment dates, and whether both codes have been actively used or only one. A shared bank account where only one code has ever been used is more likely Scenario 1 or 3. A shared account where both codes show regular payment activity is more likely Scenario 2.
Third, check the original onboarding documentation for both vendor codes. Is there a vendor registration form, a cancelled cheque, and a GST certificate for each? If one code has complete documentation and the other does not, the undocumented one requires escalation regardless of which scenario it appears to be.
This process takes between 30 minutes and two hours per hit, depending on how complete your onboarding records are.
The GSTIN validation check covered in the previous article in this series flags compliance exposure. VCR-005 flags payment and fraud exposure. Both are part of the same vendor master diagnostic suite, and both require the same response: triage before the next payment run, not after.
A structured vendor master diagnostic maps every shared bank account hit to a scenario before a payment run goes out. If you want to know what your vendor master contains, start with the Diagnostic.
Key observations
- ERP duplicate payment controls check invoice number, vendor code, and amount, not bank account uniqueness across vendor records. A shared bank account passes standard validation.
- VCR-005 returns hits in most vendor masters above 300 active records. The question is which of the three scenarios each hit represents.
- Scenario 3 (insider fraud signal) requires payment freeze and escalation before triage is complete. Processing further payments to either record during investigation increases exposure.
- Legitimate subsidiary sharing (Scenario 2) is only distinguishable from fraud if the onboarding documentation exists. Missing documentation turns a benign finding into an audit control failure.
- The triage sequence is the same regardless of ERP: freeze both records, pull 24-month payment history, check original onboarding files.