Reference data management: the part of your MDM strategy that breaks first

Country code — five systems, five values

Unmanaged

Netherlands

The Netherlands

NETH

NLD

5 variants across ERP, CRM, MDM, BI, staging

Governed in MDM

NL

Netherlands

One authoritative value. All systems join on the same code. Reports work.

Owner: assignedApproval requiredAudit trail

The quarterly report breaks. Not because the customer records are wrong, not because the supplier data is outdated. Because "Netherlands" is stored as "NL" in the ERP, "Netherlands" in the CRM, and "The Netherlands" in the BI staging area, and no tool can join on all three.

The underlying master data is fine. The reference data — the country code list that every entity references — is a mess. And in most organizations, nobody owns it.

What reference data actually is

Reference data is not master data. It is the controlled vocabulary that master data references. Country codes. Currency codes. Units of measure. GL account categories. Product status values. Department codes. Tax class codes. The lookup lists and classification hierarchies that your customer, product, and supplier records point to.

If you have worked with Microsoft MDS, you know these as domain-based attributes. A product record references a "ProductStatus" entity. A customer record references a "Country" entity. Those referenced entities — ProductStatus, Country, UnitOfMeasure — are reference data. Most MDS installations have dozens of them.

Why it is not the same as master data

Master data has a lifecycle. Customers get created, updated, merged, eventually deactivated. Products launch, get revised, get discontinued. Each record has a story you can follow through an audit trail.

Reference data is semi-static. A country code list does not change often. But when it does, the impact is wide. Retire a product status value that 3,000 products still reference and everything that reads those products downstream — your ERP, your BI tool, your API consumers — needs to handle the change. Add a new unit of measure that only one system knows about and imports start failing with validation errors everywhere else.

This is why reference data governance needs to be stricter, not looser, than master data governance. Fewer people authorized to modify values. Every change — including adding a new code — goes through explicit approval. Retired values blocked from assignment to new records.

The MDS migration trap

Organizations migrating off MDS almost always make the same mistake. They plan the migration around their core entities. Products first. Then customers. Then suppliers. Reference data gets written onto a sticky note: "migrate lookup tables later."

Later arrives on day two of the first import job. You try to load 10,000 product records and the import fails on 8,400 of them because the "Unit" field references "PCS" — which exists in MDS — but the new MDM tool only has "Pieces" and "Each" in its Units entity. Nobody migrated the unit of measure list first. Three hours of debugging later, someone realizes the fix is fifteen minutes of data work that should have happened before any products were touched.

Reference data should be migrated and validated before domain entities. Not after. Inverting this order multiplies the cleanup work.

Typical product domain: reference dependencies

Product

ProductStatusUnitOfMeasureProductCategoryTaxClass

Customer

CountryCurrencyCustomerTypeRegion

Supplier

CountryCurrencyPaymentTermsSupplierCategory

Migrate the reference entities first. Domain records import cleanly when the values they reference already exist and are validated.

The spreadsheet is not a governance strategy

When organizations do not put reference data into an MDM tool, it lands somewhere else. Usually a shared spreadsheet, or several competing ones. Finance has a GL account category spreadsheet. Product management has a category hierarchy Excel file. IT has a status code sheet from three years ago.

These diverge. Someone adds a new product category and updates their downstream system without telling anyone else. Six months later the MDM tool and the ERP disagree on what categories exist. Import jobs fail. BI reports show gaps. Analysts spend two days tracing the problem back to a row added in a spreadsheet that has no version history, no change notification, and no owner.

I have seen organizations with four separate "unit of measure" spreadsheets, each maintained by a different team, each treated as the authoritative list by a different system. All four were slightly different. None of them matched what was in the MDS installation. The migration planning meeting where this came to light was not a pleasant one.

What proper governance looks like

Reference data in an MDM tool is modeled the same way as any other entity — it has records, it has attributes, it has permissions and workflows. The governance model is what differs.

Tight write permissions

Only two or three named owners can add, modify, or retire values. Not every data steward. Not anyone with edit access to the domain.

Mandatory approval for every change

Adding a new status value, changing a code description, retiring a GL category — all go through an explicit approval step. No ad-hoc additions.

Retired values blocked from assignment

When a value is retired, the system prevents new records from referencing it. Existing records are flagged for review, not silently broken.

Full audit trail

Who added this code? When was it approved? Who retired it? These questions have answers in the audit log, not in someone's email history.

In Primentra, there is no separate reference data module. Reference entities are regular entities in the model with stricter permissions configured. The same approval workflows that gate changes to products and customers also gate changes to country codes and status values. You do not learn a different system — you apply the same governance tools with a tighter policy.

Where to start

Pick the domain causing the most pain and identify which reference entities it depends on. If it is the product domain, that is usually four things: product categories, unit of measure, product status, and tax class. Get those four entities into the MDM tool first. Define the authorized values. Assign an owner for each. Enable approval workflows.

Then import the product records. You will have far fewer validation failures and far less post-import cleanup because the controlled vocabulary your products reference already exists and is already governed.

Reference data is not glamorous. Nobody pitches it to the CFO. But it is load-bearing. Get it wrong and every domain that references it is fragile. Get it right before you import anything else and the rest of the migration becomes noticeably less painful.

Common questions

What is reference data in master data management?

Reference data is the set of lookup values, code lists, and classification hierarchies that your core master data entities reference. Examples include country codes, currency codes, units of measure, product status values, GL account categories, and department codes. Unlike master data records — which have full lifecycles with creates, updates, and merges — reference data is semi-static. It changes less often, but when it does, the impact is broad: every entity that references a changed or retired value is affected.

How is reference data different from master data?

Master data describes the core entities your business operates on: customers, products, suppliers, cost centers. Each record has a lifecycle — created, updated, merged, eventually retired. Reference data provides the controlled vocabulary those entities use: the country code a customer references, the unit of measure a product uses, the status a supplier record carries. Reference data changes less frequently but affects every entity that references it, so change control needs to be stricter, not looser.

Why does reference data break MDM implementations?

Most MDM implementations focus on the core domains first — products, customers, suppliers — and treat reference data as an afterthought. The lookup lists end up spread across spreadsheets maintained by different teams. Values diverge. Someone adds a new product category in their spreadsheet, downstream systems pick it up, but the MDM tool never learns about it. Six months later, import jobs fail with validation errors because the category exists in the ERP but not in the MDM entity model. Reference data should be migrated and governed before core domain entities, not after.

How should reference data be governed in an MDM tool?

Reference data governance is stricter than master data governance. For master data, you want broad contribution — data stewards create and update records, approval workflows gate changes. For reference data, you want tight control: only a few named owners can add or modify values, every change requires explicit approval, and retired values should be prevented from being assigned to new records. In most MDM tools, including Primentra, reference data is modeled as regular entities with stricter permissions — there is no separate module required.

How did Microsoft MDS handle reference data?

Microsoft MDS (Master Data Services) handled reference data through domain-based attributes and constrained lists. A leaf-level member in one entity could reference an attribute domain defined by another entity — effectively making that second entity a reference data list. Organizations migrating from MDS typically have many such reference entities: country, currency, unit of measure, status, GL account category. These need to be migrated to the new MDM tool and governed before the domain entities that reference them.

Reference data governance included — no extra module required

Primentra models reference data as regular entities with configurable permissions and approval workflows. One tool for your entire data model — domain entities and the lookup lists they reference. The 60-day trial includes everything, including the SQL Server integration and REST API.

Start free trial →Read the docs →