Data Authority Rule

Author: Charlotte Malmberg

  • Is there a hidden cost in vendor contracts: Reference Data?

    Micronesia potentially broke our system.

    Not catastrophically. Just… wrong. A Business Analyst flagged it. One potential data mismatch in a system we’d already used for years, now maybe causing issues with data mapping.

    It reminded me of the Sweden/El Salvador disaster from Post 2. A Swedish developer picked “SV” for Sweden, not knowing ISO had assigned it to El Salvador. Years of mapping tables to fix someone else’s assumption.

    Over the weekend, I started thinking about every procurement process I’d been part of.

    We never evaluated reference data standards.

    Not once.

    What I Evaluated (And What I Missed)

    At EDS, I evaluated vendor systems as the business expert on procurement teams. At Catalyst Housing, I led procurement projects.

    We checked everything. Functionality. Integration architecture. Security. Implementation timeline. Commercial terms. Vendor stability.

    Everything except reference data standards.

    Not because I didn’t care. Because it seemed obvious they’d be right.

    The Impact Cascade You Didn’t Price In

    When a vendor doesn’t use ISO standards, you’re not just buying “some integration work.” You’re buying consequences that ripple through your entire technology estate.

    Initial impact: Someone builds mapping tables. Vendor codes to ISO. Every vendor update/upgrade, you might need to update the mappings. Every ISO change, you update. Forever.

    Your compliance checking service uses ISO standards. Now you need transformation logic. Test cases. Exception handling. What happens when the mapping fails?

    Every new integration: Another mapping layer. More transformation logic. Compatibility testing with existing mappings. Documentation updates that future teams will need.

    Every new vendor: Three vendor systems, three different definitions of “Micronesia”. System A: “Micronesia”. System B: “FM” (ISO code, wrong mapping). System C: “FSM” (wrong definition). Three mapping tables. Not to ISO—to each other. Testing matrix multiplication. Exception handling for mismatches between systems.

    Test automation becomes a nightmare. Which version of “Micronesia” does each test case need? Mock data must account for every vendor’s definitions. Automated regression suites fail when mapping changes. CI/CD pipelines need transformation validation. Every automated test touching reference data needs vendor-specific variants.

    Operational impact: Support tickets when data doesn’t match. Manual workarounds when automation fails. Training new team members on “why we do it this way”. Knowledge loss when key people leave.

    Compliance and audit: Explaining to regulators why systems define data differently. Control weakness findings. Remediation plans. Annual re-findings when nothing fundamentally changes.

    Strategic constraints: New compliance requirements require integration work before implementation. New analytics platforms need mapping before they’re useful. API integrations to partners delayed by transformation complexity. Technical debt that makes every future decision harder.

    The costs aren’t just money. They’re velocity. Opportunity. Strategic flexibility.

    And they compound forever.

    What Should Change

    This should be an explicit evaluation criterion. Not buried in technical architecture review. Not assumed. Scored.

    Before vendor selection, ask which reference data standards they use. ISO 3166 for countries. ISO 4217 for currencies. ISO 639 for languages. Industry standards like ACORD, SWIFT, HL7.

    Then ask how they maintain them. Automatic feed from authoritative source? Manual updates—how often, who’s responsible? Custom definitions—where’s the documented mapping?

    Ask where they deviate from standards. Which entities use non-standard codes? Why? Legacy system? Customer request? Deliberate choice? What’s the mapping approach? Only in the UI?

    Ask how they handle updates. New country codes from ISO? Currency changes like Bulgaria joining the Euro? Deprecated codes?

    Ask what integration support they provide. Pre-built mappings to standards? Documentation of code definitions? Transformation services?

    If vendors can’t answer clearly, price in the integration cost.

    Why I Didn’t See This Coming

    I studied Economics. You use ISO country codes, ISO currency codes, standardized data definitions. Otherwise analysis is impossible. You can’t compare GDP across countries if everyone defines “country” differently.

    Most systems do use ISO standards. Countries. Currencies. Languages. All the reference data is correct.

    When your academic background and your first decade of professional experience both assume standards compliance, you don’t question it.

    Why would you? These are professional software vendors building enterprise systems. This is foundational.

    Except it’s not foundational to everyone.

    I didn’t think to ask during procurement because I’d never encountered a system that got it wrong.

    The Conversation with Procurement

    If you’re a Business Architect, Enterprise Architect, or data professional reading this, you might be thinking: “Yes! This! How do I get procurement to care?”

    Frame it as risk management, not technical detail.

    “We’re evaluating a vendor that could create ongoing integration costs because they don’t use industry standards for reference data. Should we price this into the commercial negotiation?”

    Make it a standard RFP question.

    “I drafted some questions about reference data standards compliance. Could we add these to the technical architecture section of our RFP template? It’ll help us identify hidden costs earlier.”

    Show the business impact.

    “Three vendor systems define countries differently. When we try to implement compliance checking, we’ll need months of integration work. Could we evaluate reference data standards in future procurements to avoid this?”

    Offer to help.

    “I can review technical architecture sections of vendor responses specifically for reference data compliance. It takes me thirty minutes per vendor and could save us significant integration costs.”

    Don’t make it about governance. Don’t make it about data purity. Make it about cost, risk, and integration complexity.

    Procurement teams manage cost and risk every day. Give them the business case.

    What I’d Do Differently Now

    If I were leading a procurement initiative today, reference data standards would be an explicit evaluation criterion.

    Not a nice-to-have. A scored requirement.

    Compliant with ISO/industry standards: Full marks.

    Custom codes with documented mapping: Partial marks, priced accordingly.

    Custom codes with no mapping plan: Major red flag.

    Because I’ve seen the costs. I’ve watched integration projects stall on data transformation. I’ve heard of test automation grinding to a halt because mock data needs multiple versions for the same country.

    The Authority Rule taught me: You don’t own reference data. But you own the consequences of choosing vendors who pretend they do.

    What You Can Do

    If you’re in procurement: Add reference data standards compliance to your evaluation criteria. Ask vendors to document their approach. Price non-compliance into commercial terms.

    If you’re a Business Architect or Enterprise Architect: Review your vendor landscape. Document which systems use non-standard codes. Quantify the integration impact across the areas that touch: transformation, testing, operations, compliance, strategy. Take this to procurement with a business case.

    If you’re a vendor: Understand that your customers pay forever for your architectural choices. Using ISO standards isn’t gold-plating. It’s reducing your customers’ total cost of ownership.

    If you’re buying systems off the shelf: Before you sign that contract, ask: “Which reference data standards do you use?” If they can’t answer clearly, you’re buying technical debt.

    The Micronesia conversation started this thinking. But it applies to every vendor system that doesn’t use reference data standards as its internal keys.

    The costs are hidden. The consequences are long-term. And the decision is made during procurement, often without anyone realizing it matters.

    I didn’t realize it earlier in my career.

    I realize it now.

    This post is part of The Authority Rule series exploring how authority patterns determine data classification and governance. The framework emerged from real-world experience building enterprise data architecture across multiple industries.

    Read the full series at authorityrule.com/

  • Contracts: The Fifth Authority Type

    Post 8 of The Authority Rule Series

    Something didn’t fit.

    I’d mapped out four authority types: Reference Data (external authority), Master Data (internal strategic), Master Records (internal operational), and Transactions (captured events). The framework worked well—until I hit contracts. Then nothing lined up cleanly.

    Contracts.

    They’re not quite transactions.

    A payment transaction records an event—it happened on 15 December. A contract defines terms that govern the behavior, i.e., when and how often payments are due.

    Contracts are a fifth authority type: Contractual Authority.

    What Makes Contractual Authority Different

    Contractual authority is bilateral or multilateral binding agreement.

    Neither party can unilaterally change it. Your customer can’t rewrite the terms. You can’t rewrite them either.

    Both must follow what was signed. Courts arbitrate disputes—when parties disagree on what the contract means, external authority interprets. Just like ISO interprets currency standards, courts interpret contractual terms.

    It creates shared authoritative terms. Within the relationship, the contract functions as reference data both parties must follow. But unlike ISO standards, it only binds the signatories.

    It’s immutable as a document.

    Why This Matters in Insurance

    I work in P&C insurance.

    This distinction is fundamental to how we operate.

    The policy document is contractual authority. It defines coverage, exclusions, limits, terms.

    Once signed, both insurer and insured must follow it. Claims adjusters can’t just decide to pay something the policy excludes—they’re bound by the policy terms. Courts interpret ambiguous clauses when disputes arise. The contract governs what happens, not internal policy changes made after signing.

    Premium payments are transactions.

    They record what happened under the policy terms. Insured paid £500 on 1 January—that’s captured authority, it happened.

    Claims are transactions governed by contractual authority. The claim event happened (transaction). Whether it’s covered depends on the policy terms (contractual authority).

    Coverage definitions start as master data. Before the policy is sold, your coverage tiers, exclusions lists, and limits are internal master data. Management can change them tomorrow for new policies.

    But once signed into a policy, they become contractual authority.

    Now you can’t unilaterally change those definitions for this customer.

    When Master Data Transforms

    I see this transformation constantly.

    Your product codes are master data. You control your product hierarchy. Management can restructure it tomorrow for new customers.

    But write those codes into a multi-year supplier agreement?

    Now they’re contractual authority. You can’t just “update the product hierarchy” without renegotiating contracts.

    Your pricing structure is master data.

    You decide how to price your services. But sign a three-year SLA with fixed prices? Those prices are contractual authority—you’re bound by what you signed.

    Your service levels are master data. You define what “standard support” means internally. Include those definitions in customer contracts? They’re now contractual authority. The customer can hold you to your own definitions. Not your updated definitions—the ones you agreed to.

    Your coverage tiers in insurance are master data internally. Define Bronze, Silver, Gold however you want. But underwrite a policy using those tiers? Contractual authority for that policy’s lifetime.

    The Governance Trap

    Companies miss this transformation all the time.

    They see “master data change.”

    They miss “contractual authority impact.”

    Insurance company decides to update their household policy terms to exclude flood damage in high-risk zones. Sounds like a master data change—management decision, internal authority. But tens of thousands of existing policies have already been sold. Those are contractual authority. You can’t retroactively change coverage for signed policies—the old terms remain in force until renewal.

    What looks like a simple master data update is actually dual governance.

    New master data (updated policy template). Existing contractual authority (signed policies unchanged). You’re managing two versions until policies renew.

    Software company restructures product hierarchy—”Enterprise” tier splits into “Enterprise Standard” and “Enterprise Plus.” Management approved. Seems straightforward.

    But hundreds of enterprise customers have contracts.

    Those contracts reference “Enterprise” with specific feature lists. Contractual authority.

    You need contract amendments or grandfather clauses—not just a product hierarchy update.

    The Test for Contractual Authority

    Can you unilaterally redefine this tomorrow?

    Your product hierarchy → Yes, management decides → Master Data

    ISO currency codes → No, ISO decides → Reference Data

    Signed contract terms → No, both parties agreed → Contractual Authority. The signed contract happened at a point in time—an immutable document, captured like a Transaction. But it creates ongoing binding authority, governs future behavior—unlike a Transaction.

    Do others need to accept your redefinition?

    Your sales territories → No, internal only → Master Data. Signed policy coverage → Yes, customer and courts must accept → Contractual Authority.

    The Five Authority Types

    External Authority (Reference Data):

    • ISO, governments, regulators decide
    • Universal or industry-wide
    • You follow or you’re non-compliant
    • Example: Currency codes, tax rates

    Internal Strategic Authority (Master Data):

    • Management decides
    • Internal to your organization
    • You can redefine unilaterally
    • Example: Sales territories, product hierarchies

    Internal Operational Authority (Master Records):

    • Employees maintain within structures
    • Day-to-day operations
    • Must follow master data and reference data
    • Example: Customer #12345, Product SKU ABC

    Captured Authority (Transactions):

    • What happened at a moment
    • Immutable as an event
    • Records the state of other data types
    • Example: Invoices, payments, claims

    Contractual Authority (Contracts):

    • Bilateral/multilateral binding agreement
    • Neither party can unilaterally change
    • Courts arbitrate disputes
    • Transforms your master data into binding terms
    • Example: Policies, SLAs, supplier agreements

    Each pattern requires different governance. Reference Data: Monitor and comply. Master Data: Management approval and impact analysis.

    Master Records: Operational quality management.

    Transactions: Audit and correction processes. Contractual Authority: Legal review, negotiation, and amendment processes. Don’t treat contract changes like data updates.

    What This Means Monday Morning

    Before signing contracts, review what master data you’re binding.

    Product codes, pricing structures, service definitions—once they’re in signed contracts, they’re no longer just internal master data. You’ve transformed them.

    Distinguish policy documents from policy transactions.

    The policy is contractual authority. Premium payments are transactions under those terms.

    Recognize you’re managing two versions.

    New master data for future contracts. Existing contractual authority for signed agreements. Both need governance, but different governance—don’t confuse updating your product catalog with amending hundreds of customer contracts.

    When updating master data, audit contractual impact. Which signed contracts reference this? Do you need amendments? Grandfather clauses? Migration plans?

    Don’t treat contract changes like data updates.

    Amending contractual authority requires negotiation, not just management approval.

    The PDF Problem

    Here’s where this gets practical.

    The five authority types matter operationally.

    Most contracts are PDFs.

    Unstructured.

    Unqueryable.

    You want to restructure your product hierarchy. Management approves. Seems like a straightforward master data change. But which contracts reference those products?

    You can’t query PDFs.

    Someone has to manually read hundreds of contracts.

    Or worse, you just make the change and hope nothing breaks.

    You can’t ask “which contracts reference our Bronze coverage tier?” You’d have to read every policy document manually. You can’t analyze “what’s the impact of retiring product code PROD-100?” No database knows which contracts bind that code. You can’t audit “how many policies still use the old service level definitions?” The data exists in PDFs, not in queryable systems.

    So when management wants to change master data, you can’t assess contractual authority impact.

    You’re governing blind.

    This is why AI tools that can extract contract data into structured formats like JSON, XML, or something else are becoming more common.

    Tools that read PDFs, extract key terms, and make them queryable. It’s not a perfect solution—retrofitting is messy—but it’s better than nothing.

    Insurance is slowly moving in this direction. Contract extraction tools. Structured policy data initiatives.

    But most industries are still drowning in PDFs, unable to analyze which master data has transformed into contractual authority.

    The framework shows why this matters. Being able to query your contracts would make it actionable.

    Why The Five Types Matter

    The Authority Rule started simple: Can you redefine it? Do others need to accept?

    But every time I used it, I kept finding five patterns, not two: External (you follow), Internal Strategic (management decides), Internal Operational (employees execute), Captured (what happened), Contractual (bilaterally binding). Each pattern requires different governance—you can’t apply the same rules to all five types.

    Reference Data: Monitor and comply.

    Master Data: Management approval and impact analysis. Master Records: Operational quality management. Transactions: Audit and correction processes.

    Contractual Authority: Legal review, negotiation, and amendment processes.

    Get the authority pattern right, and governance becomes clear. Treat a signed contract like master data that you can change? Expect lawsuits. Treat your internal product hierarchy like contractual authority requiring customer approval? Paralysis.

    This framework isn’t about data formats. It’s about authority patterns.

    And contracts proved I needed a fifth type to capture bilateral binding authority.

    The Authority Rule: Can you redefine what this means, and do you need others to accept your definition? The answer reveals which authority pattern you’re dealing with.

  • When Bulgaria Joins the Euro: Four Types of Data, Dozens of Decisions

    Post 7 in The Authority Rule Series

    On 1 January 2026, Bulgaria joins the Eurozone.

    The European Council decided. The conversion rate is set: 1.95583 Bulgarian Lev per Euro. BGN phases out.

    You cannot change any of this.

    But if you do business with Bulgaria—or your systems handle Bulgarian data—you have dozens of decisions to make. And if you treat this as “just a reference data update,” you’ll miss most of them.

    The Reference Data Changes (Non-Negotiable)

    Three things happen on 1/1/26 that you cannot control.

    BGN and EUR exist as ISO 4217 currency codes. ISO decides. You follow.

    The official conversion rate is 1.95583. EU Council set it. Every regulated entity must recognize it.

    Bulgaria adopts EUR on 1 January 2026. The date is fixed. BGN ceases as an active currency.

    This is reference data. External authority. You follow or you’re non-compliant.

    For Acme Ltd, your Bulgarian customer: They’re in Bulgaria (ISO 3166 country code). Bulgaria = BGN until 1/1/26, then = EUR. The EU decided. Acme didn’t get a vote. You didn’t get a vote.

    The Cascade Effect

    One reference data change triggers decisions across four data types.

    Reference Data: Bulgaria joins Euro, rate set (EU authority). Master Data: Do we restructure territories? Change pricing models? (Management authority). Master Records: Update customer currency fields? Change supplier payment terms? (Operational authority). Transactional Records: How do we handle open invoices? Active contracts? Historical data? (Business policy for immutable truth).

    Every layer requires different authority, different owners, different decisions.

    Master Data Decisions (Strategic Authority)

    Management needs to make strategic decisions about business structure.

    Do you restructure sales territories? Maybe you’ve had “Eastern Europe Non-Euro” as a territory. Does Bulgaria move to “Eurozone East”? Or stay where it is? This is business strategy, not data maintenance.

    Pricing structures. If you’ve priced differently for non-Eurozone versus Eurozone countries, what happens to Bulgarian pricing on 1/1/26? Do existing contracts maintain historical pricing, or shift to Eurozone rates? How do you communicate these changes to customers?

    Market segmentation might change. You could segment by currency zone for risk analysis—Bulgaria just switched segments. Your analytics frameworks, risk models, and reporting structures all need strategic decisions about how to reflect this shift.

    For Acme Ltd: Your management decides: Do we keep “Eastern Europe Non-Euro” pricing for existing contracts, or move them to “Eurozone” pricing? Do we restructure territories so Bulgaria sits with other Eurozone countries? These decisions change how you organize and price your business.

    Master Record Decisions (Operational Authority)

    Employees need to update individual entity records within the structures management defined.

    Customer #12345 currently shows “default currency: BGN”. Update to EUR? When? Automatically on 1/1/26? Earlier with customer notification? Wait for customer agreement?

    Bulgarian supplier records—payment currency fields need updating. But do all suppliers move to EUR at once? What if some want to negotiate new terms? Who coordinates this across procurement teams?

    Employee records for Bulgarian staff need attention. Salary currency, expense currency, benefits currency—HR coordinates with payroll, finance updates systems, communication strategy required for affected staff.

    For Acme Ltd, Customer #12345:

    Current record:

    • Default Currency: BGN
    • Territory: “Eastern Europe Non-Euro”
    • Credit Terms: 30 days
    • Pricing Tier: “Non-Eurozone”

    Updates needed (following management’s Master Data decisions):

    • Default Currency: EUR (automatic 1/1/26)
    • Territory: “Eurozone East” (if management restructured)
    • Credit Terms: Review if changing to Eurozone standards
    • Pricing Tier: Update if management changed pricing structure

    Sales rep executes these updates.

    But they work within the structures management defined. They can’t restructure territories. They can update which territory Acme sits in.

    Business Policy for Immutable Transactions

    Transactions happened.

    They captured state at that moment.

    You can’t change what happened.

    But you must decide your business policy for handling them.

    Active transactions spanning the transition create complexity. Open invoices in BGN—the invoice was issued in BGN, that’s recorded. But do you accept EUR payment at the official rate? What if payment terms cross 1/1/26? What about invoices due in 2025 but unpaid by 1/1/26? What does your policy state?

    Contracts signed in 2024 for three years, denominated in BGN—the contract happened in BGN. Do you amend to EUR going forward? Continue in BGN? Handle currency conversion at each payment? Legal review required, not just data decisions.

    Purchase orders in BGN with 2026 delivery create questions. The PO was placed in BGN. How do you handle pricing when currency changes mid-delivery window? Who bears exchange rate risk if you convert? What do contract terms actually require?

    Historical closed transactions stay as they are. Paid invoices from 2024—they happened in BGN. Stay in BGN. The transaction is immutable.

    But for trending analysis, do you convert historical data? That’s not changing the transaction. That’s a Master Data decision about reporting strategy.

    For Acme Ltd:

    Immutable transaction: Invoice #INV-2024-789, dated 15 December 2024, amount 5,000 BGN, paid 20 December 2024. This stays in BGN. It happened. You can’t change history.

    Open transaction: Invoice #INV-2025-042, dated 20 December 2025, amount 10,000 BGN, due 15 January 2026. The invoice was issued in BGN (immutable). But payment due after currency change. Business policy needed: Accept EUR at 1.95583? Require BGN payment before deadline? Issue new invoice?

    Active contract: 3-year service agreement signed March 2024, annual fee 50,000 BGN. The contract was signed in BGN (immutable). But 2026-2027 payments are due post-transition. Business policy needed: Amend contract to EUR? Continue BGN payments? Renegotiate terms?

    Your business context determines every answer.

    Where You Convert (Master Data About Reporting)

    Even when you decide to convert historical transactions for analytics, you choose where.

    This choice is itself a Master Data decision—management defining how the business reports and analyzes across the currency transition.

    In transactional systems: Leave closed transactions alone. Preserve source truth. The 2024 invoice happened in BGN. Keep it in BGN. Don’t rewrite history in operational systems.

    In your data warehouse: Convert everything to EUR for trending. Apply official rate consistently across ten years of data for clean analytics. Your CFO wants year-over-year revenue trending without currency splits? Warehouse conversion strategy solves this.

    Both strategies are valid. Don’t confuse them. One preserves operational truth. The other enables analytical consistency.

    For Acme Ltd: Their 2024 invoice stays in BGN in your billing system (source truth). But your data warehouse might convert all BGN transactions to EUR at 1.95583 so your CFO can see clean year-over-year revenue trending without currency splits. That’s a reporting strategy decision, not changing what happened.

    What Companies Get Wrong

    They treat this as “reference data maintenance.”

    IT updates currency codes on 1/1/26.

    Done.

    Meanwhile: Finance hasn’t decided pricing strategy for Bulgarian customers. Commercial hasn’t restructured territories. Legal hasn’t reviewed contract implications. HR hasn’t coordinated employee salary changes. Data teams haven’t decided warehouse conversion strategy. Customer service doesn’t know how to answer “what happens to my BGN invoices?”

    The reference change is simple.

    The response requires coordinated business decisions across every function.

    What This Potentially Means for You

    My assumption is that most companies already have policies for all of the above.

    Why?

    Because Bulgaria is not the first country to join the EURO since it was launched. Eight countries have joined since, making Bulgaria the ninth.

    But the below might still be useful.

    Map your Bulgarian exposure across all four data types. How many customers? Suppliers? Employees? Open contracts? Active transactions? Historical data? Without this baseline, you can’t assess impact or coordinate response.

    Separate reference updates from business decisions. Currency codes update automatically. Everything else needs a decision and an owner. Don’t let “it’s just data” thinking hide strategic choices.

    Identify decision owners by data type:

    • Reference monitoring: IT/Data team (follow EU/ISO)
    • Master Data restructure: Management/Commercial/Finance (strategic)
    • Master Records updates: Operations/Sales/HR (operational)
    • Transaction handling: Finance/Legal/IT (business policy)

    Document your conversion policy by record type and system layer. Not one policy. Multiple policies for different contexts. What converts in transactional systems? What converts in the warehouse? What stays as-is?

    Recognize the deadline is real.

    Bulgaria joins 1/1/26. Your systems either handle it or break. No extensions available.

    Putting It All Together: One Customer

    Watch how Acme Ltd, your Bulgarian customer, cascades through all four data types.

    Reference Data (External Authority – You Follow):

    • Bulgaria = ISO 3166 country code (can’t change)
    • BGN → EUR on 1/1/26 at 1.95583 (EU decided)

    Master Data (Management Authority – Strategic):

    • Decision: Move “Eastern Europe Non-Euro” territory to “Eurozone East”?
    • Decision: Bulgarian pricing—maintain premium or align with Eurozone?
    • Decision: Credit terms—continue historical or adopt Eurozone standards?

    Master Records (Operational Authority – Within Strategy):

    • Customer #12345 “Acme Ltd”
    • Current: Currency = BGN, Territory = “Eastern Europe Non-Euro”
    • Update: Currency = EUR (automatic 1/1/26)
    • Update: Territory = “Eurozone East” (if management restructured)
    • Update: Pricing tier (following management’s pricing decision)
    • Communication: Sales team notifies Acme of changes

    Transactional Records (Immutable + Business Policy):

    • Invoice #INV-2024-789: 5,000 BGN, paid December 2024 → stays BGN (happened)
    • Invoice #INV-2025-042: 10,000 BGN, due January 2026 → accept EUR payment? (policy)
    • 3-year contract: 50,000 BGN annual, signed 2024 → amend or continue? (legal + policy)
    • Analytics: Convert historical BGN to EUR in warehouse? (reporting strategy = Master Data decision)

    One customer. Four data types. Different authority at each level.

    Miss the distinction, and you’ll govern everything the same way.

    Get it right, and the work becomes clear.

    Why The Four Types Matter

    Without distinguishing data types, companies make two mistakes.

    Mistake 1: Treat everything as reference data. “Just update the codes.” Miss all the business decisions. Systems work but business processes break.

    Mistake 2: Treat everything as master data. Try to govern the EUR code. Create approval workflows for ISO standards. Waste effort on non-decisions.

    The framework reveals what needs decisions versus what needs compliance.

    Reference data: Comply with EU/ISO. Master Data: Management decides strategic response. Master Records: Employees update within strategy. Transactional Records: Immutable, but business policy determines handling.

    Get the authority pattern right, and January becomes manageable.

    Get it wrong, and January will be chaos.

    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 charlotte-malmberg.ghost.i

  • 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/

  • The True Cost of Ignoring Reference Data

    Post 5 of The Authority Rule Series

    When one “innocent” deviation from an ISO standard costs thousands (or more) every year.

    A Swedish developer made a reasonable decision. Their system needed country codes. Sweden is “Sverige” in Swedish. The natural abbreviation is “SV.” So they coded Sweden as “SV” in the database.

    Seemed perfectly logical. Got the project done. Moved on.

    Except ISO 3166 assigns “SV” to El Salvador.

    What Happened Next

    When the company started selling to El Salvador, they hit a wall. “SV” was already taken. So El Salvador got a different code, which meant permanent mapping tables in every integration. The data warehouse team discovered this variation years later when conforming data from multiple systems, and by then, the original developer was gone. The decision wasn’t documented; it seemed obvious at the time.

    Every migration touched this issue. Every integration required mapping logic. Every data warehouse layer needed transformation rules for fifteen years and counting.

    This wasn’t malicious or incompetent. It was one reasonable person making one local decision under project deadline pressure.

    The problem: Nobody told them ISO has authority over country codes.

    How It Really Happened

    Here’s what was missing: No one had decided “we use ISO 3166 for country codes.” No one had documented that country codes have external authority. QA had no policy to check against. Architecture hadn’t defined the pattern; they might not even have existed at the time of this project. So when project pressure hit and the developer needed a solution, they made the call themselves.

    Reasonable. Local. Wrong authority level.

    The failure wasn’t the developer’s. It was organizational—no one owned the decision about which external standards to follow.

    The Lifecycle Cost Nobody Captures

    Business cases model three to five years of maintenance. But systems run for fifteen to twenty years, or more, and this single ‘innocent’ decision touches every part of the software lifecycle.

    In development, you need permanent mapping tables in every system that integrates.

    During integration, every external connection requires special handling—forever.

    In the data warehouse, someone years later has to discover this variation when conforming data from multiple systems, often without documentation explaining why it exists.

    New developers are likely to assume the custom code is standard and are at risk of propagating the error.

    During migration, you have to remember, discover, or reverse-engineer the mapping, or everything breaks.

    The business case said three years. The system ran for twenty. One innocent decision. Decades of compounding technical debt.

    Where Responsibility Sits

    Someone must own the decision about which external standards the organization follows. If you have a Chief Data Officer, this sits in their domain. If you don’t have a CDO it is likely to be the Enterprise Architecture team. If you have neither, someone still needs to be responsible; in small organizations, it might be the Head of IT or Tech Lead.

    It doesn’t matter who. It matters that someone owns it.

    That role decides: “We use ISO 3166 for country codes. Non-negotiable.” Then QA checks compliance, and developers know they can’t redefine Sweden.

    The Authority Rule Prevents This

    The Authority Rule asks: Who has the authority to define what this means?

    For country codes, can you redefine what “Sweden” should be coded as tomorrow? Actually, no. ISO 3166 has that authority—every external system expects ISO codes, every industry standard uses them, every data exchange requires them. You don’t own this definition. That makes it reference data.

    Which means you follow the external authority. You don’t redefine it, create “helpful” variations, or make it fit local preferences.

    One question. One moment of clarity. Years of technical debt prevented.

    What This Means Monday Morning

    Identify who owns external standards decisions in your organization—CDO, Architecture, CTO, someone must have this responsibility. Document which external authorities you follow: ISO 3166 for countries, ISO 4217 for currencies, SWIFT for bank identifiers. Create guardrails that prevent deviation through architectural patterns and QA checks. When developers ask “can we just use our own codes?” the answer is already documented.

    Recognize that reference data needs policy, not governance. No approval workflow. No committee discussion. Just a rule: Follow the external authority.

    Why This Matters

    The Swedish developer wasn’t wrong to want “SV.” They just didn’t know ISO already owned that decision, and nobody in the organization took responsibility for telling them.

    That one missing policy created technical debt that compounds annually across the entire enterprise for decades. When you ignore reference data, you don’t just create one mapping table; you create permanent complexity that touches every system, every integration, every migration, every new developer, for the entire lifecycle of your estate.

    The Authority Rule prevents this by asking one simple question that reveals where authority actually sits: Can you redefine this? No. Then follow the standard.

    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/

  • Why Exchange Rates Are Master Data (Yes, Really)

    Post 4 of The Authority Rule Series

    “But Charlotte, exchange rates come from Reuters. Bloomberg. The ECB. They’re published externally. We don’t decide what EUR/USD is trading at—we just look it up. How can that possibly be master data?”

    I hear this objection constantly. And I understand it. Exchange rates feel like reference data. They exist in markets. Multiple authorities publish them. You can’t just make them up.

    But here’s the thing: Exchange rates are master data.

    And the confusion about this sends people looking for answers in the wrong places.

    The Authority Rule Question

    Let’s apply our test: Who has the authority to define what this means, and do you need others to accept that definition?

    For currency codes, ISO 4217 decides that Euro = EUR, US Dollar = USD. You cannot redefine EUR to mean something else. Every system in the world must accept ISO’s definitions.

    This is reference data.

    For exchange rates, you choose which source (Reuters? Bloomberg? ECB? Your bank?). You choose which timing (opening? closing? daily average? intraday?). You choose which methodology (spot rate? forward rate? adjusted for fees?). Nobody else needs to accept your choices.

    This is master data.

    What You Actually Control

    When you “use an exchange rate,” you’re making four business decisions:

    1. Source authority: “We use Bloomberg rates.”
    2. Temporal authority: “We take the 4 pm London close”
    3. Methodological authority: “We use bid-side for payments, mid-side for reporting.”
    4. Exception authority: “During market disruption, we use yesterday’s rate.”

    Each of those is your choice.

    Your business decision.

    Your definition.

    The rate Bloomberg publishes at 4 pm is a fact. Which rate you use for which purpose? That’s your policy.

    Where Authority Actually Sits

    Here’s what matters most.

    Exchange rate policy sits with your CFO and C-Suite, not with data governance or IT. It’s not a data steward decision. It’s not a reference data maintenance task. It’s not an IT configuration choice.

    It’s a business decision about financial policy. When someone asks, “Which exchange rate should we use for this new product line?” the answer isn’t in a data governance committee. It’s in a conversation with Finance leadership or the C-suite about risk tolerance, accounting requirements, and business strategy.

    When the classification is confused:

    Finance teams submit “data change requests” for what should be executive decisions.

    Data governance committees debate financial policy they shouldn’t own.

    IT teams make business decisions by default when configuring rate feeds.

    Business decisions get stuck in data maintenance workflows.

    The Real-World Test

    Tomorrow, your CFO can say: “We’re switching from Reuters to Bloomberg, and we’re moving from daily close to intraday rates for all FX trades over €1M.”

    And they can just… do it.

    You need to comply with regulatory requirements – if regulations say “use observable market rates,” you must use recognized sources. But within those constraints, the specific choices are yours. The regulator doesn’t approve that you switched from Reuters to Bloomberg. They just care that both are legitimate market sources that meet their requirements. Your external auditors don’t verify which timing convention you chose. They verify that your chosen approach is consistently applied and appropriate.

    The regulatory framework is reference data (you must follow it).

    Your implementation within that framework is master data (you control the specifics).

    If your CFO said, “We’re redefining EUR to mean Japanese Yen,” regulators would shut you down immediately. You can’t redefine currency codes because ISO has that authority, and regulators require you to follow ISO standards.

    That’s reference data – an external authority you must accept.

    Why Classification Matters

    Knowing what it is tells you where to seek your answer.

    When someone asks, “Can we change how we handle exchange rates?”:

    If you think it’s reference data:

    • Data governance committees
    • Reference data stewards
    • IT maintenance teams
    • External source verification

    If you know it’s master data:

    • CFO and Finance leadership
    • Business policy owners
    • Risk management
    • Strategic decision makers

    The classification doesn’t just organize your data catalog.

    It tells you who has the authority to make decisions. Which tells you where to go for answers.

    Common Confusions

    “But the rate exists independently of us!”, “But we have to use market rates for compliance!”

    You choose which source, which timing, which methodology. Compliance constrains; it doesn’t eliminate your authority.

    “But everyone uses the same rates!”

    They don’t. Some use opening, some closing, some averages. Some use mid-market for reporting but bank rates for transactions. The variety proves the authority is distributed.

    What About Rate Tables?

    You maintain a table of exchange rates in your database.

    Doesn’t that make it reference data?

    No. (See Post 3: “Just Because You Master It…”)

    You’re maintaining your copy of your business decision about which rates to use. The fact that you update it daily doesn’t change who has authority over what the data means.

    The rate value came from an external source (that’s a fact). Which source you used is your decision (that’s policy). When you captured it is your decision (that’s policy). How you apply it is your decision (that’s policy). Whether to override it in specific cases is your decision (that’s policy).

    All policy. All yours. All master data.

    And all CFO authority, not data governance authority.

    The Governance Implication

    If you govern exchange rates as reference data:

    • Finance decisions route through data committees
    • Business policy becomes “data change requests”
    • CFO authority gets obscured by process
    • Time wasted seeking wrong approvals

    If you govern exchange rates as master data:

    • Financial policy sits with Finance leadership
    • Business decisions flow appropriately
    • Authority is transparent and efficient
    • People know who to talk to

    The Pattern

    This pattern repeats everywhere.

    Tax codes = reference (government decides) → monitor external changes

    Tax rates = reference (government decides) → monitor external changes

    Your tax configuration = master (Finance decides) → business approval workflow

    Security identifiers (ISIN, CUSIP) = reference (authorities decide) → monitor standards

    Security prices = fact in markets → capture data

    Which prices you use for valuation = master (CFO decides) → financial policy

    Country codes = reference (ISO decides) → follow standards

    Your market segmentation = master (executives decide) → strategy decision

    The external fact existing doesn’t make it reference data. Your authority over how you use it makes it master data.

    And that authority lives somewhere specific in your organization.

    What This Means For You Today:

    Stop routing rate policy questions through data governance.

    Document who owns rate sourcing methodology.

    Separate rate values from rate policy in your architecture.

    When someone asks “which rate should we use,” redirect them to Finance leadership.

    Recognize that knowing the source and type matters more than the label – but knowing the label tells you where to go for decisions.

    Why This Matters

    The confusion doesn’t just clutter your data catalog.

    It sends people to the wrong decision-makers. When Finance teams think exchange rates are “just reference data,” they defer to IT or data governance for decisions that should be theirs.

    When data teams think exchange rates are reference data, they implement what should be executive-level financial policy.

    The Authority Rule cuts through the confusion: Can you redefine your rate sourcing methodology tomorrow? Yes. Do you need anyone else to accept it? No. It’s master data. And that means the authority sits with your CFO, not your data steward.

    The external fact that rates exist in markets doesn’t eliminate your authority over how you use them.

    And recognizing where that authority lives tells you exactly where to go for answers.

    Next Week: The True Cost of Ignoring Reference Data – When one “innocent” deviation from an ISO standard costs thousands every year

    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/

  • Just Because You Master It Doesn’t mean it is Master Data.

    For years, something bothered me about data discussions.

    People would say “currency codes are our master data” and I’d feel this cognitive dissonance. We maintain them. We distribute them. Other systems depend on us for them. By every traditional definition, we “master” this data.

    But something felt off. I couldn’t put my finger on it or articulate what was jarring to me.

    Then I discovered the Authority Rule—that simple question that cuts through everything: “Who has the authority to redefine what this means?”

    And suddenly, the fog lifted. What had been jarring me for years became crystal clear.

    The Moment It Clicked

    Currency codes. EUR means Euro. USD means United States Dollar. GBP means British Pound.

    Ask yourself: Can your organization decide EUR means something else? Can you give USD three decimal places instead of two? Can you invent a new currency code and expect the world to accept it?

    No.

    You can’t. Because you don’t have the authority. ISO does.

    In fact, ISO masters it for the world, holding the final definition, making it reference data for everyone else. When one entity has authority for everyone, it automatically becomes reference data for all consumers.

    This isn’t about technical capability. You could absolutely change CHF to mean “Chilean Franc” in your database instead of Swiss Frank – the definition the rest of the world uses. You have the technical power. But you don’t have the authority. And that difference, between capability and authority, is everything.

    The Pattern I Keep Seeing

    Once this clicked, I started seeing it everywhere:

    Currency codes: You maintain them perfectly. You might even add business rules—which currencies you trade, your risk limits, your preferred banks. But the codes themselves? Not yours. ISO 4217 owns those.

    Exchange rates: Here’s where it gets interesting. The rate itself? That’s your master data—you choose your source, your timing, your calculation method. But the currency codes those rates reference? Still ISO’s.

    Country codes: Your systems depend on them. Every address, every tax calculation, every shipping route. But can you decide that GB means Germany instead of Great Britain? No. ISO 3166 has that authority.

    Sales territories: Now we’re in your domain. How you divide regions, which countries belong to EMEA vs APAC, your sales areas—that’s your master data. You define it, others in your organization accept it.

    SWIFT codes: Financial institutions treat these like crown jewels. SWIFT defines them. You’re just maintaining a subscription.

    Tax codes: Governments define them. You configure how to handle them. The codes are reference data. Your configuration is master data. Two different things, accidentally welded together.

    The pattern repeats: Just because you “master it”—maintain it, distribute it, depend on it—doesn’t mean it’s Master Data. You’re mastering the maintenance, not the meaning.

    Why This Distinction Matters

    This isn’t semantic philosophy. This confusion creates real problems:

    The Governance Theater

    When you treat reference data like master data, you create elaborate governance for things you don’t control. Approval workflows for copying ISO updates. Committees to discuss SWIFT code changes. Review boards for government tax codes.

    It’s governance theater. You’re governing your ability to copy someone else’s homework.

    Meanwhile, your actual master data—the business decisions that differentiate you—often has no or limited governance at all. Your credit limits, your risk ratings, your pricing strategies, your customer segments. The data you actually own and control.

    The Integration Maze

    When two systems exchange currency codes, whose version is “right”? If both think they’re the master, you get conflicts. Mapping tables. Transformation rules. Endless reconciliation.

    But neither of you owns currency codes. You’re both subscribing to the same external truth. The conflict is imaginary—like two people arguing about the “correct” spelling of a word when the dictionary is right there.

    The Update Paralysis

    When ISO updates a standard, organizations freeze. “We need to assess the impact.” “We need approval to update.” “We need to coordinate across systems.”

    No, you don’t. It’s reference data. When the dictionary adds a new word, you don’t convene a committee. You just use the new edition.

    But because you’ve confused maintenance with ownership, every update becomes a project.

    The Hybrid Problem

    Here’s where it gets genuinely complex. Most datasets aren’t pure. They’re hybrid.

    Take your currency table:

    • Currency code (EUR): Reference data (ISO’s authority)
    • Currency name (Euro): Reference data (ISO’s authority)
    • Decimal places (2): Reference data (ISO’s authority)
    • Exchange rate (1.18): Master data (your chosen source/timing)
    • We trade this (Yes): Master data (your authority)
    • Risk rating (Medium): Master data (your authority)
    • Preferred dealers (Bank1, Bank2): Master data (your choice of who)
    • Dealer legal names/post codes: Reference data (outside your authority)

    You’ve mixed external truth with internal decisions. Reference data with master data. And because you can’t see the boundary, you treat it all the same.

    When ISO updates, you’re afraid to accept the changes. You might “lose” your enrichments. You’ve welded together things that should be separate.

    The Clear Path Forward

    The Authority Rule makes the path clear:

    For pure reference data:

    • Subscribe to the authoritative source
    • Update automatically when they update
    • Don’t govern it—you don’t own it
    • Cache it locally for performance
    • Never modify the standard values

    For pure master data:

    • Govern it carefully—this is yours
    • Track changes and audit trails
    • Control the lifecycle
    • Define the business rules
    • Own the decisions

    For hybrid datasets:

    • Separate the layers
    • Link, don’t embed
    • Update reference data independently
    • Preserve master data separately
    • Document the boundary clearly

    My Discovery Journey

    This framework didn’t come from reading data management textbooks. It came from pattern recognition—the same approach I use to understand complex systems.

    I kept seeing people struggle with the same classification problems. Master or reference? Who owns what? Where does governance apply? The existing definitions weren’t helping. They focused on technical characteristics—volatility, cardinality, lifecycle. But these weren’t the real differentiators.

    The real differentiator was authority. Who gets to say what something means?

    Once I found that question, everything else fell into place. Currency codes—reference. Your trading decisions—master. Tax codes—reference. Your tax configuration—master. The pattern holds everywhere.

    The Liberation

    Understanding this distinction is liberating.

    You stop wasting time governing things you don’t own. You stop creating false conflicts in integrations. You stop treating external standards like internal decisions.

    You can maintain reference data excellently—keeping it current, available, well-distributed—without confusing it with ownership. In fact, you’ll maintain it better once you stop pretending it’s yours.

    Your actual master data—the decisions only you can make, the data that differentiates your business—they now get the attention they deserve.

    The Simple Test

    When you’re unsure about any piece of data, ask the Authority Rule question:

    “Can we redefine what this means and expect others to accept our definition?”

    • Currency code EUR: Can you redefine it? No. Reference data.
    • Exchange rate for EUR: Can you choose your source? Yes. Master data.
    • Country code USA: Can you change it? No. Reference data.
    • Sales territory “Americas”: Can you redefine it? Yes. Master data.

    If yes, it’s master data. Govern it. Own it. Control it.

    If no, it’s reference data. Subscribe to it. Synchronize it. Use it.

    Just because you “master it” doesn’t mean it’s Master Data. Just because you maintain it excellently doesn’t mean you own it. The source of truth doesn’t move with the copy. And recognizing this difference isn’t just precision—it’s the key to effective data governance.

    Next in this series: “Why Exchange Rates Are Master Data (Yes, Really)” – why external sources don’t determine data classification, and how the USC taught me about authority twenty years before I had the words for it.

  • When Dropdowns Lie: Why Data Format Doesn’t Determine Authority

    I’ve been thinking about why data classification has gotten more confusing over my career, not clearer.

    Early on, working with SAP, there was some structure. “System provided values” versus values you configured during implementation. Country codes came from SAP. Sales areas came from you.

    But we never articulated why that distinction mattered.

    Fast forward to today, and I sit in meetings where experienced data professionals argue for 30 minutes before someone finally asks: “Wait, are we even talking about the same type of data here?”

    The confusion is real. And expensive.

    After publishing the Authority Rule framework last week – the idea that master versus reference data is fundamentally about authority, not attributes – several people pointed out the exact source of confusion:

    The dropdown is lying to you.

    Two Identical Containers, Opposite Authority

    Open your metadata catalog. Look at everything labeled “reference data.”

    I’d bet a significant portion of it isn’t reference data at all.

    Here’s what I mean.

    Your system has a country code dropdown:

    • GRC – Greece
    • DEU – Germany
    • USA – United States
    • JPN – Japan

    You maintain this in your database. You update it when countries change. You synchronize it across systems.

    But ISO owns these codes.

    I’ve seen what happens when someone decides to “fix” this. A Swedish developer used “SV” for Sweden. Made perfect sense to them – their country, their natural abbreviation.

    Except ISO assigned “SV” to El Salvador.

    When the company started selling there, they had to give El Salvador a different code. Now there are permanent mapping tables. Every external integration needs special handling. Every new developer gets confused by why Sweden and El Salvador have non-standard codes. The more complex your system estate, the bigger the problem compounds.

    The root cause to the problem: they tried to exercise authority they don’t have.

    You can’t wake up tomorrow and decide Greece should be coded differently. Well, you can in your internal systems. But ISO still publishes “GRC or GR.” Every other system still expects “GRC or GR”. Every industry standard still uses “GRC or GR.”

    You don’t own these definitions. That makes them reference data.

    Your system has a sales area dropdown:

    • UK-Enterprise – UK Enterprise accounts
    • UK-SMB – UK Small/Medium Business
    • DACH-Enterprise – Germany, Austria, Switzerland Enterprise
    • NORDICS-ALL – Nordic countries, all segments

    You created these territories. You defined the boundaries. You chose the codes.

    Tomorrow, you could:

    • Merge UK-Enterprise and UK-SMB into UK-ALL
    • Split DACH by industry vertical instead of company size
    • Add BENELUX-Enterprise for Belgium, the Netherlands, and Luxembourg
    • Rename everything to match a new organizational structure

    And everyone in your organization must accept these changes. Your CRM updates. Your reporting adapts. Your sales teams realign. Your compensation plans adjust.

    You own these definitions. That makes them master data.

    The Format Trap

    Look at those two examples again.

    Same format: Dropdown list

    Same structure: Code + Description

    Same maintenance: Regular database updates

    Same usage: Referenced across multiple systems

    Completely different authority relationships.

    This is why format-based classification fails.

    For decades, we’ve said:

    • Lookup table? → Reference data
    • Dropdown values? → Reference data
    • Code tables? → Reference data
    • Low volume, high reuse? → Reference data

    We classified by what data looks like, not by who has the power to define it.

    Why I Started Questioning Format-Based Classification

    I kept noticing the pattern: meetings where smart people couldn’t agree on classification because they were arguing about different things.

    One person focused on format: “It’s in a dropdown, so it’s reference data.”

    Another focused on source: “We maintain it, so it’s master data.”

    A third focused on usage: “Multiple systems use it, so it’s reference data.”

    None of these attributes provided a clear distinction.

    I started looking for similarities and differences. What’s actually the same between country codes and sales areas? What’s fundamentally different?

    Not the container – both dropdowns.

    Not the maintenance pattern – both regularly updated.

    Not the importance – both critical to business operations.

    The difference is who has the authority to define what these codes mean.

    ISO for country codes. You for sales areas.

    Once I saw that, everything else fell into place.

    What Practitioners Are Discovering

    When I published the Authority Rule last week, Mark Berford – an Enterprise Data Architect with over 30 years of experience and DAMA membership – immediately recognized this pattern:

    “Traditionally, a list of possible values for a ‘customer type’ master data attribute is defined as reference data rather than master data. However these are still within ‘your’ authority to define, so I’m inclined to call [them master data].”

    He’s working through decades of format-based classification and seeing why authority provides the clearer distinction.

    Yogesh Poddar, a Product Owner in Digital Transformation, explained where the confusion originates:

    “Perhaps the confusion occurs due to the allocation of an additional internal unique identifier to instances of ref data – like Currency or Country codes. This could lead some to believe that since they have allocated their own identifier (to what is external data) that data is to be considered Master.”

    The presentation layer – how we store and display data internally – obscures the authority relationship underneath.

    The Authority Rule Applied to Dropdowns

    Stop classifying by format, instead remember this:

    Master: you can redefine it and only you need to agree.

    Reference: if you redefine it, the world won’t accept it.

    Apply this systematically to your “reference data” catalog:

    Reference Data (External Authority):

    • Country codes (ISO 3166)
    • Currency codes (ISO 4217)
    • Tax form codes (IRS, HMRC, etc.)
    • Industry classification codes (NAICS, SIC, etc.)

    You monitor external changes. You ensure compliance. You can’t redefine them.

    Master Data (Your Authority):

    • Sales area codes
    • Customer type codes
    • Department codes
    • Product category codes
    • Internal project codes

    You create, modify, and retire these based on business needs. You can ensure compliance in your company.

    The dropdown format is irrelevant. Authority determines classification.

    Steps to Improve Your Understanding

    Step 1: Audit Your “Reference Data”

    Go through your metadata catalog.

    For everything labeled “reference data,” ask: “Who has the authority to define what this means?”

    External organization (ISO, government, industry body) → Actually reference data

    Your organization → Actually master data, misclassified

    It wouldn’t surprise me if 40-60% of what’s labeled “reference data” in most enterprises is actually master data hiding in dropdowns.

    Step 2: Create Three Categories

    Reference Data: External authority defines, you monitor and comply

    • Examples: ISO codes, government regulations, industry standards

    Master Data: Your authority defines what everyone in your company must follow

    • Examples: Customer segments, territories, internal categories

    Lookup Data: The presentation format (can contain either type)

    • Examples: Dropdown lists, code tables, lookup tables

    The Container Is Irrelevant

    Dropdowns don’t lie. They present data consistently.

    But we lie to ourselves when we assume format determines classification.

    The dropdown is the container. Authority is what matters.

    Country codes and sales areas look identical in your UI. But you control one completely and the other not at all.

    Classify them differently. Govern them differently. Integrate them differently.

    Because who has the power to define what something means – that’s the line that actually matters.

    What’s Next

    This distinction between presentation and authority becomes even more important when examining layered authority relationships:

    • Tax codes (reference) vs tax rates (reference) vs tax configuration (master)
    • Currency codes (reference) vs trading currencies (master)
    • When your master data becomes someone else’s reference through contracts

    I’ll explore these complex cases in upcoming posts.

    But start with your dropdowns.

    Audit what you’ve labeled “reference data.” Apply the authority test. I’d bet you’ll find master data that’s been ignored because it was hiding in a lookup table.

    The Authority Rule cuts through format to reveal authority underneath.

    And authority – not format – determines what data actually is.

    This is part of a series on the Authority Rule framework for distinguishing master and reference data. The framework emerged from looking for similarities and differences across domains – the same pattern recognition approach that helped me understand art history, identity systems, and now data classification.

    Next week: “Just Because You Master It Doesn’t Mean You Own It” – why maintaining reference data in your systems doesn’t transfer ownership to you.

    What dropdowns in your organization are hiding master data behind a “reference data” label?

    Share your examples – I’m documenting these patterns for a book on the Authority Rule, and your real-world cases might make it into the final manuscript.

  • 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.