Try it now, capture a real invoice
Free plan · No credit card · Your data stays yours
The vendor master file is the central record of every supplier a company can pay: legal name, remit-to address, tax ID, bank details, payment terms, and status. It is the gatekeeper of accounts payable, because no invoice can be paid to a party that is not in it. That also makes it the single most attacked record in finance: nearly every large payment fraud starts with a change to the vendor master rather than a fake invoice.
What is a vendor master file?
Every ERP has one, whether it is called the vendor master, the supplier master, or just the vendor list. It holds one record per supplier and it is what the AP system looks up when an invoice arrives. If the record is right, the invoice gets coded correctly, the payment goes to the right bank account, the terms are applied, and the 1099 comes out clean in January. If the record is wrong, all four of those go wrong at once and nobody notices until the money has left.
Companies treat the vendor master as an address book. It is not. It is a control record. The moment someone is added to it, they become a party your organization is capable of paying, and the only thing standing between a fraudster and your bank account is how carefully that record was created and how tightly it is monitored afterward.
What fields belong in a vendor master record?
| Field | Why it matters | Control note |
|---|---|---|
| Legal name and DBA | Must match the W-9 and the bank account name | A mismatch between invoice name, bank name, and W-9 is the first red flag |
| Tax ID (EIN or SSN) | Drives 1099 reporting and backup withholding | Validate against the IRS TIN matching service before the first payment |
| W-9 on file, dated | Legal requirement for US vendors | No W-9, no payment. Treat it as a hard block, not a reminder |
| Remit-to address | Where checks go | PO boxes and residential addresses on a corporate vendor deserve a second look |
| Bank account and routing number | Where ACH and wires go | The highest-risk field in the entire ERP. See the change control section below |
| Payment terms | Drives due dates and discount capture | Terms set per vendor, never typed per invoice, or your DPO is fiction |
| Default GL account | Consistent coding | Cuts miscoding at the source |
| 1099 flag and box | Determines whether a 1099-NEC is issued | Set at creation, not in December when it is too late to collect the W-9 |
| Status (active, hold, blocked) | Controls payability | Deactivate, never delete. History has to stay auditable |
| Insurance certificate expiry | Applies to contractors and service vendors | An expired COI on an active vendor is an uninsured liability sitting in your building |
That last row is quietly expensive. If a contractor's general liability policy lapsed in March and someone gets hurt on your site in June, the claim finds its way to you. Insurance certificates expire silently, which is why a lot of AP and risk teams track them in a dedicated system that chases expiring certificates of insurance automatically rather than in a spreadsheet somebody was supposed to check.
Vendor master file controls that actually stop fraud
These are the controls an auditor expects to see, and each one exists because companies have lost seven figures without it.
1. Segregation of duties between vendor setup and payment
The person who can create or edit a vendor must never be the person who can release a payment. If one person controls both, they can create a supplier and pay it, and no invoice-level control will catch that. This is the foundational control in the whole process and it is the one most often broken in small teams. Our segregation of duties guide covers the workarounds when you genuinely do not have enough people.
2. Out-of-band callback on every bank-detail change
Someone emails AP, on a spoofed or compromised address, saying "our bank has changed, please update our details before the next run." This is how business email compromise works, and it succeeds constantly because it looks like routine housekeeping. The control: never accept a bank change from email alone. Call the vendor on a number you already had on file, not one from the request, and confirm with a named person. Log the call. No exceptions for urgency, because urgency is the whole attack.
3. Maker-checker approval on the record itself
A new vendor or a changed bank account should require a second person to approve the change in the system before it takes effect. A pending state, not a post-hoc report. Reviewing a change log after the payment ran is not a control, it is a postmortem.
4. TIN matching and screening at creation
Validate the EIN against IRS TIN matching, and screen the vendor against the OFAC sanctions list. Both take seconds and both are the kind of thing that becomes very expensive to explain if you skipped them.
5. Employee-vendor conflict check
Run vendor addresses and bank accounts against your employee master. A vendor whose remit-to address matches an employee's home address is either a legitimate reimbursement arrangement or a fictitious vendor scheme, and you want to know which.
How duplicate vendors cause duplicate payments
The most common vendor master failure is not fraud, it is duplication. "Acme Corp", "Acme Corporation", and "ACME Corp." become three records. Then the same invoice arrives twice, once by email and once in the mail, and gets keyed against two different records. Duplicate detection based on vendor plus invoice number never fires, because the vendor IDs differ.
| Duplicate cause | How it happens | Fix |
|---|---|---|
| Name variants | Punctuation, abbreviations, legal suffix typed differently | Fuzzy match on name plus tax ID before allowing a new record |
| Same vendor, different divisions | Each business unit sets one up | One master record, divisions as remit-to addresses, not new vendors |
| Merged or acquired suppliers | Old and new entity both stay active | Deactivate the old, map open items across |
| One-time vendors | A permanent record created for a single payment | A one-time vendor category that expires automatically |
Deduplication is where most of the recoverable money is. Search on tax ID first, because names lie and EINs do not. Then fuzzy-match names and bank accounts. Two vendor records sharing a bank account are either duplicates or something worse. Our guide to duplicate invoice payments covers the invoice-level side, and duplicate invoice detection software catches what a name-matching rule cannot.
Vendor master file maintenance: the quarterly routine
A vendor master decays about 20 percent a year on its own. People move, companies get acquired, banks merge. Run this every quarter:
- Deactivate the dormant. Any vendor with no activity in 18 months goes to inactive status. Do not delete: you need the history for audit and for 1099s. An inactive record cannot be paid, which shrinks the attack surface enormously.
- Re-run the duplicate scan. Tax ID, then name, then bank account. Merge what you find, carefully, with open items in mind.
- Chase missing W-9s. Anyone paid this year without a valid W-9 is a backup withholding problem waiting for you in January.
- Review every bank-detail change from the quarter. Pull the change log, confirm each one had a documented callback. If any did not, verify it now, before the next payment run.
- Confirm expiring insurance and licenses. Anything lapsing in the next 60 days gets chased now.
- Check the employee-address overlap. Ten minutes, once a quarter, and it is the query that finds fictitious vendors.
Who should own the vendor master file?
Not accounts payable. That sounds counterintuitive, and it is the most important structural point here. If AP owns vendor creation and also processes and pays invoices, the segregation of duties is broken by design, no matter how careful the people are. Ownership belongs to procurement, a vendor management function, or a controller-level role, with AP able to request a new vendor but not create one.
In a small company where that is genuinely impossible, compensate: require a second approver on every new vendor and every bank change, have someone outside AP review the change log monthly against source documents, and make sure that review is documented. An auditor will accept a compensating control. They will not accept nobody looking.
Onboarding a new vendor cleanly
The moment to get all of this right is at creation, because everything you skip at onboarding becomes an exception you chase forever. A clean intake collects the W-9, the bank letter or voided check, the insurance certificate, the remit-to address, and the payment terms before the vendor is payable at all, ideally through a portal the vendor fills in themselves rather than an email thread an AP clerk retypes. That removes the transcription errors and gives you a timestamped record of who supplied what. See the vendor onboarding process and vendor onboarding software for how to structure it.
A clean vendor master is not glamorous work. It is also the difference between an AP function that pays the right people the right amount and one that finds out in April that it wired $180,000 to someone who spoofed a supplier's email in February.