Vendor Master Data: Duplicates, Bank Fraud and Real Controls

Most organisations treat the vendor master file as a boring reference table. Someone in finance keys in a supplier, adds a bank account, and moves on. That table is where money leaves your company. If you can edit a bank account and also release the payment that follows it, you are one convincing email away from wiring six figures to a criminal. This is a checklist for treating the vendor master as what it actually is: the softest, most valuable target in your ERP.

The vendor master is a fraud surface

Start with the attack, because the controls only make sense once you have seen the mechanics. A bank-detail change fraud runs like this. The attacker studies your supplier relationships, often from a compromised mailbox on the supplier side or from public tender records. They send a message that looks routine: "We have changed our bank. Please update our details for the next invoice." The email spoofs a real contact, references a real purchase order, and arrives when a genuine invoice is expected. A clerk opens the vendor record, edits the IBAN, and the next payment run does the rest. Nobody stole a password. Nobody breached the ERP. The system did exactly what it was told by someone with legitimate access.

It succeeds for one structural reason: the same person, or the same small team, can both change the bank details and approve the payment. There is no second pair of eyes between the edit and the cash. Segregation of duties is the oldest control in accounting, and the vendor master is where it quietly collapses. A three-way match will happily reconcile a valid PO, a valid goods receipt, and a valid invoice while the money flows to the wrong account, because the match validates the transaction, not the destination. If you have automated approvals without fixing this, read how I sequence controls in accounts payable workflow automation before you go further.

The control set that closes it

Four controls, applied together, take the bank-detail attack from "easy" to "very hard". None of them are exotic. Each one inserts friction exactly where the fraudster needs speed. Treat this as a checklist and confirm each item is live in your ERP, not just in a policy document nobody reads.

1. Dual approval on every bank-detail change.

A change to IBAN, account number, or beneficiary name must be entered by one user and approved by a second, independent user before it takes effect. The approver must not be able to release payments to that vendor. Configure this as a field-level workflow, not a policy. If your ERP cannot lock bank fields behind a maker-checker step, that gap is your single biggest exposure.

2. Callback verification against an independently sourced number.

Before the change is approved, someone calls the supplier and confirms it. The critical word is independently sourced. You do not call the number in the request email, the new letterhead, or the signature block, because the attacker controls all three. You call the number already on file from the original onboarding, or one you find on the supplier's official domain. Log who called, the number used, who they spoke to, and the date.

3. A mandatory cooling period before first payment.

After bank details change, no payment to that vendor may be released for a fixed window, typically three to five working days. This kills the fraudster's advantage, which is timing the change to land just before a real invoice. It also gives a genuine supplier time to flag "we did not change anything" if the request was fraudulent. The cooling period costs an honest supplier a few days once; it costs a criminal the entire scheme.

4. A seven-day exception report.

Run a standing report of every payment made within seven days of a bank-detail change on that vendor. Finance reviews it weekly. Any hit that slipped through the cooling period gets investigated before month-end, not after the auditor finds it. This is your detective control, the net under the three preventive ones above.

Deduplication that actually works

Duplicate vendors are the fraud surface's quiet twin. A duplicate lets the same invoice get paid twice, hides a supplier under a slightly different name to dodge a block, and wrecks your spend analytics. Exact-match deduplication catches almost nothing, because duplicates are rarely identical. You need fuzzy matching on the fields that actually identify a legal entity. Score each candidate pair and route anything above a threshold to a human.

A shared trade licence or tax number is close to proof. A shared name alone is a weak signal, because "Al Noor Trading" is not rare. The interesting case is a shared IBAN across two records with different names.

Worked merge decision: same IBAN, different name.

Suppose record A is "Gulf Technical Services LLC" and record B is "GTS Contracting", and both carry the same IBAN. Do not auto-merge. A shared IBAN can mean one legitimate entity onboarded twice, or it can mean two records are being funnelled to one account, which is exactly what fraud looks like. Work the decision in order:

• Compare trade licence and tax registration numbers. If they match, it is one entity: merge, keeping the record with the complete onboarding documents as the survivor and retiring the other.
• If the licence numbers differ but the IBAN is shared, freeze both and investigate. Two separate legal entities should not share a bank account without a documented reason such as a parent company collection account.
• Never merge by deleting; deactivate the losing record and repoint its transaction history so the audit trail survives. This is the same discipline I apply across the procurement workflow from PR to PO to GRN.

The point of the rule table is to make the machine surface candidates and a human make the call. Fuzzy matching that auto-merges will eventually destroy a real vendor's history. For a broader view of why destination integrity matters as much as amount integrity, see three-way matching across PO, GRN and invoice.

Onboarding fields that matter in the GCC

A clean vendor master starts at onboarding. In the GCC, a handful of fields do the real work of proving a supplier is a genuine, licensed, tax-registered entity. Capture these as structured fields with expiry dates, not as scanned attachments nobody ever opens again.

Onboarding is not a one-time event. Store an expiry date against every document and run a re-verification schedule: a report of everything expiring in the next 30 days, an automatic block on new POs to a vendor with a lapsed trade licence, and a periodic refresh of the bank letter tied back to the callback control above. A vendor master that verifies once and never again is stale within a year.

The monthly vendor-master health report

Controls decay unless someone measures them. Put eight metrics on one page every month and have the finance director sign it. The signature turns "we assume the vendor master is fine" into an owned, dated statement. These are the eight I track:

1. Bank-detail changes this month, and how many went through dual approval and a logged callback. The two numbers should be equal.
2. Payments made within seven days of a bank change, from the exception report, each with a disposition.
3. Active duplicate candidates above the match threshold, still unresolved.
4. Vendors missing a mandatory field (trade licence, TRN, bank letter).
5. Documents expiring in 30 days and the count already lapsed.
6. Vendors with no transaction in 24 months, candidates for deactivation and a shrunk attack surface.
7. Records created this month, versus how many completed full onboarding.
8. Users who can both edit bank details and release payment. The target is zero. Any number above zero is your segregation-of-duties gap, named.

The last metric is the one that matters most, and the one nobody wants on paper. If it is not zero, you have not fixed the fraud surface, you have only documented it. A metric that stays red month after month with a director's signature under it is how a control failure becomes a decision someone owns.

A note on independence

I am an independent practitioner, not a reseller, and I have no commercial tie to any ERP vendor, bank, or verification service named or implied here. This checklist reflects my own field experience across GCC ERP and procurement projects. It is general guidance, not legal, tax or audit advice. Regulatory field requirements and control expectations differ by jurisdiction and change over time, so validate anything here against your own auditors and against current authority guidance before you configure it. For control terminology, the ISACA glossary is a good neutral reference.

Conclusion

The vendor master looks like a table of names and account numbers. It is really the door that money walks out of. Treat it as a fraud surface and the work becomes obvious: separate the person who edits bank details from the person who pays, verify changes against a number the attacker does not control, slow the first payment down, deduplicate on identity not spelling, keep the GCC onboarding fields current, and put eight numbers in front of a director every month. None of it is expensive. All of it is cheaper than one wire that never comes back.