Finance Index
What is vendor master data and what should every vendor record contain?
Reference guide to vendor master data standards, including vendor records, onboarding requirements, compliance checks, fraud controls, and payment readiness.
Vendor master data is the controlled set of records identifying every supplier you transact with - legal identity, tax data, addresses, banking, terms, and status. It's the reference data AP, payments, and 1099 reporting all depend on. A gold-standard record contains verified identity, tax classification, validated payment details, defaults, and an ownership/audit trail.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Vendor master data | Vendor master data is the controlled set of records identifying every supplier you transact with - legal identity, tax data, addresses, banking, terms, and status. | Keeps evidence clear and reduces control risk. |
| Vendor impact | Identity: legal name, DBA, entity type, EIN/SSN, status. | Keeps vendor records and payment decisions reliable. |
| Vendor naming conventions | Pick one convention and write it down: legal name from the W-9 as the record name, consistent case (title case reads better than ALL CAPS), standardized suffixes (Inc, LLC. | Keeps vendor records and payment decisions reliable. |
| Vendor onboarding | Keep it to two pages - naming, required fields, remit-to rules, who approves what - embed the rules as required fields and validations in the system rather than in a PDF, and review exceptions monthly. | Keeps vendor records and payment decisions reliable. |
| Remit-to address be a separate | Yes, always - they routinely differ (lockboxes, factoring, payment processors), and paying to the wrong one causes misapplied cash. | Reduces payment errors, timing issues, and reconciliation cleanup. |
What's the gold-standard vendor master field list?
Identity: legal name, DBA, entity type, EIN/SSN, status. Tax: W-9/W-8 on file (with date), 1099 flag and box, TIN-match result. Locations: physical address, remit-to address(es). Payment: method, verified banking details, currency, terms. Defaults: GL account, payment terms, entity scope. Governance: created by, approved by, last change, linked documents. If a field can't be traced to who set it and why, it's a liability, not data.
Vendor naming conventions - how do I standardize names?
Pick one convention and write it down: legal name from the W-9 as the record name, consistent case (title case reads better than ALL CAPS), standardized suffixes (Inc, LLC - pick punctuation once), no abbreviations in the master name, DBA in its own field. The convention matters less than its consistency - duplicate detection, search, and 1099s all depend on it.
How do I create a vendor master data standard the team will actually follow?
Keep it to two pages - naming, required fields, remit-to rules, who approves what - embed the rules as required fields and validations in the system rather than in a PDF, and review exceptions monthly. Standards enforced by software outlive standards enforced by memos.
Should remit-to address be a separate field from physical address?
Yes, always - they routinely differ (lockboxes, factoring, payment processors), and paying to the wrong one causes misapplied cash. For multiple remit-tos, use your ERP's address/site structure rather than duplicate vendor records.
One vendor record or many for vendors with multiple locations or divisions?
One legal entity, one master record; represent locations as sites/addresses under it where your ERP supports parent-child structures. Separate records are justified only when the locations are genuinely different legal entities with different TINs.
What is a vendor record vs a vendor site vs a vendor address in my ERP?
The record is the legal entity (one TIN, one 1099); sites are transactable locations under it with their own ordering or remit-to details; addresses are data elements within sites. ERPs name these differently, but the hierarchy - entity, location, address - is universal.
Which vendor master fields should be mandatory vs optional in our ERP?
Mandatory: legal name, TIN (or documented exception), one validated address, payment terms, and 1099 determination. Banking mandatory for electronic-payment vendors. Everything mandatory that feeds payment or tax; everything else optional so setup doesn't stall on trivia.
Should default GL accounts, payment terms, and 1099 flags live on the vendor record - and who decides?
Yes - vendor-level defaults drive coding consistency and 1099 accuracy. AP/controller owns 1099 flags and terms defaults; accounting owns GL defaults. Defaults are suggestions for coding, but the 1099 flag is a control: changing it should require approval.
How do I categorize vendors - spend category, vendor type, or both?
Both, as separate fields: vendor type (supplier, contractor, service provider, government) drives compliance requirements; spend category drives analysis and sourcing. Keep the taxonomy to a dozen or two values each - taxonomies with 200 categories are write-only data.
How do I standardize 5,000 messy vendor names without breaking history?
Don't rename blindly: dedupe first, then apply the convention to surviving records via your ERP's rename (which preserves transaction linkage by vendor ID, not name), in batches, with a before/after log. Names are display attributes; the vendor ID carries history.
Vendor master vs supplier record vs supplier master - any real difference?
No - terminology varies by ERP and by which team is speaking (AP says vendor, procurement says supplier). The governance principles are identical.
Stampli perspective
Stampli's principle is "your ERP holds the data, Stampli holds the story." The ERP remains the source of truth for vendor master records; Stampli enriches and synchronizes those records while surrounding them with what ERPs can't hold - contract terms, insurance documents, communication threads, and complete interaction history - so the record is both clean and operationally usable inside AP.