The vendor master file might be the least glamorous object in the audit universe: a table of names, addresses, tax IDs, and bank accounts. It is also the single control point through which every outbound payment in the company flows. The three-way match in accounts payable verifies that the amount is right; the procurement process decides the deal is right. Neither verifies that the bank account receiving the money belongs to the vendor you think you are paying. Only the vendor master does that — which is why nearly every modern payment-fraud scheme, from business email compromise to phantom vendors, is at bottom an attack on this one unglamorous table.
The economics of auditing it are outstanding: the scope is small, the data is one extract, most tests run at full population, and the findings are the kind that stop actual wire transfers to actual criminals. This guide covers the whole file: why it is the chokepoint, onboarding verification, the payee-change fraud vector and the controls that defeat it, data-quality analytics (duplicates, employee-vendor collisions, dormant records), governance and segregation of duties, and the complete test program.
This guide was rewritten in September 2026 to add what the August version left out: how to size and sequence the engagement, a template for the bank-change verification record that most of the test program depends on, the scoping variants for shared service centers, acquisitions and outsourced payables, MidState Beverage’s vendor master audit test by test, and the links to the templates and the fraud-side guides that carry the work. The verification ladder, the payee-change controls, the duplicate ladder, the 12-test program and the analytics catalog are unchanged. The scheme this file guards against has kept growing: the FBI’s Internet Crime Complaint Center recorded 24,768 business email compromise complaints in 2025 with losses of 3.05 billion dollars, up from 2.77 billion the year before, and its Recovery Asset Team froze 679 million of the 1.16 billion dollars it was asked to chase, a recovery rate that depends entirely on someone noticing within hours. The payment operations guide covers the hours; this guide covers the table the fraud has to get through first.
In this guide
- Why this small file is the fraud chokepoint
- Onboarding: verification before the first record exists
- The payee-change fraud vector — and the controls that defeat it
- The bank-change verification record: what the evidence has to show
- Data-quality analytics: duplicates, collisions, and dormant records
- Governance and segregation of duties
- Sizing and sequencing the engagement
- The test program
- The analytics catalog
- Worked example: MidState Beverage’s vendor master audit
- Scoping variants: shared services, acquisitions and outsourced payables
- Where to go next
Why this small file is the fraud chokepoint
Map the major payment-fraud schemes onto the purchase-to-pay cycle and they converge on the same square. Payee-change fraud (the business-email-compromise classic): the vendor is real, the invoice is real, the work was done — only the bank account was swapped by a fraudster who emailed a convincing change request. Phantom vendors: an insider creates a vendor that exists only on paper, then feeds it invoices; the scheme’s load-bearing moment is the master-file record’s creation, not the invoices. Duplicate-vendor double payment: the same supplier exists twice with slight name variations, and the same invoice gets paid through both. Dormant reactivation: a long-dead vendor record is quietly revived with new bank details — inheriting the trust of its history without re-earning it. In every case, downstream controls pass, because downstream controls trust the master. The file is the authentication layer of the entire payment system, and it deserves the audit attention of one — the same worked control row we built into the RCM template guide as its second example, precisely because it earns the space.
Onboarding: verification before the first record exists
A vendor record should be earned, and the onboarding control set is a verification ladder — each rung answering one question. Does the business exist? Registry or incorporation check, a real operating address (flag records whose only address is a P.O. box or a residential street), and a working phone independently sourced — not just the one the vendor supplied. Is the tax identity real and theirs? Tax ID collected and validated against the name (mismatches are how phantom vendors and sanctioned parties hide). Is the bank account theirs? This is the rung most programs skip: account validation via a name-match or verification service, a confirmed micro-deposit, or a documented call-back — something that ties the account to the entity, because an invoice header with bank details on it proves nothing. May we deal with them? Sanctions and denied-party screening at onboarding and on an ongoing basis against list updates — a control that connects this file to your third-party program and, for IIA shops, to the diligence expectations in the Third-Party Topical Requirement.
Two design points make the ladder workable. Tier it: a full verification stack for every $200 one-time supplier produces a bypass culture; calibrate depth to spend and risk, but make the bank-validation rung universal — it is the one that stops wires. Separate it: the person requesting the vendor (the buyer) must not perform the verification or the setup. Onboarding done by the requester is the phantom-vendor scheme’s enabling condition, and it is the first segregation test in the program below.
The payee-change fraud vector — and the controls that defeat it
The scheme deserves its own section because it is the one most likely to be running against your organization this quarter. The mechanics are simple and effective: the fraudster — having compromised or convincingly spoofed a real vendor’s email — sends AP a professional, urgent, plausible request to update banking details, often timed just before a known large payment. Every subsequent control passes: real vendor, real invoice, approved PO, perfect match. The money simply arrives somewhere else. What defeats it is a short list of controls that must hold without exception, because the scheme is engineered to be the exception:
- Call-back verification to the number on file — never to a number in the request, however official the signature block. The entire control is the independence of the channel; a call-back to the fraudster’s number is a courtesy call.
- No banking changes via email content alone — changes originate in a portal or verified process, and an emailed “updated remittance letter” is a trigger for verification, never a source document.
- Dual control in-system — a second, independent person approves the change before it takes effect; the change is inoperative until approved.
- Detective backstop — a complete monthly report of every banking-detail change, reviewed against supporting verification evidence, plus an alert (or at minimum an analytic) on payments issued within a short window after a bank-detail change — the change-then-payment pattern is the scheme’s heartbeat.
When you audit these, test the exception path, not the happy path: pull the changes that went through outside the portal, after hours, marked urgent, or approved by the same person who entered them. The scheme lives exactly where the control was waived because the request seemed credible and the vendor seemed impatient — credible urgency is the attack, and a control that yields to it does not exist.
The bank-change verification record: what the evidence has to show
Test 4 fails in most organizations not because nobody called the vendor but because nobody can prove what number they called. A call-back that is not recorded is indistinguishable from a call-back to the fraudster’s number, and an auditor who accepts “we always call” as evidence has tested nothing. The record below is what the verification evidence has to contain for the control to be auditable; it is short enough to be a portal form or a ticket template, and it is the artifact management most often asks for after the finding.
Bank-detail change verification record. 1. Vendor and record: vendor ID and name, the field changed, the old value and the new value, and the source of the request (portal submission, letter, email, phone) with the request attached. 2. Independence of the channel: the telephone number called, the source of that number (the master record as at the day before the request, the last signed contract, or a number independently obtained), and a statement that no number from the request itself was used. 3. The contact: the name and role of the person reached, the date and time, and confirmation that the person is known to the organization from prior dealings or was verified through the vendor’s published switchboard. 4. The verification: the new details read back by the contact, not read to them, and whether the contact was aware of the request. 5. The second person: who approved the change in the system, with confirmation that the approver is not the person who entered it and did not perform the call-back. 6. Timing: the date the change became effective, and the date of the first payment to the new details, which must be after the record was completed. 7. Exception handling: if any element could not be completed, who authorized the change to proceed anyway, on what basis, and what compensating step was taken, such as a small first payment confirmed by the vendor before the balance.
Line 2 is the whole control. When you test the population, test line 2 first and the rest only for the changes that pass it, because a change verified through a number in the request has already failed regardless of how complete the remaining lines are. Line 7 is where the exception path lives, and the exception path is where the scheme lives; a record with a line 7 entry and no line 2 entry is the pattern to pull every time.
Data-quality analytics: duplicates, collisions, and dormant records
Duplicates are the file’s chronic disease. They arise innocently — mergers, system migrations, “ACME Corp” versus “Acme Corporation” versus “ACME Corp.” — and they matter for two reasons: duplicate payment exposure (the same invoice paid through both records passes every match), and control evasion (a blocked or flagged vendor resurrected under a variant name). Match on a ladder of decreasing obviousness: exact name after normalization (case, punctuation, legal suffixes); same tax ID under different names (nearly always the same entity — or identity misuse); same bank account under different vendor names, the single strongest signal in the file, because companies share addresses and even names, but unrelated companies do not share bank accounts; then fuzzy name matching for the long tail. Every same-bank-different-name hit deserves individual disposition, in writing.
Employee-vendor collisions are the same match logic that finds ghost employees, pointed the other direction: fuzzy-match employee master fields — home address, bank account, phone, tax ID — against vendor master fields. Hits range from the benign (a legitimately disclosed employee side business) to the reportable (an undisclosed conflict) to the referable (a phantom vendor paying its creator), and the disposition discipline matters as much as the match: handle hits discreetly, verify before confronting, and route clusters through the fraud-escalation protocol rather than the draft report. Dormant records complete the trio: vendors with no activity for 18–24 months should be deactivated on a schedule, because every live record is attack surface — and reactivation must require fresh verification, full ladder, since the dormant-reactivation scheme works precisely by inheriting a dead record’s accumulated trust. Test the deactivation cadence, then pull every reactivation in the period and inspect its re-verification evidence.
Governance and segregation of duties
The file needs an owner, and the owner should be a master-data function — not the buyers who request vendors, and not the AP processors who pay them. That triangle is the process’s core segregation: request (procurement), create and modify (master data, after verification), consume (AP) — with no single role able to create a vendor and then pay it. In smaller organizations where one team wears two hats, the compensating control is a genuinely independent review of every creation and change, and your test should treat “the supervisor glances at a weekly list” with the skepticism it deserves: review evidence means the reviewer can show what they checked and what they queried. Governance also means metrics — change volumes, duplicate rate, dormant share, verification-completion rate — reported to someone who can act, and a periodic cleanse with an owner and a date rather than a standing aspiration. A vendor master that has never shrunk is a vendor master nobody governs.
Sizing and sequencing the engagement
The vendor master audit is the cheapest engagement in the purchase-to-pay series and the one with the highest fraud-prevention value per hour, because the population is one table with its change history and almost every test runs at full population. The hours below assume a single ERP, a file of a few thousand active vendors, access to the employee master under a documented arrangement, and an auditor who can join two tables. The two things that stretch it are multiple ERPs after an acquisition, where the duplicate ladder has to run across systems with different keys, and a change history that the ERP does not keep, in which case the bank-change population has to be rebuilt from workflow tickets and the audit’s first finding is that it had to be.
| Phase | What happens | Hours |
|---|---|---|
| Planning and access | The extract specified with its change history; the employee master obtained under an access arrangement that covers bank details; the RCM drafted from the verification ladder | 15 |
| Walkthrough | One onboarding and one bank change from request to effective record, on the portal path and on whatever path exists beside it | 10 |
| Analytics | The eight catalog analytics on the full file: change-then-payment, shared bank, employee match, shared tax ID, reactivation, address quality, change velocity, creator-payer overlap | 30 to 40 |
| Bank-change population | Every change in the period listed; verification evidence inspected for the risk-weighted sample and for every change followed by a payment within ten days; the exception path tested in full | 30 to 40 |
| Onboarding, dormancy and screening | The new-vendor sample against the ladder; deactivation cadence and every reactivation; the sanctions screen re-performed and the ongoing feed checked | 25 |
| Hits, dispositions and governance | Every shared-bank and employee-match hit dispositioned in writing; the monthly review re-performed; owner, metrics and cleanse evidenced | 25 |
| Reporting | Findings written to the control, with hits that involve a person routed under the protocol rather than into the draft | 25 |
| Total | 160 to 180 |
Sequence the analytics first and the bank-change population second, because between them they decide where the remaining hours go: a clean change-then-payment analytic and a portal that enforced dual control on every change let the onboarding and dormancy work take the weight; a dirty one turns the engagement into a verification-evidence exercise and the report into a single High finding with a long appendix. Run the employee match early, for the reason the sibling guides give: it is the test most likely to produce a referral, and a referral in the first week costs nothing while a referral in the last week costs the report date. Record the sample decisions in the sampling memo; the risk-weighted bank-change sample is the one a reviewer will ask about.
The test program
| # | Test | Focus |
|---|---|---|
| 1 | Walk vendor onboarding and a banking change end to end; reconcile the process as performed to policy and update the RCM | All |
| 2 | Sample new vendors: inspect each verification rung — existence, tax ID validation, bank-account validation, sanctions screening — with evidence, tiered per policy | Onboarding |
| 3 | Test that vendor creation is performed by master data (not requesters) for the full population of new records: creator ID vs. requester ID | SoD |
| 4 | Pull the complete population of banking-detail changes; inspect call-back and dual-approval evidence for a risk-weighted sample, and for EVERY change followed by a payment within 10 days | Payee-change |
| 5 | Test the exception path: changes entered and approved by the same user, made outside the portal, or lacking verification artifacts — full population | Payee-change |
| 6 | Reperform two monthly change-report reviews; verify report completeness against the system change log | Detective layer |
| 7 | Run the duplicate ladder (normalized name, shared tax ID, shared bank account, fuzzy name); disposition every shared-bank hit individually | Duplicates |
| 8 | Fuzzy-match employee master against vendor master (address, bank, phone, tax ID); investigate all hits discreetly | Collisions |
| 9 | Test dormant-deactivation cadence; pull all reactivations in period and inspect fresh-verification evidence | Dormancy |
| 10 | Screen the full active file against current sanctions/denied-party lists; verify ongoing-screening configuration | Screening |
| 11 | Profile data quality at full population: missing tax IDs, P.O.-box-only addresses, placeholder fields, free-text bank entries | Data quality |
| 12 | Review governance: named owner, metrics reported, last cleanse completed with evidence | Governance |
The analytics catalog
| Analytic | How it works | What a hit means |
|---|---|---|
| Change-then-payment window | Flag payments issued within N days of a banking-detail change on the same vendor, weighted by amount | The payee-change scheme’s heartbeat; every large hit gets its verification file pulled |
| Shared bank account | Group vendor records by bank account; flag accounts serving multiple vendor names | Duplicate records, related-party structures, or one fraudster running several shells |
| Employee-vendor fuzzy match | Match employee address/bank/phone/tax fields against vendor fields with normalization | Undisclosed COI or phantom vendor — verify quietly, escalate per protocol |
| Shared-tax-ID clusters | Group by tax ID; flag multiple names per ID | Same entity duplicated, or an ID borrowed to pass validation |
| Reactivation-then-payment | Dormant records (18–24 months idle) that reactivate and receive payment within a short window | Trust inheritance — inspect who reactivated it, and the re-verification evidence |
| Address-quality screen | Flag P.O.-box-only, residential, mail-drop, and shared-with-employee addresses | Phantom-vendor construction material; also plain data rot |
| Change-velocity outliers | Count of master-record changes per vendor per year vs. population norm | Records being actively manipulated — or a vendor in genuine flux; look either way |
| Creator-payer overlap | Users who both maintain vendor records and process payments (effective access, not job titles) | The SoD break that enables every insider scheme in this guide |
Worked example: MidState Beverage’s vendor master audit
MidState Beverage, the three-state drinks distributor used across this site, met its vendor master the hard way. The accounts payable audit in the FY27 plan, corroborating the function’s first AP analytics run, found 188 duplicate vendor records created by the migration of two acquired distributors, 29 of the 41 confirmed duplicate payments running through them, an exact-match duplicate check disabled during the migration and never re-enabled, 31 of 46 bank-detail changes with no evidence of a call-back, fourteen of them followed by a large payment within ten days, one of which was a business email compromise attempt the bank had stopped, nine users able to create a vendor and enter an invoice, and an undisclosed trucking vendor owned by a depot manager, which went to the allegation protocol. Remediation created a master-data analyst at head office, moved bank changes into a portal with dual approval, merged the duplicates and ran the first cleanse the file had ever had. The FY28 vendor master audit had a different job: to test whether the remediated controls operated, and to go deeper into the parts of the file the AP audit had not reached, dormancy, screening and data quality. The population was the file as it stood after the cleanse, 2,590 active vendors, with twelve months of change history, and the engagement took 170 hours.
| Test | Population and sample | What it found | Where it went |
|---|---|---|---|
| 1. Walkthrough | One onboarding, one bank change, on each path that existed | Onboarding and changes ran through the master-data analyst and the portal at head office and the ten legacy depots; the two acquired distributors’ AP teams retained a local vendor-create right that remediation had described as temporary. | RCM redrawn with the legacy path as a live risk |
| 2. Onboarding diligence | 96 vendors created in the year; sample 25, weighted to the acquired distributors | Existence verified for 25, tax identity validated for 25, sanctions screened for 25, bank details independently validated for 24; the one exception was created through the legacy path. | Combined with test 3 |
| 3. Creator against requester | All 96 new records | 91 created by master data after verification; five created by the acquired distributors’ AP staff who had also requested them, with no verification record for three. | Finding, Medium: the legacy creation path |
| 4. Bank-change verification | All 52 changes in the year; every one followed by a payment within ten days inspected | Portal dual approval enforced on all 52; a verification record meeting the standard above for 49; three lacked the channel-independence line, two of those followed by payments within ten days, both genuine on investigation. | Finding, Low, down from the prior year’s High |
| 5. Exception path | Full population of changes | No changes outside the portal, none entered and approved by the same user; four after hours and seven marked urgent, all with complete records. | No finding |
| 6. Monthly change review | Two months re-performed | Reports complete against the system change log in both months; the reviewer’s queries evidenced in one month and absent in the other, where the review was a signature. | Observation to the controller |
| 7. Duplicate ladder | The full file, four rungs | 41 residual pairs after the cleanse: 19 shared a tax ID, nine shared a bank account, thirteen were fuzzy-name matches. The nine shared-bank hits were dispositioned individually: seven franchise or group structures, two vendors paid through the same factor. | Finding, Low; the exact-match check confirmed re-enabled and tested |
| 8. Employee-vendor match | The file against 1,400 current and 340 terminated employees | Two hits. The disclosed spouse-owned cleaning contractor, still disclosed and still cleared; and an address match between a depot supervisor and a vendor leasing overflow yard space to the depot at 28,800 dollars a year, not on the conflicts register. | Undisclosed lease reported to the conflicts committee; finding, Medium, on attestation coverage below management grades |
| 9. Dormancy and reactivation | 612 vendors idle more than eighteen months at the start of the year; all 23 reactivations in the year | Deactivation was quarterly on paper and had run twice; nine of the 23 reactivations carried no fresh verification, two of them with a bank change at reactivation followed by payment. Both were seasonal suppliers and genuine. | Finding, High: reactivation bypassed the ladder entirely |
| 10. Sanctions screening | The full active file; the ongoing-screening configuration | No true matches; three false positives cleared with evidence. The list-update feed had failed for six weeks in the year and nobody had been alerted. | Finding, Medium; alerting added to the feed |
| 11. Data quality | Full-population profile | 104 records without a tax ID, 61 with a post-office box as the only address, twelve placeholder names left from the migration, no free-text bank fields since the portal. | Finding, Low; folded into the quarterly cleanse |
| 12. Governance | Owner, metrics, cleanse | Named owner; monthly metrics on change volume, duplicate rate, dormant share and verification completion reported to the controller since remediation; the cleanse evidenced; the file 18 percent smaller than a year earlier. | No finding; noted as the reason the year’s results were what they were |
The report carried seven findings, one High, three Medium and three Low, an overall rating of Needs Improvement, and no referrals. The rating disappointed a management team that had done a year of real work, and the report said so in its first paragraph, with the prior year’s numbers beside this year’s: the bank-change finding had gone from High to Low, the duplicates from 188 records to 41 pairs, the creator-payer overlap from nine users to five, and the first-ever shrinkage of the file was on the record. What kept the rating where it was is instructive. The dormant-reactivation path had never been in anyone’s remediation plan because the AP audit had never tested it, and the two reactivations with bank changes and no verification were, on the analytics, indistinguishable from the takeover pattern this guide describes; that they turned out to be seasonal suppliers was luck, and the finding said so. The legacy creation path was a remediation described as temporary a year earlier and still open, which is the pattern the issue log exists to expose. And the undisclosed lease was a small number found by a test that costs an hour, which is the argument for running the employee match every year rather than once.
Scoping variants: shared services, acquisitions and outsourced payables
Shared service centers concentrate the file and the risk. One master-data team serving many entities is the right design, and the audit shifts to the boundary between the entities’ requesters and the center: whether the center can refuse a request, whether it verifies or merely keys, and whether the entities have quietly kept local creation rights for speed, which is what MidState’s acquired distributors had done. Test the creation population by creator organization, not by policy. Acquisitions are where duplicates and dormant records are manufactured, and the audit after a migration should treat the migrated population as unverified: every migrated record with a bank account that receives a payment inherits trust it never earned in the acquiring organization’s process, and the practical control is a re-verification of active migrated vendors within a defined period, which almost nobody plans and which the audit should ask for. Outsourced accounts payable, whether a business process provider or a managed service, moves the keying of the file outside the organization without moving the risk; the provider’s SOC 1 report will describe its change-control procedures and will list, among its complementary user entity controls, the verification and approval steps it assumes the client performs. Read the SOC 1 review method for how to test those, and expect the call-back to be one of them: providers key what they are told, and the independent channel is the client’s to operate. Since 15 September 2026 the IIA’s Third-Party Topical Requirement gives that reliance a program-level baseline, and a payables provider with the ability to change where the organization’s money goes belongs at the top of its criticality ranking. Small organizations, finally, cannot separate request, create and consume across three teams; the compensating control is an owner outside AP, the controller usually, who approves every creation and bank change with the verification record in front of them, and the test is whether that record exists for every one of them, because in a small file every one of them can be read.
Where to go next
The vendor master audit is the highest ratio of fraud-prevention value to fieldwork hours on the audit plan: one extract, a dozen tests, mostly full-population, guarding the table every payment trusts. It completes the purchase-to-pay coverage on this site, with procurement for how the deal is struck, this file for who gets paid, and accounts payable for how the money moves, and it connects to payment operations on the bank side of the boundary. Put the register for the engagement into the structure of the RCM template, run the analytics before you pick a single sample, test the verification record rather than the assurance that calls are made, and give the change-then-payment report to the fraud team when you leave; it is the rare audit deliverable that keeps catching things after the report is issued.
Related guides
- How to audit accounts payable — the back end of the cycle, with MidState’s FY27 engagement that found the file’s problems first
- The accounts payable analytics catalog — the vendor-master red flag family and MidState’s first run
- How to audit procurement — the front end, with Brightwater’s worked engagement
- The P2P fraud analytics catalog — the cross-stage tests, including the employee-vendor and bid-loser joins
- Procurement fraud schemes — phantom vendors, kickbacks and bid rigging, and how each one uses this file
- How to audit payment operations and wire transfers — the hours after a bad change gets through
- How to audit cash management and bank reconciliations — where a diverted payment finally surfaces
- How to audit payroll — the same match logic pointed at ghost employees
- How to review a SOC 1 report — testing the verification controls an outsourced payables provider assumes you operate
- The Third-Party Topical Requirement — the baseline for provider oversight in effect since 15 September 2026
- The ACFE fraud tree explained — billing schemes and the shell company, in context
- When internal audit finds fraud: the first 48 hours — what to do with an employee-vendor hit that is not benign
- The fraud red flags library — the vendor and disbursement indicators, organized for triage
- The risk and control matrix template — with the vendor master control as its second worked example
- Segregation of duties beyond the ERP — request, create and consume kept apart
- How to perform a user access review — finding the creator-payer overlap from effective access
- The sampling memo template — documenting the risk-weighted bank-change sample
- Annotated workpaper examples — the disposition grid every shared-bank hit is recorded in
- The 5 C’s of audit findings — how the seven findings were written
- The finding and issue log template — how a temporary remediation stays visible until it is closed
- Fieldwork and testing guides, data analytics guides and fraud risk guides — the full collections
Leave a Reply