ERP for Beginners: Master Data vs Transactional Data — the Two Kinds

If you spend any real time inside an ERP — not reading about one, but actually working with one — you quickly notice that not all data in the system is the same. Some records sit there for years, quietly, rarely changing, referenced by everything. Other records are created by the thousand every day, each one timestamped, each one a moment in the life of the business. They're stored in the same database. They share foreign keys. They look, at first glance, like the same kind of thing.

They are not the same kind of thing. The ERP world has a sharp, formal distinction for them — master data and transactional data — and understanding that distinction is, after customisation-vs-configuration, the second most important mental model in the whole field. It determines who owns what, how changes are governed, how failures propagate, and why so many ERP projects spend more on data cleanup than on the software itself.

This is episode two of Season Two of ERP for Beginners — Going Deeper — and we're going to unpack the two data types properly. What master data is, what transactional data is, why they're treated completely differently, where things go wrong, and why big companies have dedicated teams whose entire job is managing master data.

What master data is

Master data is the slow-changing, shared reference data that describes the things your business deals with. If you imagine the business as a play, master data is the cast list and the props inventory — the named actors and objects that exist independently of any particular scene.

A partial list of what's typically master data in an ERP:

• Customer master — every customer your business sells to. Their name, address, payment terms, credit limit, tax registration, contact people.
• Vendor master — every supplier you buy from. Their bank details, payment terms, tax codes, preferred currency.
• Material master — every product, raw material, or part you make, buy, or sell. Its description, unit of measure, standard cost, valuation method, weight, dimensions.
• Employee master — everyone in the HR system. Their role, department, cost centre, reporting line.
• Asset master — every fixed asset that depreciates. Its purchase date, book value, depreciation method.
• Chart of accounts — the GL accounts themselves. Each account number, its type, its grouping.

Three things characterise master data:

It's slow-changing. A customer record might live for years before anything on it changes. A material master might never change after it's created. Changes, when they do happen, are events — a customer moves address, a vendor's bank details update, a material is superseded by a new version. These are few and specific.

It's shared. The same customer master record is referenced by every sales order, every invoice, every credit note, every customer payment, every credit decision. The same material master is referenced by every purchase order, every goods receipt, every production order, every inventory movement. The reference count is enormous. Changing a master record changes the meaning of thousands of transactions that reference it.

It's authoritative. When a master record says the customer's payment terms are Net 30, that's the truth the entire system uses. If that value is wrong, every invoice issued to that customer for the next year will be wrong. Master data is where truth lives.

What transactional data is

Transactional data is the high-volume, event-driven, timestamped data that records what happens in the business over time. Continuing the theatre analogy — if master data is the cast list, transactional data is every line the characters actually say, in the order they say it.

Typical transactional data:

• Sales orders, deliveries, invoices — every customer interaction, each one a dated event.
• Purchase orders, goods receipts, vendor invoices — every procurement event.
• Journal entries — every line in the general ledger, each one with a date, an amount, and a set of dimensions.
• Inventory movements — every goods issue, goods receipt, stock transfer, adjustment.
• Production confirmations — every shop-floor report of work completed.
• Payroll runs, timesheets, expense claims — every HR or finance event.

The opposite three properties apply:

It's high-volume. A business might create one new customer a month and ten thousand sales orders. The ratio between master data and transactional data is typically 1:1000 or higher. In a large enterprise, the transactional tables dwarf the master data tables by many orders of magnitude.

It's single-purpose. Each sales order belongs to one customer, one sales org, one date. It's not "shared" in the same way a master record is — it's a specific event that happened. You don't update last year's sales orders because the customer changed address; you leave them as-is, because they record what was true at the time.

It's derivative. Every transactional record references master data to get its meaning. A sales order is just a quantity, a date, and a set of pointers — to a customer, to a material, to a sales org. If the master data behind those pointers is wrong, the transaction inherits that wrongness.

The rules are completely different

Because of those differences, ERPs treat the two data types with completely different rules.

Governance. Master data changes go through controls. Creating a new customer typically requires credit approval, tax validation, sometimes duplicate checking against existing records. Changing a vendor's bank account is one of the most scrutinised events in any ERP system, because if it happens fraudulently, your next payment goes to a criminal. Transactional data, by contrast, is created by the business all day long through normal transactions. Nobody approves every purchase order; the approval rules are built into the workflow configuration.

Storage and archival. Master data stays in the live system indefinitely; a customer from 2015 is still in the customer master because there may still be aged invoices referring to them. Transactional data, after a few years, is archived to cold storage to keep the live tables fast. Finance regulations dictate minimum retention periods, but the business rarely queries journal entries from a decade ago in real time.

Change history. Master data changes are audited line by line. Every change to a customer record leaves a log — who changed what, when, and what the old value was. Transactional data doesn't get "changed" — a sales order gets cancelled and replaced, or reversed with an offsetting entry. The transactional story is append-only.

