Master Data vs Transactional Data vs Configuration

This is the first real ERP concept. Every table in an ERP falls into one of four buckets, and the bucket determines its lifecycle, its ownership, its migration strategy, and how you’re allowed to change it.

The four buckets

Bucket	Changes	Volume	Example	Who owns
Configuration (customising)	Rarely, by a consultant, moved via transport/deployment	Tiny	Document types, posting keys, tax codes, number ranges	Functional consultant
Master data	Occasionally, by business users	Thousands–millions	Customer, Vendor, Material, GL Account, Employee, Cost Centre	Data steward / MDM team
Transactional data	Constantly, by business events	Millions–billions	Sales order, invoice, journal entry, goods movement	The business, via processes
Derived / aggregate	Computed	Varies	Balances, totals, indices, MRP results	The system

Configuration is data, not code

The defining trick of packaged ERP: behaviour lives in tables.

Instead of if (documentType == "invoice") { ... }, the system reads a config table:

Document Type  Number Range  Posting Key  Reversal Type  Field Status Group
RE (Invoice)   51            31           AB             G067
KZ (Payment)   15            25           AB             G001

Consequences you must internalise:

Two customers on the identical binary behave completely differently. “The system does X” is meaningless without “in this config”.
Config moves between environments as a deployable artefact (SAP transports, Dynamics config packages, NetSuite SuiteBundles, Odoo data XML).
Config is versioned and audited — changing a posting rule in production is a controlled change, not a settings toggle.
A huge share of “development” requests are actually config requests. Always check config first. See Requirements and Fit-Gap.

Master data: the entities everything points at

The classic master data objects:

Object	Also called	Key attributes
Customer	Debtor, Sold-to, Business Partner	Payment terms, credit limit, tax class, price list, ship-to addresses
Vendor	Supplier, Creditor	Payment terms, bank details, currency, incoterms
Material	Item, Product, SKU, Part	UoM, valuation class, MRP type, lead time, plant/warehouse data
GL Account	Ledger account, Natural account	Type (asset/liability/income/expense), reconciliation flag, currency
Cost Centre / Profit Centre	Department, Business unit	Hierarchy, responsible person, validity dates
Employee	Personnel number, Worker	Org assignment, pay grade, cost centre
Asset	Fixed asset	Class, depreciation method, useful life, cost centre
BOM	Bill of Materials, Parts list	Components, quantities, validity
Routing	Operations, Work plan	Work centres, times, sequence
Price / Condition record	Price list entry	Validity, scale, customer/material key

Properties of master data

Long-lived — a customer created in 1998 is still referenced by 2026 invoices.
Referenced, not copied — except when it is. Master data is referenced by transactions, but critical attributes are usually snapshotted onto the document at creation time (the price, the address, the tax code). Otherwise reprinting a 2019 invoice would show today’s address. This is one of the most important design patterns in ERP.
Cannot usually be deleted — you mark for deletion or block. Referential integrity plus audit forbids hard delete.
Effective-dated — many attributes are valid-from/valid-to, not simple columns.
Multi-level — master data often has a global level plus org-level extensions:

Material 10023
├── General data (description, base UoM, weight)        ← global
├── Plant DHK1 (MRP type, lead time, reorder point)     ← per plant
├── Plant CTG2 (different lead time)
├── Sales org 1000 (sales UoM, tax class, price group)  ← per sales org
└── Valuation area DHK1 (price control, standard cost)  ← per valuation area

This “one object, many org-level views” shape is universal across ERPs and surprises developers coming from flat CRUD apps.

Master data governance (MDM)

Bad master data is the #1 cause of “the ERP is wrong”. Typical controls:

Approval workflow on creation/change of critical fields
Duplicate detection (fuzzy matching on name/tax ID/address)
Mandatory field rules by material type / account group
Data stewards — named humans accountable per object
Golden record / single source of truth — one system creates it, others subscribe
Change audit on every field

Transactional data: the events

A transaction is a business event, recorded, usually as a document.

Characteristics:

Has a document number from a controlled number range
Has a posting date (accounting period) and a document date (real-world date) — these differ, and it matters
Is immutable once posted; you correct it with a reversal or credit note
Carries a snapshot of relevant master data
Links to other documents (document flow) — order → delivery → invoice
Has header + line items, almost always

See Documents and Document Flow.

Derived data

Balances, aggregates, indexes, MRP results, ATP snapshots.

Rule: derived data must be reproducible from transactions. If you can’t rebuild it, you have a second source of truth and eventually a discrepancy nobody can explain.
Classic ERP design carried totals tables (materialised balances) for performance, updated in the same transaction as the line item. In-memory systems (HANA) removed many of them and aggregate on the fly.
If you build your own: keep a journal_line as truth and treat account_balance as a rebuildable projection with a reconciliation job.

Why the distinction drives everything

Question	Answer depends on bucket
How does it get to production?	Config → transport. Master → load/interface. Transaction → created by users
Who can change it?	Config → consultants. Master → stewards. Transaction → process
Can I delete it?	Config → sometimes. Master → block, not delete. Transaction → never
Migration approach?	Config → rebuilt by consultants. Master → cleansed and loaded. Transaction → open items + balances only
Testing?	Config → regression suite. Master → data quality rules. Transaction → process tests

Migration rule of thumb

You do not migrate history. You migrate:

All active master data (cleansed, deduplicated)
Open items only — open POs, open sales orders, open AR/AP items, current stock
Balances — GL opening balances as of cutover date
History stays in the legacy system (kept read-only) or lands in a data warehouse.

Anyone who asks you to migrate ten years of posted invoices into the new ERP needs to hear this. See Data Migration.