Data Authority Rule

Tag: Enterprise Architecture

  • Master Data, Master Records, and Transactions: The Distinction That Clarifies Everything

    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/

  • Master Data vs Reference Data: The Line That Actually Matters

    I’ve never been confused about exchange rates being master data. At my first company, we had something called the USC – US Control Dollar. Set once a year. Used for all cost and profit accounting. Completely under our control.

    That early experience gave me an instinct about data authority that I could never quite articulate. It led to countless frustrating conversations where I KNEW the answer but couldn’t explain WHY.

    Last week, thinking about a data model, I started thinking about this distinction more deeply, what was it that I knew but could not articulate. Then on a hike along the Thames Path, it finally clicked.

    The Moment of Clarity

    The USC taught me something fundamental: we had complete authority over that rate. It didn’t matter that exchange rates “came from outside” – WE decided:

    • When to set it (once a year)
    • What source to use
    • How to apply it

    That’s master data. We had the authority.

    But try explaining that intuition when someone insists “external source = reference data.” You end up in circular debates.

    Walking past fields (and yes, horses), thinking about data classifications, I finally found the words for what I’d always known:

    It’s about authority. Who has the power to define what something means?

    The Authority Test

    Once I had the words, I tested it on everything I could think of. Here’s the test:

    Can you redefine it and do you need others to accept your definition?

    • If you can redefine it and only you need to accept it → Master Data
    • If you can’t redefine it OR others must accept it → Reference Data

    No exceptions yet.

    Why This Matters Beyond Theory

    Every migration, every system design, the same circular arguments:

    “Exchange rates – that’s reference data because we’re told it from outside.”

    “No, this is reference data because it’s in a dropdown table.”

    “Tax rates changed and we had to update loads of systems, so it must be master data.”

    No. Tax rates are reference data – the government has authority. The pain of updating doesn’t change who owns the definition.

    An old one but a favorite: “We need a governance process for adding currencies.”

    Really? When did we last add a currency? The Euro was a project that took years. New currencies don’t just appear on Tuesday afternoons. And for adding a currency to a drop down table does it need a governance process?

    The Confusion Patterns

    Through testing, I found the same confusion patterns repeatedly:

    “We maintain it, so it’s master data”

    No. You maintain local copies of country codes too. Maintenance isn’t authority.

    “It changes frequently, so it’s master data”

    No. Tax rates change all the time. The government still has authority.

    “It’s a small lookup list, so it’s reference data”

    No. Your cost center list might be tiny and static. You still have complete authority over it.

    “It comes from outside, so it’s reference data”

    Not always. Customer names might come from external sources, but once they’re in your system, you have authority to correct spellings, update addresses, mark them inactive. That’s master data you’re maintaining.

    But Dun & Bradstreet numbers? You can’t change those – they’re reference data. D&B has the authority.

    The Choice Point

    Sometimes you get to choose:

    • Create your own party types → Master data (your authority)
    • Adopt ACORD standards → Reference data (their authority)
    • Build your own product hierarchy → Master data
    • Use GS1 standards → Reference data

    The framework helps you understand what you’re choosing: control and flexibility (master) versus interoperability and standardization (reference).

    Testing the Edges

    I always test frameworks on something completely unrelated to see if they’re robust. This time: horses.

    I rode for 16 years, so I know this domain:

    • Racing names? Jockey Club has authority → Reference data
    • Stable nicknames? You choose → Master data
    • Breed standards? Registry decides → Reference data

    The framework held. If your data architecture principle works on horses, it’s probably universal.

    Why Exchange Rates Break People’s Brains

    “But exchange rates come from external sources!”

    Yes. But there’s no single authority. You choose:

    • Which source (Reuters vs Bloomberg)
    • What timing (spot vs close)
    • What adjustments to apply

    You have authority over YOUR rate. That makes it master data.

    Try telling banks that USD now means something else. You can’t. That’s reference data.

    The Real Implications

    This isn’t academic. I’ve seen migrations fail because people put exchange rates in reference data stores that couldn’t handle daily updates. I’ve seen programs waste time discussing how to manage country codes that should have been in a simple reference table.

    When you understand authority, you know:

    • What needs real-time integration (master data under your control)
    • What needs governance (what you have authority over)
    • What needs monitoring (reference data you must comply with)
    • What can be cached (reference data that rarely changes)

    The Simple Pattern

    Every complex system hides a simple pattern. This one is about authority and control boundaries.

    Reference data is what the world gives you.

    Master data is what you create to run your business.

    Or put another way:

    • Ignore reference data → you break compliance, law, or interoperability
    • Mismanage master data → you break your business processes

    The Challenge

    This framework is simple. Maybe too simple. But complex systems often have a simple pattern at their core.

    So here’s my challenge: Find me a case where this breaks.

    Where does authority become ambiguous? Where does the test fail?

    Because if we can find where it breaks, we can make it stronger. And if we can’t, then maybe we’ve finally found the simple pattern that was hiding in plain sight all along.

    Think you’ve found an edge case? Direct message me on LinkedIn.