Reference data: what it is and how it differs from master data
Reference data: what it is, how it differs from master data, who owns it, RDM tools, and why governing it prevents integration errors.
Every company has a bunch of lists that look like a detail and that nobody governs. The list of supplier types, the one for order status, units of measure, material groups, countries, currencies, NCM (Mercosur Common Nomenclature, Brazil's tax classification code). Reference data is exactly those lists: the sets of standardized values that classify and give meaning to the rest of the company's data. It seems small. The problem starts when each system has its own version of that list, and then the report doesn't add up, the integration breaks, and the AI learns from a base nobody agreed on.
What reference data is
Reference data consists of sets of permitted values, used to classify, categorize, or standardize other data. It works as the company's official vocabulary. When a master record says the material belongs to the material group "MRO," the currency is "BRL," the unit is "UN," and the country of origin is "BR," each of those values comes from a reference list.
The defining characteristic of reference data is that it's a closed-domain value. There is a finite list of valid options, and the data can only take a value within it. Country follows the ISO 3166 standard. Currency follows ISO 4217. NCM follows the table from the Receita Federal (Brazil's federal tax authority). The chart of accounts follows the company's accounting structure. These are data that change little, apply to the entire organization, and are shared by several systems at the same time.
In practice, reference data is what turns a free-text field into a reliable field. Without it, the analyst types "unit," "un," "und," "piece," and "pc" to say the same thing. With it, there is a single list, and the system only accepts what's on it.
Reference data and master data: the difference that confuses everyone
This is the most common question from people entering the field, and it's worth separating clearly. Master data is the company's business entities: the supplier, the customer, the material, the product, the employee. These are the central master records, with many attributes, that support transactions. Reference data is the lists of values that classify those master records and those transactions.
An example makes it clear. The supplier "Metalúrgica São Jorge Ltda" is master data. The "supplier type" field inside its record, which can only be "domestic," "foreign," or "intercompany," is reference data. The material "M8 hex bolt" is master data. The material group and unit of measure of that material are reference data.
The practical difference lies in volume and frequency of change. Master data is large, grows every day, and changes with every new record. Reference data is small, changes rarely, and when it changes, it changes for the whole company at once. Changing a tax code or adding a new material group is a governance decision, not just any record. Anyone who has taken part in an SAP project knows that domain tables and value lists are usually treated as configuration, and that's exactly why nobody takes responsibility for them.
How reference data works in practice
The central point of managing reference data, or Reference Data Management, is having a single official list for each domain, published to all systems from a reliable source. Instead of keeping the list of supplier types duplicated in the ERP, the procurement system, the tax system, and an analyst's spreadsheet, you maintain one governed version and distribute it to the others.
This solves a silent problem that shows up a lot in companies: the same concept represented by different codes in each system. The ERP uses "01" for legal entity, the CRM uses "PJ," the tax system uses "J." Each is right within its own world, but when it's time to integrate, someone needs to build a crosswalk. And that crosswalk becomes a hidden piece of code that nobody documents, that breaks when a new value comes in, and that nobody can explain six months later.
Managing reference data well means three things. First, defining the official list for each domain and who can change it. Second, maintaining the mappings between internal codes and external standards, such as ISO, NCM, and CFOP (Brazil's tax operation code), so that different systems can talk to each other. Third, versioning the changes, because when a code stops being valid or is replaced, historical data still points to it and must keep making sense in the report.
Who takes care of reference data
Here lies a common problem. Reference data is usually no man's land. Because it looks like system configuration, the business thinks it's IT's responsibility, and IT thinks it's the business's decision. In the end, the list grows without criteria, picks up duplicate values, and nobody cleans it.
In mature governance, each reference domain has a clear owner. The chart of accounts belongs to finance. Tax codes belong to the tax team. Material groups and units of measure usually sit with procurement or with the master data team. The data steward's role is to operationalize this: maintain the list, evaluate requests for additions, prevent duplication, and ensure that the change is communicated to those who consume that data. The data owner, generally a business area leader, is the one who approves what comes in and what goes out.
What few people realize is that poorly governed reference data has a direct impact on the business. A new unit of measure created without criteria breaks inventory conversion. A wrong tax code creates tax risk. A messy material group destroys the analysis of purchasing spend and the ability to negotiate with suppliers. It's not just a record maintenance matter. It's margin, risk, and decision-making.
Which tools help manage reference data
The market has specific platforms for this, some dedicated to Reference Data Management and others that bring RDM as part of a larger governance and MDM solution. Among the most cited are Collibra, which has its own reference data module integrated with the catalog, SAP Master Data Governance, which handles code lists and domains within the SAP ecosystem, Semarchy, Informatica, Ataccama, Stibo Systems, and Profisee. Each solves the core of the problem in its own way, but all start from the same idea: one official source, versioned mappings, and controlled distribution to the systems that consume.
Here's a warning I tend to repeat. A tool helps, but it doesn't replace the governance decision. Buying an RDM platform without defining who owns each list and what the change process is only organizes the mess better. Technology comes in after the company has agreed on what's right, not before.
How to learn and grow in the field
The study path for anyone who wants to master reference data starts with understanding the larger context of data management. DAMA's body of knowledge, the DAMA-DMBOK, treats Reference and Master Data as one of the knowledge areas, and it's foundational reading for anyone who takes this seriously. The CDMP certification, also from DAMA, is the market reference for validating that knowledge in a structured way.
In practice, anyone who wants to truly learn should start by looking at the domain lists of the company where they work. Take the material group table, the supplier type table, or the tax code table and ask: does this list have an owner? Does it have duplicates? Is it the same in all systems? This simple exercise teaches more than many theoretical courses, because it shows the problem happening in the real world.
Career opportunities
Reference Data Management is one of those competencies that almost nobody puts on a resume and that makes an enormous difference in the daily work of a data professional. Whoever understands reference data understands integration, quality, and governance at the same time, because this topic touches all three.
Demand for governance and master data professionals has been growing consistently, driven by SAP S/4HANA migration projects, data quality programs, and now the race for artificial intelligence inside companies. Roles such as data steward, master data analyst, governance specialist, and data quality analyst call for exactly this kind of knowledge. It's a field with few qualified people and growing demand, which usually translates into good pay and stability for those who specialize.
Main questions
Is reference data the same thing as master data? No. Master data is the business entities, such as customer, supplier, and material. Reference data is the lists of standardized values that classify those master records, such as country, currency, unit of measure, and supplier type. Both are part of data management, but they differ in volume, owner, and frequency of change.
Can reference data be internal and external? Yes. There is external reference data, which follows public standards such as ISO, NCM, and CFOP, and internal reference data, created by the company itself, such as risk categories, contract types, or internal statuses of a process.
Why does reference data cause integration problems? Because the same concept usually has different codes in each system. When there is no official list and no governed mapping, each integration creates its own crosswalk, which breaks as soon as a new value comes in.
Who should own reference data? Each domain needs an owner in the business. Finance for the chart of accounts, tax for tax codes, procurement or master data for material groups and units of measure. The data steward operates the list and the data owner approves changes.
Do I need a specific tool to manage reference data? It helps, but it's not the first step. Before the tool, you need to define the official list for each domain, who approves changes, and how they're communicated. Technology organizes and automates that after governance has been agreed upon.
MDM Academy
MDM Academy is 4MDG's school of governance and master data. It was born to solve a problem I see in almost every company: there aren't enough people who understand master data, reference data, quality, and governance in a practical way, connected with the reality of SAP, procurement, supply chain, and master record maintenance. The training translates technical concepts into business impact, with real examples and accessible language, so that professionals come out able to act, and not just to repeat theory.
If you work with master data, data, procurement, or technology and want to position yourself in a field that only keeps growing, it's worth getting to know MDM Academy and joining the Data Club, where we share content, discussions, and practice on governance and master data with people who live these challenges every day.
Conclusion
Reference data is the kind of subject that looks small until the day the report doesn't add up, the integration breaks, or the AI makes a wrong decision because each system understood "supplier type" in its own way. These are short lists that change little, but they sustain the coherence of everything the company does with data. Governing them well costs little and prevents a lot. The first step isn't buying a tool, it's looking at your own domain lists and asking who owns them. At most companies, that question still has no answer.
Want to become a data governance specialist? Talk to our specialists now and get to know MDM Academy
I want to be a student
