Reference data

What is reference data?

Reference data is the set of shared lookup values that give the rest of your data meaning: country codes, currencies, languages, order statuses, VAT codes, units of measure, product categories, and industry codes. It sits behind almost every record without being the record itself.

Two traits make it distinctive. It changes slowly, and it is small in volume but wide in reach. A country list has a couple of hundred rows, yet one wrong entry can misgroup thousands of invoices. An invoice with country BE, currency EUR, and VAT code 21 only processes correctly when every system agrees on what those codes mean.

A lot of reference data is not yours to invent. External reference data comes from a standards body or regulator: ISO 3166 for country codes, ISO 4217 for currencies (maintained by SIX, with a three-letter and a three-digit code each), NACE for industry classifications, or SIC and NAICS in the United States. You track the official list and adopt its updates rather than deciding what a value means. Internal reference data is the controlled lists you own instead, such as order statuses, reason codes, and customer segments, where you set what exists. External lists are mainly a versioning problem, internal lists mainly a definition-and-ownership problem.

Reference data versus master data

Reference data and master data are easy to confuse because both are steadier than daily transactions, and frameworks like DAMA-DMBOK group them into a single discipline. They are not the same thing.

Master data describes the core business entities your organisation keeps referring to: customers, products, suppliers, employees. Reference data describes the shared classifications those entities and their transactions point at. A product is master data. The product category, unit of measure, and country of origin attached to it are reference data. A customer is master data; the segment and risk class you assign are reference data.

Transactional data is the third layer: the high-volume events such as orders, payments, and shipments that reference both. Transactions change constantly, master data changes occasionally, and reference data barely moves. Getting the reference layer right is often what makes master data management and a clean data warehouse possible, because the codes are what let three systems agree they are describing the same thing.

Why code lists drift, and how that breaks history

Reference data feels permanent, which is exactly why its changes are dangerous. Codes get retired, reused, and reclassified, and each of those quietly breaks any report that assumes a code always meant one thing.

Reuse. The two-letter code CS under ISO 3166 was used for Czechoslovakia until it split in 1993. A decade later the same code was assigned to Serbia and Montenegro, which itself dissolved in 2006. A historical record tagged CS means two different countries depending on the year. Deleted codes now live in ISO 3166-3, and the standard reserves a retired country code for at least fifty years before it can be reassigned, precisely to limit this kind of collision.

Retirement. When the euro replaced the Belgian franc, the code BEF was withdrawn from the active ISO 4217 list and moved to its historical list, kept only so that older transactions still resolve. A validation rule that accepts current currencies alone will reject a genuine record from before 2002.

Reclassification. Industry codes get renumbered between revisions. NACE Rev. 2.1 became official in 2023 and applies to European statistics from 2025, and some activities move from one class to another between Rev. 2 and Rev. 2.1. A year-over-year report grouped by industry code can show a jump that is pure reclassification, not real change, which is why Eurostat publishes correspondence tables and runs both versions in parallel during the switch.

The defence is to treat a code list as versioned rather than current. Store an effective-from and effective-to date for each value, record which revision a row was classified under, and never silently remap old codes to new ones. This is the same reasoning behind slowly changing dimensions in a warehouse: history has to stay readable in the terms that were true at the time.

Managing reference data well

Good reference data management is mostly about ownership and one place of truth.

• Give every list an owner. Someone has to decide which values exist, what they mean, and when they change. Finance usually owns VAT and cost codes, operations owns product categories.

• Keep one system of record. When every report holds its own copy of the status list, the copies drift apart. Manage each list centrally, or synchronise it on purpose rather than by accident.

• Validate at the door. A currency field should accept only values from the ISO 4217 list, a status field only codes from its own list. That stops free-text variants like cancelled, canceled, and CANC from piling up and becoming a data quality problem later.

• Version instead of overwrite. Add new codes, retire old ones with an end date, and document what each value meant. Whether a list is a small internal code set or an adopted external standard, the same discipline applies.

Who signs off on those changes is a data governance question, and the metadata around each list, its owner, its source, and its valid dates, is what keeps the list usable years later.