Vendor master data: definition and how it works in accounts payable

What it means

Vendor master data is the payment-facing record of each supplier a company pays. It is also called the vendor master file, supplier master or vendor list. The record holds the legal name, remit-to and physical addresses, tax ID, bank details, payment terms and contacts that AP uses to validate an invoice, route it for approval, schedule payment and apply credits.

Each supplier should have a single active record for each legal entity the company contracts with, but that structure depends on the company, country and contract. Tax ID formats, bank detail validation and required approvals vary by jurisdiction and internal policy. A shared tax ID across two records may be legitimate for different divisions or currencies, so AP needs a documented reason before merging or blocking anything.

The record drives downstream outcomes. Payment terms set the due date and discount window. Bank details set where money goes. The remit-to address determines where remittance advice is sent. Contacts determine who gets a query when an invoice is short, disputed or missing. When those fields are wrong, the error surfaces later as a duplicate payment, a missed discount, a late fee or a payment to the wrong bank account.

How it works in practice

A new supplier usually starts with a request from procurement, a department or AP. The request should carry the legal name, tax ID, bank details, payment terms, remit-to address and a contact who can confirm those details. The request is approved before the vendor record is created, and approval should be separate from entry. Thresholds differ: some companies require a second approval for any bank detail change, while others require it only above a set amount or for new suppliers.

When an invoice arrives, AP uses the vendor record as the reference. The invoice legal name should align with the record, and the bank details on the invoice should match the details on file. If they do not match, the invoice is not a payment instruction; it is a change request. Payment terms on the record determine the scheduled pay date and whether a discount can be taken. If the terms on the record do not match the contract, the record is wrong, not the invoice.

Maintenance is continuous. Remit-to address changes, bank detail changes, legal name changes after a merger and contact turnover all require updates. Bank detail changes deserve independent verification through a known phone number or a known contact, not through the contact details on the change request. The person who requests a change should not be the same person who approves and enters it. A change log with the request, approval and evidence keeps the record supportable.

Where it goes wrong

Duplicate vendor records are a common failure. A supplier changes its remit-to address, and instead of updating the existing record, someone creates a new vendor ID. The old and new records may have slightly different names, so a name search does not catch them. The same invoice can then be entered under one vendor ID and paid again under the other. Matching on tax ID and bank details finds duplicates that names miss.

Wrong payment terms in the vendor record cause early payments, missed discounts or late fees. A record copied from a similar supplier can carry the wrong discount window. A default term entered during onboarding can override the contract. AP pays what the record says, so an early payment may be made before the company is obliged to pay, and a discount may be missed because the discount date passed. Late fees appear when the record gives a shorter term than the contract.

Bank detail errors are higher risk. A stale bank account, a transposed digit or an unverified change can send a payment to the wrong place. A remit-to address change can also create a duplicate vendor record, as above. When one person can request, approve and enter a bank detail change, the control is weak; this is where segregation of duties matters. The related term vendor bank detail change has its own page, but the AP point is simple: a change request is not proof.

Records also go stale. Inactive vendors stay open, contacts leave, and old bank details remain. A payment run can pick up an old record because no one blocked it. Credits sit unapplied because the current record does not link to the old one. Rules on blocking, retention and approval differ by country and company, so local policy should define when a vendor is made inactive.

What to check

Start with duplicate detection. Compare the vendor master file on tax ID and bank details, then look at remit-to addresses and near-identical legal names. Do not rely on a name-only search. For each candidate pair, confirm whether the company has a legitimate reason for two records, such as separate legal entities or currencies. If not, block the duplicate from payment and keep the history. Merge or retire records only under local policy, because retention and tax rules differ.

Check payment terms against the contract or approved supplier form, especially for frequent or high-value vendors. Look for records with default terms, blank discount fields, terms that do not match the contract, and terms changed without a supporting document. The AP clerk should be able to see the approved terms in the vendor record, and the approver should know who can change them. A term change should leave a trail, just like a bank detail change.

Check change controls. Pull recent bank detail changes and remit-to address changes, then confirm that each was independently verified and approved by someone other than the requester and the data entry person. Look for changes made just before a payment run, changes where the contact details also changed, and changes with no callback evidence. Segregation of duties is the point: request, approval and entry should not sit with one person.

Check completeness and ownership. Every active record should have a legal name, tax ID, remit-to address, bank details, payment terms and a contact who can confirm the details. Missing tax IDs make duplicate matching weaker. Missing contacts make verification impossible. Assign a named owner for vendor master data maintenance, review the active list on a cadence set by local policy, and reconcile unapplied credits against vendor records.

Questions