Vendor master data with Golden Suite

Deduplicate suppliers across procurement + ERP + accounting. The procurement-team playbook.

Vendor master data is customer-360's mirror image: same problem, supplier-shaped. Procurement, finance, AP, and operations each have their own "vendor list," and they're never the same. Until they are.

Why vendor MDM is its own thing

Customer MDM gets all the attention but vendor MDM is often higher-ROI:

  • Duplicate suppliers create payment errors. AP sends two checks because Acme Inc and Acme, Incorporated look like different vendors. Or worse — payments get sent to the wrong account because vendor info is split across records.
  • Procurement leverage erodes when spend is fragmented. If "Acme Office Supplies" appears 5 ways in your AP system, you can't see your true spend with them — and you can't negotiate based on volume.
  • Compliance + risk management depend on accurate vendor lists. Sanctions screening, anti-bribery checks, supplier-onboarding KYC all assume one canonical vendor per real-world entity.
  • W-9 / 1099 reporting requires deduplication. The IRS wants one 1099 per vendor, not three.

Setup sequence

Week 1 — Source the truth

Common vendor data lives in:

  • ERP (NetSuite, SAP, Oracle Financials, Microsoft Dynamics) — vendor table, payment terms
  • AP system (Bill.com, Tipalti, AvidXchange) — supplier records + payment history
  • Procurement (Coupa, Ariba, Procurify) — supplier catalog + contracts
  • Manual spreadsheets maintained by AP, finance, or operations

Connect each as a source. Most teams discover the AP system has the most complete contact data; the ERP has the cleanest legal-name and tax-ID data; procurement has the richest categorization. Each source contributes different fields to the golden record.

Week 2 — Match on identifiers, not names

Vendor matching benefits from strong identifiers more than customer matching does. Most countries have a registered business identifier (EIN/TIN in US, ABN in Australia, VAT/UTR in EU, ACN in Australia). Use these as primary blocking signals when available:

  • EIN / Tax ID — exact-match high confidence
  • Bank routing + account — exact-match (deduplicates "same vendor, different DBA")
  • Registered legal name — fuzzy match, lower weight
  • Trading name / DBA — fuzzy match, lower weight, often differs from legal name

A common surprise: 30-50% of vendor records in a mid-size company have no tax ID populated at all. Those need a separate matching strategy — fuzzy name + address + maybe payment-account similarity.

Week 3 — Survivorship for vendor records

Sensible defaults:

  • legal_name — source priority (registry > ERP > AP > procurement). Don't trust whatever was typed during onboarding.
  • tax_id — source priority (W-9 system > ERP). Once a tax ID is authoritative, lock it.
  • payment_address — most recent from AP (this changes; you want the latest).
  • mailing_address — most complete.
  • category — source priority (procurement system > everywhere else).
  • payment_terms — most recent from ERP (negotiated; don't take a stale value from somewhere else).
  • status_active — boolean OR of all sources (vendor is active if any source says active).

Week 4 — Cross-system reconciliation

The real win of vendor MDM is reconciling activity across systems:

  • "We have $50k of YTD spend with this vendor in NetSuite, but our procurement system only shows $30k of approved POs — there's $20k of spend going around contract."
  • "AP shows this vendor as inactive but we've received 3 invoices in the last month."
  • "Procurement shows two distinct vendors but they're the same legal entity — we're missing volume leverage."

Each of these is a query against the golden table joined back to source rows via lineage. Surface them as monthly reports for procurement + finance leadership.

Common pitfalls

  • One-time cleanup, never updating. Vendor master goes stale fast — M&A, address changes, payment-info updates. Run the pipeline weekly.
  • Auto-merging based on similar name. Two unrelated companies can share a name. Always require either matching tax ID OR matching payment account before auto-merging at high confidence. Otherwise leave it in the review queue.
  • Ignoring inactive vendors. Don't delete them; mark them inactive. They come back, and you'll want the historical record + lineage when they do.
  • Treating procurement and AP as the same data source. They're different shapes; both contribute to the golden record but neither is canonical alone.

Compliance angle

Vendor MDM is one of the few MDM use cases where the audit trail isn't a nice-to-have — it's directly relevant to:

  • SOX controls (segregation of duties around vendor setup + payment)
  • Sanctions screening (OFAC, EU consolidated list) — you can't screen if you don't have a deduplicated vendor list
  • 1099 / 1042 reporting — IRS requires accurate vendor identity
  • FCPA + anti-bribery diligence — supplier-by-supplier risk scoring

Golden Suite's cryptographic audit chain addresses the SOX angle directly: every survivorship-rule change, every approved merge, every export action is logged with actor + timestamp + before/after state, in an append-only structure where tampering breaks the chain.

Next steps

← Use CasesProduct catalog deduplication →