Master data vs transactional data – the foundation under every ERP system

Whether you're implementing a new ERP system, building a data warehouse or planning a migration, one distinction is fundamental: the difference between master data and transactional data.

Most migration projects pour their energy into moving millions of transactional records from one system to another. But in the projects I run, the biggest risks rarely sit in the transactions. They sit in the quality of the master data those transactions depend on. Get the distinction wrong and you'll spend go-live firefighting problems you could have prevented during design.

What is master data?

Master data describes the core entities a business operates with – the records that give every process its context and meaning. Typical examples:

• Customers
• Suppliers
• Products and materials
• Employees
• Cost centers
• Chart of accounts
• Warehouses

A single master record can live for years and be referenced by thousands of transactions. For example:

Customer ID	Customer name	Country
C1001	IKEA AB	Sweden

This record doesn't represent an event. It represents a business entity – something that simply is.

What is transactional data?

Transactional data records business activities and events as they happen. Typical examples:

• Sales orders
• Purchase orders
• Invoices
• Deliveries and goods receipts
• Payments
• Journal entries

For example:

Sales order	Customer ID	Date	Amount
SO12345	C1001	2025-05-14	€15,000

Unlike master data, transactional data never stops growing. Every order, shipment and payment adds another row, forever.

How the two relate

Master data is the context that makes a transaction meaningful. A transaction without it is just numbers with nowhere to land.

Without a valid customer record, there is no sales order. Without a product, there is nothing to sell – or to buy on a purchase order. Without a chart of accounts, the finance team can't post anything correctly. And most transactions point to more than one master object: a purchase order combines a supplier with the products being ordered. Master data comes first, logically and practically.

Why this matters during migration

A common misconception is that transactional data is the most important thing to migrate, because it's the largest volume. In practice, poor-quality master data causes far more business disruption.

Consider a single customer record carrying:

• Incorrect payment terms
• Invalid tax information
• A duplicate twin
• Missing ownership

Every transaction that references that customer inherits the problem. One bad master record can quietly corrupt thousands of orders, invoices and postings. That's the leverage – good or bad – that master data has.

The typical migration sequence

This dependency is exactly why master data is migrated before transactional data. A simplified sequence looks like this:

1. Master data first

1. Chart of accounts
2. Cost centers
3. Suppliers
4. Customers
5. Products

2. Transactional data second

6. Open purchase orders
7. Open sales orders
8. Inventory balances
9. Open invoices

Transactions can only be loaded once the master records they point to already exist in the target system. Reverse the order and the loads fail – or worse, succeed against the wrong references.

Governance starts with master data

Organisations routinely invest heavily in the ERP implementation while overlooking master data governance. The result is predictable: duplicate customers, inconsistent product hierarchies, unclear ownership, unreliable reporting, and users who stop trusting the system.

Strong governance is mostly about keeping master data trustworthy over time, so that the operational transactions built on top of it stay reliable. The transactions take care of themselves once the foundation is sound.

A simple rule of thumb

When you're not sure which kind of data you're looking at, ask:

"Who, what or where is it?" → probably master data. "What happened?" → probably transactional data.

Data object	Type
Customer	Master data
Supplier	Master data
Product	Master data
Cost center	Master data
Sales order	Transactional data
Purchase order	Transactional data
Invoice	Transactional data
Payment	Transactional data

Final thoughts

A successful migration isn't really about moving data from one system to another – it's about preserving business meaning. Master data defines the business; transactional data records it.

When master data is trusted, transactions become reliable, reporting becomes meaningful, and the whole transformation gets dramatically less risky. So before you worry about the millions of transactions, make sure the foundational master data is fit for purpose. In most projects, that's where the real value is created.

Wrestling with master data quality ahead of a migration or ERP change? Get in touch – I'm happy to talk through how I'd approach it.