The Registry of Things, Places, and Suppliers

Opening Scene

The citizen register isn’t the only ledger a city maintains. There’s a property ledger tracking every parcel of land and building, with its own boundaries and ownership history. There’s a licensed-suppliers list tracking every contractor and vendor the city does business with, each with its own registration, tax status, and performance record. And there’s a gazetteer — the official list of street names, district boundaries, and place names — that every other office has to agree on, because “Main Street” means nothing useful if three offices each have a different idea of where it starts and ends. Each of these registers has its own quirks, but all of them follow the same discipline as the citizen register: one office, one canonical file, and everyone else deferring to it.

In Plain English

Beyond customer master data, three other domains show up in nearly every MDM program: product master data (a company’s canonical catalog of what it sells or makes, reconciled across engineering, sales, and fulfillment systems that each describe products slightly differently), vendor master data (the canonical record of every supplier a company does business with, reconciled across procurement, finance, and compliance systems), and location master data (the canonical set of physical places — stores, warehouses, service regions, addresses — that other master data references, ensuring “the Chicago warehouse” means the same specific place everywhere it’s mentioned).

The Old Way

Each of these three domains carries its own distinct challenge, separate from what customer data faces:

• Product master data’s challenge is structural complexity — a product often has variants, bundles, and hierarchical categories (a specific SKU rolling up to a product line, rolling up to a category), and different systems frequently model that structure differently, making product matching as much a structural reconciliation problem as a field-matching one.
• Vendor master data’s challenge is verification and risk — a vendor record isn’t just reconciled for consistency, it often needs to be validated against external registries for tax compliance, sanctions screening, or financial risk, giving vendor MDM a compliance dimension that customer and product data don’t carry in the same way.
• Location master data’s challenge is that it’s often the quiet dependency everything else assumes is already solved — customer records reference addresses, vendor records reference facilities, product records reference warehouses, and if location data itself isn’t standardized and deduplicated first, every domain that references it inherits the same inconsistency.

Because location data underpins so much of the other domains, many mature MDM programs deliberately get location reconciliation right early, even before tackling product or vendor data in full.

What’s Changing (and Why AI Is the Reason)

1. AI-assisted matching can reconcile product records across systems that describe the same item with wildly different structures — a manufacturing system’s part number, a sales catalog’s SKU, and a supplier’s own item code — by learning from descriptive attributes like dimensions, materials, and category text rather than relying on any single shared code.
2. AI-assisted vendor screening can continuously cross-reference vendor master data against external compliance and risk sources, flagging changes — a sanctions list addition, a tax status change — far faster than a periodic manual review cycle ever could, turning vendor master data governance from a point-in-time check into an ongoing, monitored process.
3. AI-assisted address standardization and geocoding can reconcile location data far more reliably than rule-based address parsing, correctly recognizing that “123 Main St, Suite 4” and “123 Main Street, #4” describe the same physical place even across inconsistent formatting conventions, which strengthens every other domain that depends on location as a foundation.

The Metaphor, Fully Extended

Registry Element	Master Data Management Concept
The property ledger, tracking parcels, boundaries, and structural detail	Product master data, with its own structural complexity of variants and hierarchies
The licensed-suppliers list, cross-checked against tax and compliance status	Vendor master data, carrying a compliance and risk dimension beyond simple reconciliation
The gazetteer of official street and district names every office defers to	Location master data, the shared foundation other domains reference
A property parcel referenced inconsistently across the tax ledger and the utilities ledger	Product records described inconsistently across manufacturing, sales, and fulfillment systems
A registry assistant cross-checking the supplier list against a national sanctions registry automatically	AI-assisted vendor screening, continuously monitoring compliance and risk status

Quick Recap

• Product, vendor, and location master data are the three other domains that show up in nearly every MDM program alongside customer data.
• Each carries a distinctive challenge: product’s is structural complexity, vendor’s is compliance and risk, and location’s is being a quiet, foundational dependency for the others.
• AI-assisted matching, continuous compliance screening, and address standardization each address the distinctive challenge of one domain particularly well.
• Because location data underpins so much of the rest, many mature MDM programs prioritize getting it right early.

Where This Fits in the Series

Article 7 covered customer master data; this article extended the picture across product, vendor, and location. Article 9 addresses a distinction that cuts across all four domains: the difference between a system of record and a system of reference.