Master data is the information that rarely changes and that everything else refers to: customers, suppliers, items, staff, accounts. An order refers to a customer and to items. An invoice refers to the same customer. If the master data is wrong, nothing built on top of it is right.
The question rarely comes up because of the master data itself. It comes up when a report does not add up because “Müller GmbH” and “Mueller GmbH” are two customers. Or when an interface to the shop is planned and nobody can say which item number counts. Or when an invoice goes to an address the customer left long ago.
What counts as master data
| Master data | Examples | Where it usually lives today |
|---|---|---|
| Customers | name, addresses, contacts, payment terms | ERP, accounts, sales list, shop |
| Items | number, description, unit, prices, supplier | inventory system, shop, price list in Office |
| Suppliers | address, terms, delivery conditions | purchasing, accounts |
| Staff | name, role, qualifications | HR, time recording, login to every program |
The right-hand column is the problem: almost every record exists in more than one place. A typical picture: the customer was created in the ERP when the first order came in. Accounts created it a second time because the accounting program keeps its own debtors. Sales keeps its contacts in an Excel list because the ERP is too cumbersome. Three places, three states. When the customer changes address, it is changed wherever the call lands - not in the other two.
What a leading system is
The solution is not to abolish all the programs. It is to decide, for each kind of master data, which system leads. The leading system is the place where a record is created and changed. All other systems get the data from there - through an interface or, failing that, a fixed rule about who reconciles what and when.
For items, the inventory system usually leads: it knows numbers, stock and purchase prices. The shop gets its items from there, not the other way round. For customers the ERP often leads, and accounts takes its debtors from it. For staff, the HR system or the central login leads.
What matters is not which system leads, but that there is one and everyone knows it.
Duplicates and how they arise
A duplicate is the same customer or item twice in the same system. It arises when someone cannot find a record and creates a new one: they searched for “Müller”, but it was stored as “Mueller”. Or the shop creates a new customer with every order because the email address is spelt differently.
How to tell you have duplicates:
- A customer gets two reminders for one invoice, or none.
- The revenue list shows the same customer twice, each with part of the revenue.
- An item sits in the warehouse under two numbers, and the stock is wrong in both.
- Before every mailshot someone has to clean up the list by hand.
Duplicates can be merged, but that is manual work, and someone has to decide which record wins. Better not to let them arise: with a search that finds similar spellings and a check when a record is created.
Number ranges
Anyone connecting programs needs a number that is the same in all of them. The customer number from the ERP should also be the debtor number in the accounts - or there is a fixed mapping. The inventory system’s item number should stay the item number in the shop, even if the shop keeps its own internally. Agree debtor and creditor numbers with your tax adviser before reassigning them: accounts usually has rules there.
Who is responsible for upkeep
Master data does not maintain itself. In most businesses one person or a small team may create and change customers and items; everyone else only uses them. That sounds bureaucratic, but it saves the duplicates. What matters is that creating a record is quick - otherwise sales will put the customer back in its own list. And changes need a fixed route: whoever learns of a new address passes it to the people who maintain it instead of changing only their own program.
Why this comes before any integration
Anyone connecting a shop, an accounting program or an app to the ERP runs into master data first. An interface can only hand over data that is unambiguous: which customer is meant, which item? The same goes for reports across several systems. That is why an integration often begins with a clean-up. It is not lost time but the precondition for double data entry really disappearing.
Where the inventory system leads and where it falls short
For items, stock and suppliers, the inventory system is usually the right leading system. For other things it often lacks the room: contacts and their responsibilities, equipment at the customer’s site, contracts, staff certificates. That is where the Excel list appears. Instead of tolerating it, an addition can hold this master data and reconcile it with the inventory system, through an interface where possible. For additions like these we use ElbDesk, the foundation we build on. If you have an ERP, it stays - accounts and warehouse stay out of it.
Questions before you decide
- Which system leads for customers, items and suppliers today - or does none?
- In how many places is a change of address entered?
- Who may create master data, and how quickly does it happen?
- Are customer and item numbers the same in every program?
- Which master data has no system at all so far, only a list?
We settle these questions at the start of every integration, because without the answers no interface runs cleanly.
