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:
- Find all Orders with order date in Q1 2026
- For each Order, get Customer ID
- For each Customer, get Master Record properties as of order date
- Apply Territory Structure version effective for order date
- Classify Order by territory
- 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:
- Find all Orders with order date in Q1 2026
- Classify using Territory Structure v1.0 (before restructure) → Q1 sales by old territories
- Classify same Orders using Territory Structure v2.0 (after restructure) → Q1 sales by new territories
- 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/
Leave a Reply