Data Authority Rule

Tag: Master Data Management

  • Contracts: Where Agreement Meets Execution

    Contracts sit between strategy and execution.

    Master Data structures define how you organize your business. Transactions capture what actually happened. Contracts are where both parties agree to terms before execution begins.

    Purchase Orders. Sales Orders. Service Agreements. Insurance Policies. Loan Agreements. These aren’t just paperwork. They’re the binding layer where internal classifications meet external commitments.

    Understanding what belongs in contracts versus what stays in structures changes what needs updating when strategy changes.

    What Contracts Are

    A contract is a bilateral agreement. Both parties commit to terms.

    You agree to deliver Product SKU-789 to Customer #12345’s Warsaw plant. Customer agrees to pay £10,000 under Net30 terms. You both sign. That’s a contract.

    From Post 8: Contractual Authority is bilateral and time-binding. Once agreed, terms are fixed for the contract duration. You can’t unilaterally change price. Customer can’t unilaterally change payment terms. The agreement binds both parties.

    Contracts create Orders in admin systems. Order Management systems. Contract Management systems. The systems that capture “what we agreed to do before we do it.”

    Sales Order SO-456789 records the contract. Product SKU-789, Customer #12345, Ship-to Warsaw plant, Quantity 500, Price £10,000, Terms Net30, Delivery Express, Discount 15%.

    The Order is the operational record of contractual agreement. Transactions execute against it.

    What Belongs In Contracts

    Contracts capture what both parties agreed to.

    Product and quantity: Product SKU-789, Quantity 500 units. Both parties agreed to specific product and amount.

    Customer and delivery: Customer #12345, Ship-to location Warsaw plant. You’re delivering to specific party at specific location.

    Pricing and terms: Price £10,000, Discount 15%, Payment terms Net30. Financial agreement between parties.

    Delivery commitments: Delivery method Express, Delivery date 2026-02-15. Service level agreement.

    Dates: Order date 2026-01-15, Expected delivery 2026-02-15, Payment due 2026-03-17. Timeline commitments.

    These are bilateral. Both parties agreed. Customer committed to pay these terms. You committed to deliver under these terms.

    Contracts reference Master Records minimally. Customer ID #12345, Product ID SKU-789, Location ID Warsaw plant. Just IDs pointing to entities, following the same principle as Post 15.

    The contract doesn’t embed customer properties (revenue, industry, contact details). Those are in Customer Master Record. Contract just references customer by ID.

    The contract doesn’t embed product properties (specifications, weight, dimensions). Those are in Product Master Record. Contract just references product by ID.

    Minimal references. Agreed terms. That’s what contracts contain.

    What Doesn’t Belong In Contracts

    Contracts don’t capture your internal classifications.

    Sales territory: Customer #12345 order doesn’t include “North Region” or “Enterprise Sales.” Territory assignment is YOUR internal org structure. Customer doesn’t care which territory owns the account. That’s Master Data classification structure for your internal operations.

    Product category: Order doesn’t include “Desktop Computing > Business Laptops” taxonomy. Product classification is YOUR internal organization. Customer ordered Product SKU-789. How you classify that product internally is Master Data structure.

    Cost center: Order doesn’t include which department or cost center processes it. Internal accounting allocation is YOUR structure. Customer isn’t party to your internal financial organization.

    Customer segment: Order doesn’t classify customer as “Enterprise Tier” or “Strategic Account.” Segmentation is YOUR internal classification. Customer agreed to purchase terms, not to your internal categorization.

    Commission rules: Order doesn’t embed salesperson splits or commission calculations. Those are YOUR internal compensation structures based on territory, product, customer assignments – all Master Data classifications.

    These are unilateral. You control them. Customer isn’t party to these decisions. They’re strategic authority (Master Data), not contractual authority (bilateral agreement).

    The separation matters architecturally.

    How Terms Get Applied

    When creating an Order, you apply current Master Data structures to determine contractual terms.

    Customer #12345 places order on 2026-01-15. Your system evaluates:

    Network membership structure (Master Data): Customer #12345 is member of European Manufacturing Consortium as of 2026-01-15. EMC Master Record shows 15% volume discount terms. Apply 15% discount to order.

    Payment terms structure (Master Data): Customer #12345’s standard terms are Net30. Apply Net30 to order.

    Party-to-location relationship (Master Data from Post 16): Customer #12345 has ship-to location Warsaw plant. Customer selects Warsaw. Order captures location ID.

    Pricing rules (Master Data): Product SKU-789 base price £11,765 as of 2026-01-15. Apply 15% discount = £10,000 contract price.

    The Order captures the RESULT of applying structures: 15% discount, Net30 terms, Warsaw location, £10,000 price. Not the structures themselves. Not “member of EMC” – that’s Master Data relationship. Just the agreed discount percentage.

    Once Order SO-456789 is created, those terms are contractual. Fixed for this agreement. Even if Customer #12345 leaves EMC tomorrow, Order SO-456789 still has 15% discount because that was the agreed term.

    Contractual Authority binds the terms at agreement date.

    Why This Separation Matters

    Sales territory restructure doesn’t touch Orders because territory was never in Orders.

    Management restructures from “Regional Sales > North Region” to “Enterprise Sales > North Region Enterprise.” Territory classification structure (Master Data) versions.

    Existing Orders? Unchanged. Orders never contained territory. Territory is your internal classification for commission, reporting, management structure. Customer agreed to product, price, delivery – not to your org chart.

    Reporting still works: Query Order SO-456789, join Customer #12345 Master Record properties, apply Territory Structure v1.0 (effective when order created) → classified as North Region for historical reporting. Apply Territory Structure v2.0 (current) → classified as North Region Enterprise for current reporting.

    Both accurate. Order unchanged. Territory restructure doesn’t require order updates because territory was never bilateral agreement.

    Network membership change DOES matter for NEW orders, but not existing orders:

    Customer #12345 leaves European Manufacturing Consortium on 2026-02-01. Orders created before 2026-02-01 preserve their 15% contractual discount – that was agreed. Orders created after 2026-02-01 don’t get EMC discount – membership ended. New orders apply new structures, get new terms.

    Contractual Authority preserves agreed terms. Master Data structures determine terms for NEW agreements.

    This is different from transactions embedding structures.

    If you embedded territory in transactions (Post 12 problem), territory restructure breaks historical transactions. If you capture agreed discount in Orders, that’s correct – discount WAS agreed bilaterally. Orders preserve contractual terms. Execution transactions reference Orders.

    The distinction is bilateral (belongs in contract) versus unilateral (belongs in Master Data structures).

    Admin Systems and Minimal Orders

    Order Management systems, Contract Management systems – these are admin systems capturing agreements before execution.

    Sales Order system records what you agreed to sell. Purchase Order system records what you agreed to buy. Service Contract system records what you agreed to provide. Policy Admin system records insurance coverage agreed.

    These systems should maintain minimal Orders following same principle as Master Records (Post 15) and execution Transactions.

    Order contains:

    • Order ID (stable identifier)
    • Customer ID (reference to Master Record)
    • Product IDs (references to Master Records)
    • Ship-to location ID (reference to Master Record)
    • Agreed terms (Net30, 15% discount, Express delivery)
    • Agreed amounts (quantities, prices)
    • Agreed dates (order date, delivery date, payment due)

    Order doesn’t contain:

    • Customer properties (those are in Master Record, time-stamped)
    • Product properties (those are in Master Record, time-stamped)
    • Location properties (those are in Master Record)
    • Internal classifications (territory, segment, category – those are Master Data structures)

    Minimal means referencing entities by ID, capturing agreed terms, not embedding properties or structures.

    Why minimal? Same reason as Post 15. Less to maintain. Fewer dependencies. Easier to govern. Changes to Master Records don’t require Order updates. Changes to Master Data structures don’t require Order updates (unless creating new Orders).

    Transaction Execution Against Contracts

    Execution transactions capture what was agreed in the Order.

    Order SO-456789: Deliver 500 units Product SKU-789 to Customer #12345 Warsaw plant, charge £10,000, terms Net30.

    Execution transactions that fulfill this Order:

    Shipment Transaction ST-111222: Shipped 500 units Product SKU-789 to location Warsaw plant on 2026-02-15. References Order SO-456789.

    Invoice Transaction INV-333444: Invoiced Customer #12345 for £10,000, terms Net30, due 2026-03-17. References Order SO-456789.

    Payment Transaction PAY-555666: Received payment £10,000 from Customer #12345 on 2026-03-17. References Invoice INV-333444 which references Order SO-456789.

    Execution transactions reference the Order. Order references Customer and Product Master Records. Master Data structures classify for reporting.

    Chain: Execution Transaction → Admin Transaction (Order) → Master Records → Master Data structures (at query time).

    No embedded structures in any transactions. No embedded properties in Orders. Just references connecting layers.

    Query-Time Composition With Orders

    When reporting needs classifications, join through the layers.

    Query: “Show sales by territory for Q1 2026”

    Process:

    1. Find all Orders with order date in Q1 2026
    2. For each Order, get Customer ID
    3. For each Customer, get Master Record properties as of order date
    4. Apply Territory Structure version effective for order date
    5. Classify Order by territory
    6. Aggregate sales by territory

    The territory classification happens at query time. Uses Master Data structure version that was effective when Order was created. Order itself never contained territory.

    Query: “Show impact of territory restructure on Q1 sales”

    Process:

    1. Find all Orders with order date in Q1 2026
    2. Classify using Territory Structure v1.0 (before restructure) → Q1 sales by old territories
    3. Classify same Orders using Territory Structure v2.0 (after restructure) → Q1 sales by new territories
    4. Compare

    Same Orders. Different structure versions. Both classifications accurate. No Order updates required.

    Territory restructure is just Master Data structure versioning. Orders unchanged. Reporting adapts through query-time joins.

    Contractual Changes Versus Structural Changes

    Contractual changes require new agreements:

    Customer #12345 negotiates better discount. New Orders get 18% discount. Existing Orders preserve 15% discount – that was contractually agreed. You can’t unilaterally change agreed terms.

    Customer #12345 changes payment terms. New Orders get Net45. Existing Orders preserve Net30 – that was the agreement.

    Bilateral changes require bilateral agreement. New terms apply to new Orders. Existing Orders preserve contractual terms.

    Structural changes don’t require Order updates:

    Territory restructure: Orders unchanged. Territory was never in Orders. Classification structure versions, reporting adapts.

    Product reclassification: Orders unchanged. Product taxonomy was never in Orders. Orders reference Product ID. Taxonomy structure versions, reporting adapts.

    Customer segmentation changes: Orders unchanged. Segmentation was never in Orders. Orders reference Customer ID. Segmentation rules version, reporting adapts.

    Unilateral changes don’t affect bilateral agreements. Your internal structures are your business. Customer agreed to product, price, delivery – not to your internal classifications.

    Real Example: Network Membership Discount

    Customer #12345 is member of European Manufacturing Consortium. EMC negotiated 15% volume discount.

    Order created 2026-01-15:

    • Membership check: Customer #12345 member of EMC as of 2026-01-15
    • Apply discount: 15% from EMC Master Record
    • Order SO-456789 captures: Customer #12345, Product SKU-789, Discount 15%, Price £10,000

    Customer leaves EMC on 2026-02-01:

    • Update network membership Master Data: End date 2026-02-01
    • Order SO-456789: Unchanged. Still has 15% discount. That was agreed term.

    New Order created 2026-02-15:

    • Membership check: Customer #12345 not member of EMC as of 2026-02-15
    • No EMC discount applies
    • Order SO-789123 captures: Customer #12345, Product SKU-789, Discount 0%, Price £11,765

    Network membership is Master Data relationship structure (Post 16). Discount terms are in EMC Master Record. Orders capture the applied discount at agreement time. Membership changes don’t retroactively change contractual discounts.

    Structural relationship (membership) separate from contractual terms (discount). Changes to structure affect new agreements, not existing contracts.

    Admin Systems Versus Transactional Systems

    You might think: “Orders are just another transaction type.”

    Not quite. They’re a different kind of transaction.

    The Transactions layer contains two types of systems:

    Admin systems capture agreements before execution. Orders, Contracts, Policies – bilateral commitments about what will happen. “We will ship. You will pay.” Binding terms before execution begins.

    Transactional systems capture execution events. Invoices, Shipments, Payments – immutable facts about what happened. “Shipment occurred. Invoice issued. Payment received.” Facts after execution.

    Both are transactions. Both are captured authority. Both reference Master Records minimally. But they serve different purposes in the operational flow.

    Contracts bridge strategy and execution. Apply Master Data structures to determine bilateral terms. Capture those agreed terms. Enable execution through transactional events.

    The Three-Layer Architecture Pattern:

    • Master Data (structures – strategic authority, versioned)
    • Master Records (entities – operational authority, time-stamped)
    • Transactions (captured authority, immutable):
      • Admin layer: Agreements (Orders, Contracts, Policies)
      • Transactional layer: Execution events (Invoices, Payments, Shipments)

    Each layer has different authority pattern. Admin and Transactional systems within the Transactions layer have different purposes but follow the same architectural principles: minimal references, no embedded structures, immutable once created.

    Contracts are where internal classifications meet external commitments. Where Master Data structures get applied to generate bilateral terms. Where agreements lock in before execution begins.

    Understanding this distinction prevents confusion about what changes when structures change. Internal classifications? Version the structure. Bilateral agreements? Create new contract. Execution events? Immutable facts.

    Clear separation. Clear authority. Clear governance.

    Connection To Earlier Posts

    Post 13 identified Master Data as structures with strategic authority. Territories, taxonomies, operating standards, relationships – all Master Data.

    Post 14 identified the Three-Layer Architecture Pattern separating Master Data, Master Records, and Transactions.

    Post 15 identified Master Records as entities with operational authority. Minimal intrinsic properties, time-stamped changes.

    Posts 16 showed relationship structures as Master Data. Cross-system mappings, party-to-location, network memberships – all relationship structures enabling composition.

    Post 17 shows Contracts as binding agreements with contractual authority. Admin systems within the Transactions layer that apply Master Data structures to determine terms, reference Master Records minimally, create commitments that execution transactions fulfill.

    The Three-Layer framework working together. Each layer with different authority. Each with different mutability. Each with different governance. Admin and Transactional systems within Transactions layer serving different purposes but following same architectural principles.

    Next: Post 18 covers execution Transactions as minimal immutable events. Completing the understanding of how all three layers interact through both admin and transactional systems.

    This post is part of the Systems Thinking Series and how the 5 authority types impact system design. Read the full series at authorityrule.com/

  • The Party Problem: Seven Ship-To Locations

    One customer, seven locations. Management wants to restructure territories. How long will it take?

    If your architecture requires updating every location record, you’ve embedded structures in entities. If it versions a single structure, you’ve separated them correctly.

    Let’s test the Three-Layer framework under increasing complexity.

    Scenario 1: Basic Party-to-Location

    Acme Corporation has seven ship-to locations: Warsaw plant, Krakow distribution center, Berlin office, Prague warehouse, Budapest facility, Vienna office, London headquarters.

    The temptation: Store locations as properties on the customer record. Seven address fields. Or create a locations table with customer ID stamped on each row.

    The problem: When Acme opens an eighth facility, what changes? When they close Prague warehouse, what updates? Every change touches either the party record or requires updating stamped location records.

    Framework approach:

    Acme Corporation = Master Record. Minimal intrinsic properties: legal name, tax ID, registration date, entity type. No locations embedded.

    Each location = Master Record. Warsaw plant, Krakow distribution, Berlin office — each is an entity with its own minimal properties: address, delivery hours, loading dock capacity, operational status.

    Party-to-location assignments = Master Data. Relationship structure connecting party to locations:

    Acme Corporation (Party)├── Warsaw plant├── Krakow distribution├── Berlin office├── Prague warehouse├── Budapest facility├── Vienna office└── London headquarters

    This is Master Data from Post 13. Relationship structures. Maintained by operations. Versioned when changes occur.

    When Acme opens eighth facility: Create location Master Record for new facility. Add relationship in party-to-location structure. Party Master Record unchanged. Existing location Master Records unchanged. Just relationship structure updated.

    When Acme closes Prague warehouse: Update location Master Record status to inactive. Remove relationship in party-to-location structure (or version it with end date). Party Master Record unchanged. Other locations unchanged.

    When Acme restructures operations: Reassign locations to different operational roles. Relationship structure versions. Party and location Master Records stay unchanged unless actual properties like delivery hours change.

    The separation holds. Changes affect relationship structures. Master Records stay minimal.

    Scenario 2: Corporate Hierarchy

    Acme Corporation isn’t standalone. It’s a subsidiary of Acme International Holdings, which is owned by Global Industrial Corp.

    Three-level corporate hierarchy. How do you trace ownership chains? How do you handle reorganizations?

    The temptation: Add parent company ID to party Master Record. Acme record includes “Parent: Acme International Holdings” as property.

    The problem: When Global Industrial restructures — sells division, acquires competitor, merges subsidiaries — every party Master Record in the affected hierarchy requires updates. Parent IDs change. Historical reporting breaks unless you’ve time-stamped every ownership change at the party level.

    Framework approach:

    Each entity = Master Record. Acme Corporation, Acme International Holdings, Global Industrial Corp — all party Master Records with minimal properties. No parent IDs embedded.

    Corporate hierarchy = Master Data. Relationship structure defining ownership:

    Global Industrial Corp└── Acme International Holdings    └── Acme Corporation        └── (7 ship-to locations from Scenario 1)

    This is classification structure Master Data — hierarchical, but mapping relationships between entities. Versioned independently.

    When Global Industrial acquires competitor: Add competitor parties as Master Records. Update corporate hierarchy structure to show new ownership relationships. Version the structure. Historical reporting uses historical hierarchy version. Current reporting uses current version. Existing party Master Records unchanged.

    When Acme International Holdings is sold: Update corporate hierarchy structure. Acme International (and all subsidiaries) move to new parent. Version the structure with effective date. Historical transactions use historical hierarchy. Current transactions use current hierarchy. Party Master Records unchanged.

    The pattern holds. Relationship structures handle hierarchies. Master Records stay minimal. Changes version structures, not entities.

    Scenario 3: Network Membership

    Acme Corporation is member of European Manufacturing Consortium. The consortium negotiated supplier agreements providing 15% volume discount with preferred vendors.

    How do you know Acme gets the discount? How do you apply it to transactions? How do you handle when Acme joins or leaves networks?

    The temptation: Add discount percentage to Acme’s Master Record. Or add “Network: EMC” as property with associated discount terms.

    The problem: When consortium renegotiates terms — 15% becomes 18% — you update every member party record. When party leaves consortium, you remove discount from their record. Party Master Records become repositories for contractual terms that belong elsewhere.

    Framework approach:

    European Manufacturing Consortium = Master Record. The network itself is an entity with minimal properties: name, registration details, contract terms. The discount terms (15% volume discount) are intrinsic properties of the consortium entity.

    Network membership = Master Data. Relationship structure connecting parties to networks:

    European Manufacturing Consortium (Master Record: 15% discount)├── Acme Corporation (member)├── TechMfg Industries (member)├── Alpine Manufacturing (member)└── Nordic Production Group (member)

    Parties don’t have discounts stamped on them. Networks have discount terms in their Master Records. Membership connects parties to networks through relationship structures.

    How does transaction get the discount?

    Transaction ships product to Acme Corporation. Query process:

    1. Check party-to-network mapping (Master Data) → Acme is member of EMC
    2. Query EMC Master Record → discount terms = 15%
    3. Apply discount to transaction pricing

    Query-time composition. Not pre-stamped discount on party record.

    When consortium renegotiates discount: Update EMC Master Record. 15% becomes 18%. Time-stamp the change. Party Master Records unchanged. Membership structure unchanged. All members automatically get new discount for new transactions. Historical transactions used historical discount percentage from EMC Master Record effective date.

    When Acme leaves consortium: Update membership structure. Remove Acme from EMC membership. Version with end date. Party Master Record unchanged. EMC Master Record unchanged. Future transactions query membership, find no match, no discount applies.

    The framework holds. Network terms live in network Master Records. Membership is relationship structure. Compose at query time. No party records bloated with contractual terms.

    Scenario 4: Territory Restructuring

    Management restructures sales territories. Currently organized by country offices. Changing to regional model.

    Current structure: Six country offices (Poland, Germany, Czech, Hungary, Austria, UK) each managing their local Acme locations.

    New structure: Two regional offices (Western Europe, Eastern Europe) managing consolidated territories.

    Six country offices become two regional offices. Territory restructure. This is the Post 11 problem applied to parties.

    The embedded approach:

    Sales office assignment is a property on location Master Records. Update every affected location:

    • Warsaw Master Record: Change “Sales Office: Poland” to “Sales Office: Eastern Europe”
    • Prague Master Record: Change “Sales Office: Czech” to “Sales Office: Eastern Europe”
    • Berlin Master Record: Change “Sales Office: Germany” to “Sales Office: Western Europe”
    • Vienna Master Record: Change “Sales Office: Austria” to “Sales Office: Western Europe”

    Every location in Europe requires Master Record update. Historical reporting breaks unless you’ve time-stamped every sales office change at the location level.

    This is exactly the problem Post 11 described. Territory restructure requires reprocessing Master Records.

    Framework approach:

    Location Master Records contain minimal properties: address, delivery hours, operational capacity. No sales office assignment embedded.

    Sales territory assignment = Master Data. Classification structure organizing locations by sales responsibility:

    Sales Territory Structure v1.0 (through 2025-12-31):├── Poland Sales Office│   ├── Warsaw plant│   └── Krakow distribution├── Germany Sales Office│   └── Berlin office├── Czech Sales Office│   └── Prague warehouse├── Hungary Sales Office│   └── Budapest facility├── Austria Sales Office│   └── Vienna office└── UK Sales Office    └── London headquartersSales Territory Structure v2.0 (from 2026-01-01):├── Western Europe Sales Office│   ├── Berlin office│   ├── Vienna office│   └── London headquarters└── Eastern Europe Sales Office    ├── Warsaw plant    ├── Krakow distribution    ├── Prague warehouse    └── Budapest facility

    Sales office assignment is Master Data. It’s a classification structure organizing locations by operational responsibility. Management controls it. Changes when strategy changes.

    When management restructures: Create new structure version. Effective date 2026-01-01. New regional model.

    What changes: One structure.

    What stays stable: All location Master Records, party Master Records, party-to-location relationships, corporate hierarchies, network memberships, transactions.

    Historical reporting: “Show me sales performance by office for 2025.”

    Query uses Sales Territory Structure v1.0. Warsaw rolls up to Poland office. Berlin rolls up to Germany office. Historical structure preserved.

    Current reporting: “Show me sales performance by office for 2026.”

    Query uses Sales Territory Structure v2.0. Warsaw rolls up to Eastern Europe office. Berlin rolls up to Western Europe office. Current structure applies.

    Trending across change: “Show me Warsaw plant performance 2025 vs 2026 by responsible sales office.”

    • 2025: Query with v1.0 structure → Poland office
    • 2026: Query with v2.0 structure → Eastern Europe office

    Both correct for their time periods. No location Master Records changed. Structure versioned.

    This applies the same principle from Post 11 to a different layer. Territory restructures version Master Data structures. Master Records stay unchanged. Transactions stay unchanged. Reporting adapts using version dates.

    If you embedded sales office in location Master Records: Three-month project to update every location record. Migration scripts. Data validation. Testing across all systems consuming location data. Reporting breaks if you don’t update historical assignments.

    Embedded structures create the restructuring nightmare Post 11 described. Separated structures enable routine strategic changes.

    What The Scenarios Reveal

    Four scenarios. Increasing complexity. Multiple relationship types. Real-world changes.

    The framework holds because:

    Master Records stay minimal. Parties, locations, networks, corporate entities — all contain only intrinsic properties. No embedded relationships. No stamped structures.

    Relationship structures handle connections. Party-to-location, corporate hierarchy, network membership, territory assignment — each is separate Master Data. Each versions independently. Each governs independently.

    Query-time composition assembles views. Reporting joins transactions, Master Records, and relationship structures using dates and versions. No pre-consolidated data. No forced migration.

    Changes affect structures, not entities. Open location, update structure. Restructure hierarchy, update structure. Change membership, update structure. Reassign territories, update structure. Master Records unchanged. Transactions unchanged.

    What breaks if you embed:

    Embed locations in party record: Opening location changes party. Closing location changes party. Every location change touches party Master Record.

    Embed hierarchy in party record: Acquisition changes every subsidiary party. Restructuring changes every affected party. Corporate changes cascade through Master Records.

    Embed discount in party record: Renegotiate terms, update every member party. Leave network, update party. Join network, update party. Contractual changes require mass party updates.

    Embed territory in location record: Restructure territories, update every location. Strategic changes become migration projects.

    Embedded structures create cascading changes. Separated structures enable isolated updates.

    The pattern is consistent across all four scenarios: separate by authority, version independently, compose at query time. Master Records hold operational authority over entity properties. Master Data holds strategic authority over structures. When structures change, Master Records stay stable.

    This isn’t just cleaner data models. It’s architecture that scales with complexity instead of breaking under it. Each new relationship type is a new structure. Each strategic change is a structure version. No migration. No reprocessing. No cascading updates.

    The Three-Layer framework separates immutable transactions from mutable structures in Post 11. The Master Data / Master Records separation prevents embedding mutable structures in entity properties. Same principle. Different application. Consistent framework.

    Understanding relationship structures as Master Data changes what’s architecturally possible. Not just theory. Strategic flexibility through proper separation.

    This post is part of the Systems Thinking Series and how the 5 authority types impact system design. Read the full series at authorityrule.com/

  • When One Entity Lives in Many Systems

    One entity, multiple systems — that’s the reality of every large enterprise.

    Customer #12345 exists in CRM, again in ERP, again in Billing. The immediate instinct is to fix it. One source of truth, says the playbook. Master Data Management will unify everything.

    I’m questioning that premise.

    Not because I’ve watched Master Data Management projects fail — although I have, repeatedly — but because I’ve watched them stall before they ever began. Teams spend months defining the business value, mapping attributes across systems, debating ownership and governance, and designing the theoretical “golden record.” Then nothing ships.

    Maybe the problem isn’t execution. Maybe the premise itself is wrong — especially for enterprises that already have functioning systems.

    Why One Entity Lives in Many Systems

    This isn’t duplication. It’s not “the same data copied everywhere,” and it’s not a quality issue waiting to be resolved. It’s specialisation.

    Different systems hold different slices of the same reality because they serve different operational purposes. CRM manages customer relationships and sales opportunities. ERP manages financial transactions. Billing manages invoices and payments. Each needs different data, different workflows, and different operational contexts.

    CRM is designed for sales performance, ERP for financial integrity, Billing for payment processing. They overlap because the real world overlaps — but that overlap isn’t an error. It’s a feature of focus.

    The Golden Record Promise

    Traditional Master Data Management promises to fix this through consolidation.

    Create a single master record — the Golden Record — that every system references. One authoritative version of the truth. One comprehensive customer profile.

    The promise is seductive: instead of scattered customer data, a single authoritative source. Instead of synchronisation problems, guaranteed consistency. Systems point to one shared entity, and inconsistency disappears.

    In practice, it rarely works that way.

    To make it happen, every existing system has to stop using its own customer table and start using the new master table. CRM must change every query, workflow, and integration point. ERP must do the same. Billing too. What sounds like a simple reference change is actually a fundamental rewrite of each system’s data model — while those systems are still running live business operations.

    The design phase can last months. The migration phase is often never completed. The risk is too high, the disruption too great, and the promised benefit too abstract to justify the upheaval.

    Maybe the problem isn’t that teams can’t execute MDM. Maybe the Golden Record itself — the idea of collapsing specialisation into one master object — is the wrong architecture for brownfield systems.

    Relationship Structures as Master Data

    The Three-Layer Architecture framework reveals a different approach: the mappings between systems are relationship structures — the third type of Master Data from Post 13. Not a workaround or an integration patch, but the structural layer that connects specialised systems into a coherent whole.

    In most enterprises, CRM holds Customer #12345 in Salesforce for sales operations, ERP holds the same entity as #98765 in SAP for financial management, and Billing keeps its own version, #45678, for invoicing. Support and Order Management have theirs as well. Each record represents the same organisation — Acme Corporation — but in a different operational context.

    Each system maintains its own Master Record, containing only the intrinsic properties it truly needs to function. CRM tracks legal name, tax ID, registration date, and primary contact. ERP maintains the corporate identifiers required for accounting and compliance. Billing stores delivery and invoice preferences. Nothing duplicated, nothing redundant, nothing derived — each record remains minimal by design.

    The connective tissue is the relationship structure itself:

    Real-world entity: Acme Corporation├── CRM: CRM-12345├── ERP: ERP-98765├── Billing: BILL-45678├── Support: SUP-11223└── Order Management: OM-99887

    These mappings — the explicit relationships that say these identifiers all refer to the same entity — are relationship structures, the third Master Data type. Governed and versioned like classification structures and operating standards, but connecting entities instead of organizing them.

    Most organisations treat this mapping data as a nuisance: integration scaffolding to be replaced once the mythical Golden Record arrives. That view misses the point. Cross-system mappings are not a symptom of fragmentation; they are a reflection of system specialisation.

    They express how reality looks inside a mature enterprise — multiple domains, each optimised for its own purpose, connected through governed relationships rather than collapsed into a single model. When recognised as Master Data, these relationship structures stop being transient and start being architectural assets.

    Architecture, Tools, Operations

    The responsibility for relationship structure data divides cleanly across three functions.

    Architecture defines what must be mapped: customer identifiers between CRM and ERP, party-to-location relationships, or product mappings across order management and billing.

    Development provides the tools — small, focused applications that maintain these relationship structures with standard interfaces and full version history.

    Operations owns the ongoing data maintenance, ensuring that when a new customer appears in ERP or a system is replaced, the relationships are updated and versioned correctly.

    This is Master Data as designed structure, not as a centralised database. The emphasis shifts from consolidation to composition — from trying to eliminate boundaries to managing them transparently.

    A customer-to-system mapping tool does one thing. A party-to-location mapping tool does another. Product taxonomies, sales hierarchies, regulatory codes — each lives in its own governed module. When cross-system reporting is required, the join happens dynamically. Data remains in its native systems; the relationship structures tell the query where to go. The result is coherent, without the cost and fragility of continuous synchronisation.

    When someone asks, “Show me all support tickets for customers with revenue greater than £1 million,” no single Golden Record is queried. The system composes the answer. CRM identifies strategic customers. Relationship structure data locates their equivalents in the Support system. Revenue is calculated from transactions. The join occurs at query time — clean, auditable, current. Nothing is duplicated, and no nightly batch tries to keep everything in sync. Truth emerges from structure, not consolidation.

    Governance Requirements

    For this model to work, relationship structure data must be treated with the same discipline as any other Master Data.

    Ownership sits with enterprise data governance, not individual system teams. Every relationship carries an effective date and version history. Historical states remain queryable, so reporting always aligns with the truth at that point in time.

    System teams remain accountable for the accuracy of their own Master Records. Governance is accountable for the accuracy and integrity of the relationship structures that connect them. That separation keeps systems autonomous while preserving enterprise traceability.

    If relationship structures are governed Master Data, integration should stop being a migration exercise. Adding a new system becomes a matter of adding relationship structure data. Replacing an existing platform means updating relationships, not rebuilding the enterprise. Even mergers become manageable: relationship alignment replaces wholesale consolidation. Truth becomes temporal and relational, not monolithic. Architecture enables composition rather than control. Systems stay focused. Data stays coherent. And the Golden Record quietly becomes unnecessary.

    Connection to the Three-Layer Pattern

    This entire model fits naturally within the Three-Layer Architecture Pattern — the framework that separates Transactions, Master Records, and Master Data.

    Transactions are immutable events — sales, invoices, payments — always tied to specific system identifiers. Master Records define the entities themselves, with time-stamped properties that evolve over time. Master Data contains the mutable structures — classifications, operating standards, and relationship structures — that give those entities context and connect them across systems.

    When all three layers work together, truth becomes traceable through time.

    To understand what was true at any given point, you only need three coordinates:

    Transaction date+ Master Record effective date+ Master Data structure version= Truth at Time T

    This formula replaces the brittle idea of a single, universal “source of truth” with a verifiable chain of evidence.

    Each layer evolves independently but remains auditable through versioning.

    You can change a classification, replace a system, or restructure an organisation without rewriting history or replatforming your data.

    That’s the architectural breakthrough the framework reveals: separating how the business operates from how its truth is constructed.

    The Three-Layer Architecture framework reveals relationship structures as the missing governance layer. Not a workaround for MDM. Not a stepping stone to Golden Records. The actual architectural pattern for brownfield enterprises.

    What This Should Enable

    The framework suggests that once relationship structures are recognised as Master Data, architectural options should expand dramatically.

    Cross-system reporting no longer requires consolidation projects. You define the relationship structure requirements, build or configure mapping tools, and maintain the data. Query-time joins handle composition dynamically. Adding a new system no longer means rebuilding interfaces or forcing migrations — you simply extend the relationship structures.

    Replacing a legacy platform becomes incremental rather than catastrophic. You update relationship structures, maintain historical versions, and preserve continuity. Mergers or acquisitions stop being years-long data integration nightmares; instead, you link ecosystems through governed relationships. Both organisations keep operating on their existing systems while shared reporting emerges through mapped relationships.

    This is the pragmatic architecture the Three-Layer framework proposes for enterprises that already run on specialised systems and can’t afford the risk or downtime of a full rebuild. It turns “integration” from a transformation programme into a living structure of governed relationships.

    The difference is profound.

    Traditional Master Data Management tries to fix inconsistency through consolidation — a data operation that requires every system to change.

    This approach resolves inconsistency through design — an architectural separation that allows systems to remain independent while still aligning at the point of truth.

    It’s not a smaller version of MDM. It’s a different pattern entirely.

    One where data remains where it belongs, and relationships — not records — form the backbone of enterprise coherence.

    This post is part of the Systems Thinking Series and how the 5 authority types impact system design. Read the full series at authorityrule.com/

  • Master Records: The Entities Themselves

    Last post established the distinction: Master Data = structures, Master Records = entities, Transactions = events. Let’s now deep dive into Master Records and how we could architect them differently.

    What Master Records Are

    Master Records are specific entities. Individual things that exist in your business.

    Customers:

    • Customer #12345 (Acme Corporation)
    • Customer #67890 (TechCo Inc)

    Products:

    • Product SKU-789 (Business Laptop Model X)
    • Product SKU-456 (Enterprise Server Model Y)

    Locations:

    • Ship-to Location SL-10001 (Acme Warsaw Plant)
    • Ship-to Location SL-10002 (Acme Krakow Plant)

    Employees:

    • Employee S-456 (Jane Smith, salesperson)
    • Employee S-789 (John Chen, account manager)

    Each one is a thing. An entity. A specific instance. Not a category. Not a structure. An actual entity with properties and a state. This matters because entities have different architectural requirements than structures.

    Master Records Have Properties

    Customer #12345 isn’t just an ID. It’s an entity with characteristics:

    Customer #12345: Acme Corporation- Legal Name: Acme Corporation Ltd- Tax ID: UK123456789- Registration Date: 2010-03-15- Primary Address: London, UK- Status: Active (i.e. its state)- Contact Email: info@acme.com

    These are properties of THIS customer. They describe THIS entity. Not customers in general. This one.

    Properties change over time. Address changes when they relocate. Status changes when the relationship changes. That’s why Master Records need time-stamping:

    Customer #12345 properties:2020-01-01 to 2023-12-31:- Address: Manchester, UK- Status: Active2024-01-01 onwards:- Address: London, UK- Status: Active

    Properties evolve. Time stamps preserve what was true when.

    This is different from Master Data versioning. Master Records track property changes. Master Data tracks structural reorganizations.

    Master Records You Create

    Not all Master Records are discovered in the world. Some you define and create yourself.

    Products you specified:

    • SKU-789: 16GB RAM, 512GB SSD, Intel i7, 14″ screen
    • SKU-456: 64GB RAM, 2TB SSD, Dual Xeon, Rack-mount

    Your Locations you designated (or the one you outsourced production to)

    • SL-10001: Berlin plant, delivery hours 8am-6pm, loading dock capacity 5 trucks
    • SL-10002: Munich plant, 24-hour operations, rail access

    You decided these entities exist. You defined their properties. You control when they change.

    You create them. You operate with them. You govern their properties.

    But you don’t organize them – that’s what Master Data structures do.

    The Separation That Changes Everything

    Here’s what the Master Data / Master Records distinction actually means in practice:

    Master Records = Entities:

    • Customer #12345
    • Properties: Name, address, tax ID
    • Changes: When entity facts change (moved, renamed)
    • Governance: Operational (sales ops, customer service)
    • Authority pattern: Operational authority over properties

    Master Data = Structures organizing entities:

    • Territory hierarchy (Strategic Accounts > North Region > Enterprise Sales)
    • Classification rules (Revenue > $1M = Strategic Account)
    • Changes: When strategy changes (territory reorganization)
    • Governance: Strategic (management, architecture)
    • Authority pattern: Strategic authority over organization

    Customer #12345 is a Master Record. The territory structure that classifies Customer #12345 as “Strategic Account in North Region” is Master Data.

    The entity exists independently of how you classify it.

    That independence is architectural. You can restructure territories without touching customer records. You can change classification rules without reprocessing entities.

    The structures are mutable. The entity facts are what they are.

    Why Traditional MDM Fails Here

    Traditional MDM conflates these. “Master Data Management” becomes “manage all the important data” without separating entities from their organizing structures.

    Result: Territory restructuring requires reprocessing customer records. Taxonomy changes require updating product definitions. Org chart changes require modifying employee records.

    Three months to change a classification structure.

    Not because the decision is hard. Because you embedded mutable structures (Master Data) in stable entities (Master Records).

    The three-layer architecture prevents this:

    Transactions reference Master Records by ID. Just the ID.

    Master Records contain entity properties. Time-stamped so you know what was true when.

    Master Data contains classification structures. Versioned independently so management can restructure without touching operational data.

    Reporting joins them at query time. Transaction date + Master Record effective date + Master Data version = correct classification for that point in time.

    No reprocessing. No propagation. Query-time assembly.

    Master Record Principles

    Understanding Master Records as entities leads to specific architectural principles.

    These seem to hold across insurance, manufacturing, housing – 12+ years building business architecture:

    Master Record Principles

    Understanding Master Records as entities leads to specific architectural principles.

    These seem to hold across insurance, manufacturing, housing – 12+ years building business architecture:

    Principle 1: Minimal necessary properties

    Store intrinsic entity facts – not derived classifications, not calculated values. Just what’s true about this entity.

    Customer #12345 has legal name (Acme Corporation Ltd) and tax ID (UK123456789), but territory assignment belongs in Master Data structures, and customer lifetime value belongs in analytics.

    Why minimal? Because every property in a Master Record requires operational governance. More properties means more governance overhead. Master Data handles classification. Analytics handles calculation. Master Records handle entity facts.

    Principle 2: Time-stamped changes

    Properties change over time, so preserve history with effective dates. No “current state only” architecture. You’ll need historical reporting, audit trails, answers to “what did we know about this customer on June 15?”

    Time-stamp from the start because retrofitting temporal data is painful. Adding effective dates after the fact breaks everything.

    Principle 3: Single source per property type

    Don’t duplicate entity facts across systems. Pick authoritative source for each property type. Customer legal name comes from CRM. Customer shipping address comes from Order Management.

    The Master Record exists across systems, but each property has single authority. This is different from “golden record” approaches that try to create one master copy. The entity exists in multiple systems. Who has authority over specific properties is what matters.

    Principle 4: Stable identifiers

    IDs don’t change, ever. Customer #12345 stays #12345 forever, even if company name changes, even if acquired, even if relocated.

    Everything else in the Master Record can change. The ID never changes.

    Why? Because Transactions reference Master Records by ID. If IDs change, you break transaction history. Stable identifiers enable everything else to be mutable.

    Customer #12345 properties (2025-10-28)

    Customer #12345 properties:2020-01-01 to 2023-12-31:Address: Manchester, UKStatus: Inactive2024-01-01 onwards:Address: London, UKStatus: Active

    Let’s deep dive into Cross-System Master Records

    In real enterprises, Master Records live in multiple systems.

    CRM has customers. ERP has customers. Billing has customers.

    Not duplicates. Not golden records. Different systems, different purposes, same real-world entity.

    Understanding Master Records as entities changes how you handle this.

    You don’t try to consolidate. You don’t create golden records. You map across systems.

    Cross-system mapping structure (Master Data):

    Entity Mapping:Real-world: Acme Corporation├── CRM: CRM-12345├── ERP: ERP-98765└── Billing: BILL-45678

    The Master Records exist in their systems, with the properties each system needs. The mapping structure (Master Data) connects them.

    This is why the Master Data / Master Records distinction matters architecturally.

    Master Records = entities in operational systems, governed operationally. Master Data = structures that organize/map entities, governed strategically.

    No golden record needed. Just well-governed mappings.

    The Minimal Principle Revisited

    Master Records should contain minimum necessary properties.

    Not because minimalism is virtuous. Because governance overhead scales with property count.

    You include identity (ID, legal name), intrinsic facts (tax ID, registration date, serial number), contact and admin details (address, email, phone), and status (active, inactive, suspended). You don’t include derived classifications like territory, segment, revenue category etc – those belong in Master Data. You don’t include structural relationships like team membership, hierarchies, or networks – those belong in Master Data. You don’t include calculated values like credit score or lifetime value – those belong in the analytics layer.

    Each property you add requires operational governance (who updates, when, how), creates dependencies (who consumes this property), and adds to change management overhead (what happens when it changes). Derive classifications from properties plus structures at reporting time. Keep Master Records minimal. Push complexity to Master Data and reporting.

    Implementation Sequence

    The Master Data / Master Records distinction seem to change the implementation sequence.

    You can’t version Master Data structures until you stabilize Master Records.

    Start with Master Records. Identify your core entities – customers, products, employees, locations. Define intrinsic properties, asking what describes THIS entity, not how you classify it. Implement time-stamping to preserve property history.

    Then analyse what should be Master Data. Pull out structures like territories, taxonomies, and org charts. Version these structures separately from entities. Create classification rules. Implement strategic governance where management controls structures.

    Then remove the embedded structures from the Master Records – no territory assignments, no hierarchies. Establish operational governance around who updates what and when.

    Lastly, join everything at reporting time where properties plus structures equals classifications.

    Master Records are the foundation. Master Data structures organize them. Build a stable foundation first.

    To my understanding, this is the opposite of traditional MDM, which tries to build golden records (entities plus classifications) first. Understanding the distinction changes the implementation sequence.

    What This Changes

    Get Master Records right – stable entities with time-stamped properties – and Master Data becomes manageable.

    Get Master Records wrong – embedded structures, missing time-stamps, bloated properties – and Master Data governance becomes impossible.

    The distinction isn’t semantic. It’s architectural.

    Master Records = Stable entities with time-stamped properties

    • Operational governance
    • Property-level authority
    • Changes when entity facts change

    Master Data = Mutable structures organizing entities

    • Strategic governance
    • Structure-level authority
    • Changes when strategy changes

    Transactions = Minimal references to Master Records

    • Just IDs
    • Immutable events
    • No embedded properties

    Reporting = Query-time assembly

    • Join Transaction + Master Record + Master Data
    • Use effective dates and version numbers
    • Reconstruct classification at any point in time

    Clean separation. Clear governance. Operational stability. Strategic flexibility.

    That’s what the Authority rules give you with regards to Master Records as entities.

    Not just “entities to manage.” Foundation for architecture that scales.

    This post is part of the Systems Thinking Series and how the 5 authority types impact system design. Read the full series at authorityrule.com/

  • Master Data: The Layer That Changes

    Three layers solve the restructuring problem. Transactions (immutable facts), Master Records (entity properties), Master Data (classification structures).

    We’ve covered why embedding structures in transactions creates architectural and business challenges. As I explained in The Three-Layer Architecture Pattern, separating these layers enables strategic flexibility.

    Now: Master Data specifically. Because this is the layer that the Authority Rule changes the most. Reference Data is not Master Data – that’s easy to understand. Master Data as Structure – can be a bit harder to get your head around.

    What Master Data Actually Is

    Master Data is structures, not entities.

    Not individual customers. Not specific products. Not particular locations, those are Master Records. Instead, Master Data is the organizational framework you use to classify and organize those entities.

    Classification structures: Territory hierarchies that organize customers by strategic importance and geographic coverage. Product taxonomies that group items by function, market, or business line. Org structures that define teams, divisions, and reporting relationships. Customer segmentation models that classify accounts by revenue potential, service requirements, or strategic value.

    Relationship structures: Party-to-location assignments that map which customers use which shipping addresses. Cross-system mappings that connect CRM-12345 = ERP-98765 = same real-world entity. Corporate hierarchies that define subsidiary relationships, ownership structures, and consolidation rules.

    Operating structures: Payment terms (Net30, Net60, Net90) – the standardized payment timing options you offer. Service tiers (Bronze, Silver, Gold, Platinum) – the standardized service levels you’ve structured. Party involvement types (Bill-to, Ship-to, Payee, Payer) – the standardized operational roles in your business processes. Delivery methods (Standard, Express, International) – the standardized fulfillment options you provide.

    These structures are Master Data. Not because they’re “important data.” Not because they’re “golden records.” Because they’re organizational frameworks that management controls and they change when the strategy changes. As I explained in Master Data vs Reference Data, authority determines classification.

    What Master Data Is NOT

    This distinction matters.

    Master Data is NOT individual entities. Customer #12345 is a Master Record. Product SKU-789 is a Master Record. Ship-to Location SL-10001 is a Master Record. Employee S-456 is a Master Record.

    Master Data is NOT entity properties. Customer’s address is a Master Record property. Product specifications are Master Record properties. Location delivery hours are Master Record properties. Employee hire date is a Master Record property.

    Master Data is NOT transaction data. The sales order is a Transactional Record, governed by Contract Authority (the agreement). The invoice and payment are also Transactional Records.

    Master Data is the STRUCTURES organizing these entities. The hierarchies. The classifications. The mappings. The assignment rules. Not the things themselves. The frameworks for organizing things.

    As I explained in Master Data, Master Records, and Transactions: The Distinction That Clarifies Everything, authority type determines how data changes. Master Data has internal strategic authority – management controls these structures and changes them when strategy changes. Territory structures, product taxonomies, org hierarchies – all under management’s authority.

    The Three Structure Types In Detail

    Classification structures organize entities into hierarchies.

    Territory hierarchy example:

    Enterprise Sales├── North Region│   ├── Strategic Accounts│   │   └── Criteria: Revenue > $1M, Country = US/CA/UK│   └── Growth Accounts│       └── Criteria: Revenue $250K-$1M└── South Region    └── Emerging Markets```

    Management controls this structure. They can reorganize, split the North Region into North Enterprise and North Mid-Market, combine the South Region with Emerging Markets, and redefine the Strategic Accounts threshold from $1M to $5M.

    The structure is mutable, strategic, under management authority.

    Operating structures define how your business operates.

    Payment terms:
    Net30
    Net60
    Net90
    Due on Receipt
    2/10 Net 30

    These are strategic choices. Management decides which payment options to offer, can add new terms (Net45), remove unused terms, change terms based on market conditions.

    Service tiers:

    Bronze: Basic support, 48-hour response
    Silver: Priority support, 24-hour response
    Gold: Dedicated support, 4-hour response
    Platinum: 24/7 support, 1-hour response

    Management defines these tiers, can restructure service levels, add premium tiers, consolidate tiers, change response time commitments.

    The structures define operating reality. Management controls them. They change when strategy changes.

    Relationship structures map connections between entities.

    Party-to-location assignment example:

    Customer: #12345 (Acme Corporation)Ship-to Locations:  - Warsaw plant  - Krakow distribution  - Berlin office  - Prague warehouse  - Budapest facility  - Vienna office  - London headquarters```

    This mapping is Master Data. The customer entity is a Master Record. Each location is a Master Record. The party-to-location relationship structure maps which locations belong to which customer.

    When Acme acquires a new facility or closes an existing one, you update the relationship structure. Customer Master Record unchanged. Location Master Record unchanged (or added/inactivated). Relationship structure updated.

    Real-world entity: Acme Corporation

    Real-world entity: Acme CorporationCRM System: CRM-12345ERP System: ERP-98765Billing System: BILL-45678

    The mapping structure connects these. No golden record needed. Just well-governed mappings maintained as Master Data.

    Why This View Is Different

    I initially thought there might be two types of Master Data. Classification structures (territories, taxonomies) felt different from operating structures (Net30, service tiers). They seemed like separate categories requiring different treatment.

    But working through the Authority Rule framework revealed a pattern: it’s ALL structures. Just structuring in different ways.

    Classification structures organize entities into hierarchies. Operating structures define how your business operates. Relationship structures map connections between entities. All three are organizational frameworks management creates to run the business.

    None of them are the entities themselves. That’s the distinction.

    To my understanding, traditional Master Data Management conflates Master Records (the entities) with Master Data (the structures organizing them). “Master Data Management” becomes “manage all the important stuff” without separating what things are from how you organize them. They want to create ‘golden records’ for these – the focus is on the entities

    This framework separates them. Master Data = structures. Master Records = entities. Different authority. Different mutability. Different governance.

    Authority Determines Mutability

    From Master Data, Master Records, and Transactions: The Distinction That Clarifies Everything: authority type determines how data changes.

    Reference Data (external authority): You can’t redefine ISO 3166 country codes. They change when ISO changes them. Immutable from your perspective.

    Master Data (internal strategic authority): Management controls these structures. They redefine when strategy demands. Territory hierarchies reorganize. Product taxonomies restructure. Service tiers change. Mutable by design.

    Master Records (internal operational authority): Properties change when entity facts change. Customer relocates, revenue grows, status changes. Time-stamped changes, not strategic restructuring.

    As I explored in Contracts: The Fifth Authority Type, Contractual Authority is Bilateral binding agreement that locks specific versions of Master Data and Master Records for the contract duration. Neither party can unilaterally change the bound terms. Courts arbitrate disputes.

    Transactions (captured authority): What happened stays what happened. Immutable truth. Customer bought product for amount on date – that’s a fact that doesn’t change.

    Different authority. Different mutability. Different governance. Keep them separate in architecture.

    Versioning Master Data

    Since Master Data structures change when strategy changes, version them independently from Transactions and Master Records.

    Territory structure v1.0 (effective 2020-01-01 through 2025-12-31):

    Regional Sales containing North Region and South Region.

    Territory structure v2.0 (effective 2026-01-01 onwards):

    Enterprise Sales containing North Region Enterprise and South Region Enterprise, plus Mid-Market Sales containing North Region Mid-Market and South Region Mid-Market.

    Both versions exist. Historical transactions use v1.0 when reporting 2023 data. Current transactions use v2.0 when reporting 2026 data. Trending across the change? System joins transaction date with appropriate structure version automatically.

    No reposting. No migration. Update structure, version it, reporting adapts.

    This works because the transaction never stored the classification. It only stored Customer ID and date. The system determines which territory structure to apply at query time, not storage time. Nothing to convert because nothing was classified when the transaction was captured.

    This is different from the mapping tables rejected in the previous post about restructuring. Those mappings translated between versions of embedded structures—Old_Territory → New_Territory chains that compound forever.

    Instead, these structures ARE Master Data—first-class architectural components that define entity connections. Party-to-location assignments don’t fix bad architecture. They ARE the architecture for managing relationships.

    Does This Architecture Work?

    I haven’t implemented this exact Master Data versioning architecture in a production system. But across insurance, manufacturing, banking – 12+ years as business architect – every restructuring nightmare I’ve seen comes so far from the same pattern: mutable structures embedded in immutable transactions.

    Authority Rule reveals what’s needed: separate by authority type. Master Data (strategic, mutable structures) in one layer. Master Records (operational, time-stamped entities) in another layer. Transactions (captured, immutable facts) in a third layer. When you separate them, restructuring becomes routine instead of exceptional.

    I’m testing this separation principle against real architectural scenarios. Every domain I’ve applied it to validates the pattern. Embedded structures always create a restructuring problem. Separated layers always enable flexibility.

    The framework suggests this is what enables strategic flexibility without breaking operational stability. I’m working to prove it.

    Governance By Authority Type

    Master Data governance is strategic, not operational.

    Who governs Master Data: Management, architecture, business stakeholders who define strategic frameworks. Not operational teams who maintain entity data.

    What they govern: Classification structures, operating standards, relationship mappings. Not individual entity properties.

    How it changes: Strategic decision-making. Territory reorganization requires management approval. Service tier restructuring requires executive sign-off. Cross-system mapping changes require architectural governance.

    Why it matters: Master Data changes affect reporting, analytics, strategic metrics. Changes aren’t just “data updates” – they’re strategic decisions with business impact.

    Contrast with Master Records governance (operational – sales ops maintains customer properties, product managers maintain SKU specs) and Transactional Records governance (none – transactions are immutable).

    Different authority requires different governance. Separate the layers, separate the governance models.

    Why This Matters

    Strategic flexibility requires architectural separation.

    If management can’t restructure territories without 3-month projects, architecture constrains strategy. If product teams can’t reorganize taxonomies without data migration, architecture blocks evolution. If finance can’t redefine cost centers without reposting transactions, architecture creates rigidity.

    Master Data as versioned structures enables strategic flexibility. Restructure when business needs it. Version the change. Reporting adapts automatically. Transactions unchanged. Master Records unchanged. No migration. No reposting.

    Business moves at business speed. Not IT speed.

    That’s not “cleaner data architecture.” That’s competitive advantage. Competitors stuck with embedded structures take months to adapt. You take days. That’s the difference between architecture that enables and architecture that constrains.

    The Test

    Next time someone says “We need to restructure territories,” ask: “How long will it take?”

    If the answer involves reposting transactions or migrating master data, structures are embedded where they shouldn’t be.

    If the answer is “Update the structure, version it, done,” structures are properly separated as Master Data.

    One architecture enables strategy. The other constrains it.

    Next post: Master Records: The Entities Themselves – the entities that Master Data structures organize.

    This post is part of the Systems Thinking Series and how the 5 authority types impact system design. Read the full series at authorityrule.com/

  • The Three-Layer Architecture Pattern

    The premise is that embedding Master Data in transactions makes restructuring expensive and brittle.

    Territory hierarchies baked into sales records. Product classifications locked into invoices. Customer segmentations part of financial transactions. When management wants to reorganize, you need either to repost transactions. Or you build mapping tables. Or you accept broken historical reporting.

    The Authority Rule points to a different Architecture. The distinction between master data, master records, and transactions separates what happened from how you classify it.

    Three layers. Separate what happened from how you classify what happened. Separate entity facts from organizational structures. Each layer governed differently, each layer versioned differently, each layer serving its own purpose.

    Keep them separate, and restructuring becomes (hopefully) trivial.

    The Three Layers

    Layer 1: Transactions – What happened. Immutable facts captured at the moment of occurrence.

    Layer 2: Master Records – Entity properties that define specific entities: this customer, this product. Time-stamped so you know what was true when.

    Layer 3: Master Data – Classification structures and operating standards that organize entities. Versioned independently so management can restructure without touching operational data.

    Each layer has different authority. Different mutability. Different governance. The architecture works because you keep them separate and join them only when reporting.

    Layer 1: Transactions – Immutable Facts

    Store the absolute minimum. Entity identifiers, amounts, dates. Reference Data that’s a fact about this specific transaction.

    Transaction ID: TXN-2025-10-15-001Amount: $50,000Customer ID: #12345Product ID: SKU-789Salesperson ID: S-456Date: 2025-10-15Currency: USD

    That’s it. No territory hierarchy. No product classification. No customer segmentation. Just the facts about what happened.

    As I explored in Transactions: Why Embedding Structures Breaks Everything, transactional records have ‘captured authority – the system recorded what happened, and you can’t change what happened. This transaction stays this way forever.

    Everything else – how you classify this sale, which territory you assign it to, which product hierarchy you organize it under – lives in other layers.

    Layer 2: Master Records – Entity Properties

    Time-stamped properties that define specific entities. Customer moved from England to Scotland? Product specifications changed? Location delivery hours updated? Time-stamp the change in the Master Record.

    Customer #12345:

    Effective 2020-03-01 to 2025-09-30:- Country: UK- Address: 45 London Road, ManchesterEffective 2025-10-01 onwards:- Country: UK- Address: 123 Main St, Glasgow

    Every transaction references the entity ID. When reporting, the system joins transaction date with Master Record effective dates automatically. Transaction from June 2025? System uses the English properties. Transaction from November 2025? System uses Scottish properties.

    No reposting. No manual updates. Time-stamping handles it.

    Master Records have “your authority, typically operational” – these are the entities your business operates with, and you control when their properties change. I explore this in depth in Master Records: The Entities Themselves.

    Layer 3: Master Data – Classification Structures

    This is where organizational strategy lives. Territory hierarchies. Product taxonomies. Org structures. Operating standards like payment terms and service tiers. Relationship mappings like party-to-location assignments.

    These structures change when strategy changes. This is why master data is the layer that changes. Version them independently from transactions and Master Records.

    Territory structure effective Q1 2025:

    Enterprise Sales├── North Region│   ├── Strategic Accounts (Revenue > $1M, Country = US/CA/UK)│   └── Growth Accounts (Revenue $250K-$1M)└── South Region    └── Emerging Markets

    Territory structure effective Q1 2026 (strategy shifted):

    Enterprise Sales├── Global Strategic (Revenue > $5M, any country)├── Regional Enterprise (Revenue $1M-$5M)│   ├── North America│   └── EMEA└── Growth Segment (Revenue < $1M)

    Same transactions. Same Master Records. Different classification structure.

    How Reporting Joins the Layers

    Query: “Show me sales by territory for Q4 2025”

    System process:

    1. Transactions layer – Pull all transactions from Q4 2025, get Customer IDs
    2. Master Records layer – Join Customer IDs with properties effective during Q4 2025
    3. Master Data layer – Apply territory rules effective during Q4 2025
    4. Result – Sales classified by territory as it was structured in Q4 2025

    Now run the same query for Q4 2026. The system automatically uses the territory structure effective in Q4 2026. Different classifications. Same transactions. Same Master Records.

    When you restructure territories in January 2026, you update the Master Data layer. Version it. Effective date: 2026-01-01.

    Transactions unchanged. Master Records unchanged. Historical reporting uses old structure. Future reporting uses new structure. Trending across the change? System handles it automatically by joining appropriate versions.

    No reposting. No mapping tables. No data migration. Update the structure, version it, reporting adapts.

    Why This Matters

    The traditional approach embeds structures in transactions. Want to reorganize territories? In several systems, you then have to repost every transaction to reflect the new hierarchy. Or change your Data warehouse. Want to change product taxonomy? Update thousands of records. Want to implement new customer segmentation? Potentially a data migration project, not between systems, between structures.

    Expensive. Slow. Error-prone.

    Three-layer architecture separates immutable facts (transactions) from stable properties (Master Records) from mutable structures (Master Data). Each layer governed independently. Each layer versioned appropriately.

    Management changes strategy? Update Master Data. New effective date. Done. Transactions and Master Records stay untouched. Historical reporting still works. New reporting uses new structure automatically.

    That’s strategic flexibility. That’s operational stability. That’s architecture that enables business to move at business speed rather than IT speed.

    Next post: Master Data: The Layer That Changes – what Master Data actually is, what it contains, and how versioning classification structures independently creates flexibility without chaos.

    This post is part of the Systems Thinking Series and how the 5 authority types impact system design. 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/

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