Ownership. Master data is usually owned by specific business functions — the finance team owns the chart of accounts, the sales team owns customer master, the procurement team owns vendor master. Large companies have formal data owners and data stewards — people whose job description includes "keep the vendor master clean." Transactional data doesn't have a single owner; it's the record of the business operating.

Master data is where things go wrong

For anyone new to ERP, the instinct is to think of master data as boring setup work — the dull bit you do before you start using the system. That instinct is dangerously wrong. In practice, master data is the single most common source of problems in an operational ERP system. And it's worth understanding why.

The scariest property of master data is that it's shared and propagating. A mistake in a master record doesn't break one transaction — it breaks every transaction that references that record, and it does so silently. A customer master with the wrong VAT number will produce thousands of invoices with the wrong tax treatment, and the finance team may not notice for months. A material master with the wrong unit of measure will misreport stock levels across every plant. A vendor master with an incorrect bank account will send every payment to the wrong place until someone catches it.

The second scariest property is that duplicates are invisible failures. If the same customer is accidentally created twice — say, "Acme Corp" and "ACME Corporation" — the system happily treats them as two separate customers. Their invoices don't consolidate on aging reports. Their credit limits don't combine. Your CRM thinks you have two customers; your accounts receivable team thinks one of them is late paying. The two records may never reconcile until someone manually merges them — which itself is a heavyweight operation involving re-pointing every historical transaction.

The third is stale data. A customer moved five years ago. A vendor was acquired and renamed. An employee changed departments. If the master data doesn't keep up, the system keeps operating on yesterday's reality, quietly generating wrong reports, invoices to the wrong address, payroll against the wrong cost centre.

A well-run ERP, in practice, is mostly a well-governed master data set plus a configured transaction engine. The config-vs-customisation decision gets all the attention during implementation, but the day-to-day quality of the system depends overwhelmingly on how well master data is maintained.

Why MDG exists

Large companies have learned, often painfully, that master data management doesn't happen by itself. The discipline has a name — Master Data Management (MDM) in the generic term, Master Data Governance (MDG) in SAP's specific product — and it's a multi-billion-dollar software category in its own right.

What MDM/MDG actually does:

Workflow-driven creation. A new customer can't be created with one-click entry; the request goes to the credit team, then the tax team, then sales ops, each with their own fields to fill in. By the time the record exists in the operational ERP, it's been validated by multiple stakeholders.

Duplicate prevention. When someone submits "Acme Corp", the system does fuzzy matching against existing records and suggests "you may mean ACME Corporation (existing customer 4712)." This single feature, if it actually works, saves downstream reconciliation nightmares.

Central hubs for distributed systems. Big enterprises don't have one ERP — they have multiple SAP systems, Salesforce on the side, a payroll SaaS, a legacy tool still running in one subsidiary. A central MDM hub is the single source of truth; master data flows from the hub out to all the consuming systems, rather than each system maintaining its own copy.

Change auditing at source. Every attempted change is logged, including rejections. Bank-account changes typically require two-person approval and notification back to the vendor through an independent channel.

MDM/MDG is not glamorous work. But mature organisations invest in it precisely because the cost of bad master data — recovered revenue, compliance fines, re-worked invoices, duplicate payments, tax errors — adds up to more than the cost of the tooling many times over.

Why this mental model matters

Pull it all together. Every ERP you encounter has two kinds of data in it. Master data is the slow-moving foundation — the customers, vendors, materials, accounts, employees that the business operates on. Transactional data is the fast-moving record of what happened — the orders, invoices, journal entries, goods movements that are created and closed over the normal rhythm of the business.

They have different governance, different lifecycles, different failure modes, different owners. Master data problems are propagating and silent; transactional data problems are local and loud. An ERP project that nails the configuration and customisation but neglects master data quality is an ERP project that will limp for years.

For anyone new to ERP — whether you're using one, evaluating one, or building something adjacent — the single most practically useful skill you can develop is the instinct to distinguish these two at a glance. When someone says "we have a customer data problem," they almost never mean "our sales orders are wrong." They mean "our customer master is inconsistent, and it's breaking the sales orders." The fix isn't in the transaction layer; it's in the master data layer. Knowing which layer you're looking at is half the diagnostic work.

What's next

That's master data versus transactional data. Slow-changing, shared, authoritative on one side. High-volume, derivative, timestamped on the other. The rules, the governance, the ownership all diverge — and most ERP operational pain lives on the master side.

Episode three takes the two data types and follows one through the system, end-to-end. A single sales order, from creation through delivery through invoice through journal entry through management reporting — every module it touches, every master record it reads, every transactional record it spawns. The thread that ties the whole ERP together.

See you there.