Post 6 of The Authority Rule Series
“We need to govern our master data better.”
I hear this constantly. Then I ask: “What do you mean by master data?”
Customer records. Product hierarchies. Sales territories. Contracts. Master Agreements. All are called “master data.”
But these are fundamentally different things.
Mixing them up creates governance chaos.
The Four Types
Reference Data: Standards from external authorities.
Currency codes. Country codes. Tax codes. ISO, governments, and regulatory bodies control these. You follow them or you’re non-compliant.
Master Data: Structures and definitions you control.
Your sales territories. Your product hierarchies. Your customer segmentation model. You have complete authority. Nobody outside needs to accept your definitions.
Master Records: Individual entities using your structures.
Customer #12345. Product SKU ABC. Supplier XYZ. These are instances—specific customers, specific products, specific suppliers.
Transactional Records: Events and agreements.
Orders. Contracts. Invoices. Payments. These capture what happened at a point in time.
Why The Confusion Happens
Most systems present these identically.
A dropdown for country looks exactly like a dropdown for sales territory. Customer records and product records live in the same MDM system. Orders and master records both have IDs and create dates. The presentation hides the authority. You maintain all four types. You update all four types regularly. But who has authority over what each means? Completely different.
Where Authority Sits
Reference Data: External authority.
ISO decides currency codes. Your government decides tax rates. SWIFT decides bank identifiers. You can’t redefine these tomorrow. Every external integration breaks if you try.
Master Data: Your authority, typically management.
Restructuring sales territories is a strategic decision. Redefining product hierarchies changes how the business operates. Customer segmentation models reflect business strategy. Management decides these structures. They’re implementing business decisions about how to organize the company.
Master Records: Your authority, typically operational.
Employees create and maintain these records. Sales reps add Customer #12345. Procurement creates Supplier XYZ. Product managers set up SKU ABC. But employees must use the structures above them—they assign customers to sales territories (Master Data) and register them in countries (Reference Data). Operational authority within strategic constraints.
Transactional Records: Captured authority.
The system recorded what happened. The transaction captured the state of master records and reference data at that moment. You can’t change what happened—only correct errors or handle consequences. A 2023 invoice in British Pounds stays in British Pounds even if you change default currency today.
The Governance Implications
Reference Data needs monitoring, not governance.
Watch for external changes. Update systems when standards change. Create guardrails preventing local deviations. No approval workflow needed—you’re following external authority.
Master Data needs governance.
Who approves territory changes? What’s the impact analysis process? How do you communicate changes? Who owns the definitions? Full decision-making framework required. This is strategic governance—management-level decisions about business structure.
Master Records need data quality management.
Is the customer address current? Is the product classification correct? Is the supplier information complete? Stewardship and quality rules, not strategic decisions. This is operational governance—ensuring employees maintain records correctly within the defined structures.
Transactional Records need audit and correction processes.
Was the invoice calculated correctly? Did the payment clear? Is the contract enforceable? You’re verifying what happened, not deciding what should happen.
The Test
Can you redefine what this means tomorrow?
Currency code EUR → No, ISO controls it → Reference Data
Sales territory “Western Europe” → Yes, but management decides → Master Data
Customer #12345 → Employees maintain it, but within constraints → Master Record
Can you delete the customer? Maybe, with business approval, unlikely however, if there are transactions linked to it.
Can you change which territory they’re in? Yes, within the territory structure management defined.
Can you change which country they’re registered in? Only if it’s factually wrong—you can’t override ISO.
Invoice #789 dated 2023 → The transaction happened → Transactional Record
Can you change the amount? Only via formal correction.
Can you change the date? Not the transaction date—it happened when it happened.
Why This Matters
When everything is “master data,” governance becomes impossible.
You’re trying to apply one set of rules to four fundamentally different authority patterns. You over-govern reference data by running ISO standard updates through approval committees. You under-govern master data by treating territory restructures as “data updates.” You confuse master records by not distinguishing structure changes from instance updates. You mishandle transactions by trying to “fix” historical records instead of correcting forward.
Organizations, at times, waste enormous effort applying the wrong governance to the wrong data type because they never distinguished authority patterns.
What This Could Mean For You
Audit your “master data” governance. What are you actually governing? Strategic structures management defines? Operational records employees maintain? Standards you follow? Historical transactions? Each needs different treatment.
Separate reference data monitoring from master data governance. Different owners, different processes, different authority.
Distinguish master data changes from master record updates. Restructuring sales territories is strategic—management decision. Updating Customer #12345’s address is operational—employee task. Don’t treat them the same.
Recognize transactional records as immutable truth. You don’t change what happened. You correct errors or create offsetting transactions.
Use the Authority Rule at each level. Can you redefine it? Do others need to accept? At what organizational level does authority sit? The answers differ by data type.
The Real Framework
The Authority Rule isn’t just master versus reference.
It’s a question you ask at every level: Who has authority to define what this means?
For reference data: External authorities decide. You follow.
For master data: Your organization decides. Typically management—strategic authority over business structure.
For master records: Your organization decides. Typically employees—operational authority within strategic constraints.
For transactional records: The transaction itself decided. It captured what happened at that moment.
Get the authority pattern right, and governance becomes clear.
Get it wrong, and you’re governing everything badly.
The Authority Rule: Can you redefine what this means, and do you need others to accept your definition? If you need others to accept = reference data. If you don’t = master data.
Read the full series at authorityrule.com/
Leave a Reply