Vendor Matching Is Where Due Diligence Starts Cascading

Most teams treat vendor matching as a cleanup task. Someone deduplicates a spreadsheet. Someone merges two CRM records. Someone maps a supplier name from an invoice to an entry in the ERP. The work looks small because the first screen looks small.

The cost shows up later, in places that no longer look like a matching problem.

The bill for bad identity#

Gartner still cites research that poor data quality costs organizations at least $12.9 million a year on average. IBM's Institute for Business Value reported in 2025 that more than a quarter of organizations estimate annual losses above $5 million from poor data quality, and 7% report losses of $25 million or more. Forty-three percent of chief operations officers named data quality their most significant data priority.

Those numbers are not only about missing fields. Dun & Bradstreet, quoting Gartner, puts it directly: entity resolution can be equated with data quality. If you cannot tell whether two records are the same company, every downstream system invents its own truth.

Gartner also notes that 59% of organizations do not measure data quality, and that inconsistency across sources is the most challenging quality problem. Unmeasured matching debt is still debt.

How one weak key becomes many findings#

A vendor key is never just a vendor key. Once it is wrong, findings cascade.

Finance pays the wrong entity, splits spend across duplicates, or fails to roll up risk to a parent.

Procurement negotiates without seeing the full relationship, because half the volume lives under another spelling.

Security and compliance cannot complete due diligence. Beneficial ownership, sanctions, and questionnaire history attach to the wrong node.

Support and success open tickets against a child brand while the contract lives under the parent.

Analytics and AI learn from fractured histories. IBM notes that nearly half of business leaders cite data accuracy or bias as a barrier to scaling AI, and that agents inherit and amplify those defects. A bad match does not only break a report. It teaches an agent the wrong customer.

This is why I care about key-value matching as due diligence, not as tidy data. The match decision is the control point. Everything after it inherits the confidence of that decision.

What good matching looks like in practice#

A durable approach is less glamorous than a new dashboard.

1. Decide the entity grain. Are you matching legal entities, billing sites, or brands people buy from? Mixing those grains is how false merges happen.
2. Use more than one key. Legal name alone fails. Add identifiers, addresses, URLs, national IDs where lawful, and parent relationships.
3. Keep confidence visible. Auto-merge high confidence. Queue the rest for review. Never hide a fuzzy match as a fact.
4. Record survivorship. When two records merge, note which source won which field and why.
5. Re-check on change. Names, ownership, and addresses move. Matching is a loop, not a migration weekend.
6. Measure the cascade. Track duplicate payment rates, unmatched invoices, false sanctions hits, and agent actions tied to low-confidence entities.

Dun & Bradstreet describe the same operational reality: golden records need survivorship, lineage, stewardship, and exception queues. The overhead is real. The overhead of not doing it is scattered across every team that trusts the directory.

Agents raise the stakes#

Before agents, a person might notice that "Acme US" and "Acme, Inc." feel like the same account. An agent will place an order, open a ticket, or summarize risk with whatever key it was given. IBM's point about agentic systems is the right warning: these systems rely on reliable data for grounding, actions, and decisions, not only for training.

If your vendor and customer matching is weak, do not give an agent write access to procurement, payments, or CRM merges. Fix the identity layer first, or the agent will scale your ambiguity.

The diligence question to ask#

Before celebrating a new integration, ask one question: when this system says it is talking about a vendor, how does it know, and what happens across finance, risk, and support if that answer is wrong?

Due diligence starts at the match. The findings cascade from there.