Master data and transaction data: what must stay stable and what changes with each order

This page separates reusable reference information from the facts created by one specific order or business event

A business needs some information again and again. The same approved product description, supplier identity, customer identity or size range may support many orders. Other information exists only because one order, receipt, inspection, shipment or invoice happened. Mixing those two kinds of information creates avoidable mistakes.

In this lesson, master data means stable reference information that is maintained once and reused across many transactions. Transaction data means information created by one specific business event. “Stable” does not mean “never changes.” It means the value should change only through controlled maintenance, not because someone copied a different value from an old order. The practical goal is simple: reuse what should be reusable, and create a fresh, traceable record for what belongs to each new transaction.

What you need, and what this lesson does not cover

You need: the ideas from lessons 1.1 and 1.2: every important field needs an accountable owner and approved source, and the team should keep one approved current version.

By the end of this lesson you can:

• explain master data and transaction data in plain business language;
• decide whether a field should be reused or created for each event;
• stop one past order from becoming the permanent rule for future orders;
• preserve historical transaction values when reference information is revised;
• identify which team should control a reusable record.

Not covered here: database design, software configuration, technical data models or a specific ERP or PLM product. The lesson stays vendor-neutral and focuses on working rules.

Existing course terms that help you make the distinction

These terms still apply whether the field is reusable reference information or a one-event transaction record.

Maintain stable reference information once, and record each order or event as its own transaction

If a product has an approved identity and construction, people should not type a new version of that identity into every order from memory. If a supplier has an approved legal name and payment setup, every buyer should not maintain a personal spelling of it. Reusable information needs an accountable owner and controlled source.

A transaction is different. Its quantity, required date, ordered colour mix, receipt, inspection result, shipment milestone and invoice belong to that specific event. They may copy approved reference fields into the transaction for context, but the transaction must retain its own history. When reference information changes later, old transactions should not silently rewrite themselves.

The line between reusable reference information and transaction information depends on what the field describes

Cedar & Co. reuses controlled product records while each replenishment and stock movement stays separate

Cedar & Co. is a domestic Make to Stock business with 12 shops. Its team plans from a standing forecast. Omar does not want each shop or buyer to rebuild a product description every time stock is replenished. The approved style identity, size range and current specification are reusable reference information. They need one controlled owner and source.

But a replenishment is not reusable reference data. Each replenishment has its own quantity, requested timing and status. A stock transfer from one shop to another is another event. A receipt into stock is another event. A sale is another event. Those records may point to the same product, but they must remain separate transactions so Cedar & Co. can tell what actually happened, where and when.

The same principle works in a factory, buying office, textile mill or retailer. Keep the identity of the thing controlled; keep the history of each event separate.

Two approved orders show why a past transaction value cannot become a permanent product value

Use two fixed academy transactions as a comparison, not as Cedar & Co. orders. Order A contains 15,000 T-shirts at USD 3.20 per piece. Order B jeans contains 3,000 jeans at USD 9.80 per piece.

Both transactions are valid, yet their quantities, unit prices and total values are different. That is exactly why quantity and order value should not be stored as permanent product attributes. A T-shirt style can have a stable identity while one order contains 15,000 pieces and a later order contains another approved quantity. The product record tells you what the item is. The transaction tells you what happened commercially this time.

Classify a field by asking four practical questions

1. Will people normally reuse this value across many orders or events? If yes, it may belong in controlled reference information.
2. Who can approve or revise it? Reusable information still needs a data owner and approved source.
3. Does the field describe the thing itself or one event involving the thing? Product identity describes the thing; order quantity describes one event.
4. If the reusable value changes later, must old transactions preserve what applied at their time? Usually yes. History should remain understandable.

Then write the answer in the ownership worksheet. Mark reusable fields clearly, identify their owner and source, and mark transaction fields as event-specific. At the hand-off to a new order, verify that only approved reusable values are carried forward and all event-specific values are created or reconfirmed.

The common trap is treating “master” as “never changes” or treating “last order” as the new master

Reference information can change. A product specification may receive an approved revision. A supplier address may change. A customer setup may be corrected. The control is not that the field is frozen forever; the control is that an accountable owner changes it deliberately and the new version becomes the approved source for future use.

The opposite mistake is more dangerous: copying the previous order and allowing its quantity, date, price or status to become the starting truth for a new one. That saves seconds during entry but can create hours of investigation later. Reuse the approved reference fields. Reconfirm the transaction fields.

• Master data is stable, reusable reference information; it is controlled, not necessarily permanent forever.
• Transaction data is created by a specific order, movement, approval, receipt, inspection, shipment, invoice or sale.
• Product, customer and supplier identities are common examples of reusable reference information.
• Quantity, required date and event status normally belong to a specific transaction.
• A later revision to reference information should not silently rewrite the historical meaning of completed transactions.
• Copying a previous order is not evidence that its transaction fields are valid for the next order.
• Both reusable and transaction information still need clear owners and approved sources.

Cedar & Co. is opening a new replenishment and someone proposes copying the complete previous row

Omar's team at Cedar & Co. needs a new replenishment for an existing style. The current approved product record already contains the style identity and specification. A team member opens the last replenishment row and proposes copying the whole row because it is faster. That row also contains the previous replenishment's quantity, requested date and commercial instructions.

Which information may be carried forward, and which information must be created or reconfirmed before the new replenishment is released? Decide before opening the answer.

This decision is not about banning copy-and-paste. It is about knowing what is being copied. A controlled template can save time, but transaction fields must never survive into a new event simply because nobody noticed them.

Use the ownership worksheet to mark which fields are reusable and which belong to each event

Open the T17-C01 Data ownership and data quality workbook. For each field, write its owner, approved source and whether it is reusable reference information or transaction-specific information. For reusable fields, record how revisions are approved. For transaction fields, record which event creates the value and which downstream users need it.

Before creating a new order or replenishment, review the list. Carry forward only current approved reference fields. Clear or reconfirm every transaction field.

[Download the Data ownership and data quality workbook](../../templates/T17-C01-data-ownership-data-quality.xlsx)

Download the Data ownership worksheet (Excel)

Lesson 1.4: Checking data at each hand-off before an error reaches the next department

Next you will learn how to check completeness, validity, consistency and timing before information is handed to another department. Back to the course map