ERP Master Data: The Often Underrated Foundation of Item Codes, Customers, and Suppliers

When a business decides to implement ERP, attention usually goes to features: which modules exist, which reports can be produced, and how easy the interface looks. Few people ask at the start, "What data will we put into it, and how clean is that data?" Yet this is where many ERP projects quietly wobble. A sophisticated system fed messy data will produce messy reports too, only more neatly displayed.

Master data is the core data used repeatedly by almost every business process: the list of items, customers, suppliers, employees, warehouses, and financial accounts. Every transaction, such as an order, invoice, or stock movement, refers to this master data. If master data is duplicated, inconsistent, or incomplete, errors spread through all the transactions and reports built on top of it.

This article covers why master data determines ERP success, how to structure item codes and customer and supplier data, practical naming rules, and how to keep data clean once the system is running. We use no invented figures about how large the losses from bad data are; what we offer are working patterns and a checklist you can apply to your own business data.

Summary

• Master data is the foundation of ERP: items, customers, suppliers, and other reference data used in every transaction
• One entity should have one record with one unique, unchanging code that carries no meaning that can expire
• Set written naming and format rules so data is consistent no matter who enters it
• Clean and merge old data before migrating; do not carry the mess into the new system
• Decide who owns each type of data and how changes are approved, so cleanliness lasts over the long term

What master data is and why it matters

Picture two kinds of data in a business. The first is transaction data: today's sales orders, last week's purchase invoices, this morning's stock movements. This data keeps growing and is rarely changed once recorded. The second is master data: the list of items you sell, the customers you serve, and the suppliers you buy from. This data is relatively stable but is used again and again by every transaction.

The relationship is like an address book and letters. A letter, meaning a transaction, can only be delivered correctly if the address in the address book, meaning the master data, is correct. If one customer is recorded three times under different names, their purchase history is fragmented, their invoices are scattered, and you cannot see how big that customer really is to your business. If one item has two codes, its stock is split and inventory reports mislead.

That is why master data quality determines the quality of almost everything ERP produces. Sales reports per customer, inventory value, margin analysis per product, and purchase planning all depend on accurate, consistent master data. Fixing it after thousands of transactions are recorded costs far more than structuring it properly from the start.

Types of master data to prepare

Every business has a different mix of master data, but some types are almost always present. Recognising all of them from the start helps you plan data preparation thoroughly instead of piecemeal.

• Items or products: code, name, category, unit, price, and attributes such as size or variant
• Customers: name, address, contact, payment terms, and grouping
• Suppliers: name, contact, purchase terms, and the items they usually supply
• Warehouses and storage locations: the list of places where stock sits and their structure
• Employees and positions: the basis for access rights and approvals
• Chart of financial accounts: the recording structure for financial reports
• Supporting reference data: units of measure, currencies, taxes, payment methods, and regions

Of all these, item data is usually the most complicated because of its many variations and its greatest influence on stock and finance. Customers and suppliers follow. Start with what most affects your daily operations, but plan everything from the beginning.

Building item codes that last

An item code is the item's identity in the system. A good code makes searching fast, prevents duplication, and lasts for years. A bad code causes confusion every day. A few principles help in designing it.

1. 01One item, one code: do not create a new code for the same item just because the supplier or warehouse is different
2. 02Unique, never reused: even after an item is discontinued, do not assign its code to another item
3. 03Stable codes: do not change a code once transactions exist, because history will break
4. 04Separate identity from attributes: store size, colour, or category in their own columns instead of forcing everything into the code
5. 05Consider codes that are easy to read and type, with consistent length

Meaningful codes or sequential codes

There are two common approaches. Meaningful codes embed information, for example a category prefix followed by a number. Such codes are easy for humans to recognise but risky: if an item's category changes, the code becomes misleading or must be replaced. Sequential codes are simply unique numbers with no meaning, safe from change but less informative to the human eye.

Many businesses choose a middle path: a sequential code as the main identity, plus structured attribute columns for category, brand, and variant, so searching and grouping are done through attributes rather than by reading the code. If you use barcodes, align them with the internal code so scanning in the warehouse and at the till matches the system record straight away.

Handling variants

Items with variations, such as a T-shirt in several sizes and colours, need special attention. Separate the parent item from its variants: one parent item with a name and description, then several variants each with its own code and stock. With this structure, reports can be viewed at product level and variant level, and stock per size is recorded precisely.

Clean customer and supplier data

Customers and suppliers are outside parties that interact with your business, and their data often leaks from many directions: the sales team records it in one place, finance in another, and the warehouse in a third. The result is duplication and inconsistency that are hard to untangle once they have piled up.

Start by establishing what counts as one party. Is a branch treated as a separate customer from its parent company, or as one customer with several addresses? This decision affects billing, reports, and payment terms. Also set the minimum data that must be filled in, such as the official name, address, contact, and payment terms, so records are not half finished.

To prevent duplication, make a habit of searching before creating. Before adding a new customer, staff must check whether a similar record already exists. A good system helps with a warning if the name, phone number, or business registration number resembles an existing record. Also consider an unambiguous unique identifier, such as a business registration number for corporate customers, as a distinguishing key.

Because customer and supplier data often contains personal information, treat it carefully. Limit who can view and change it, and comply with applicable personal data protection rules. Refer to the latest provisions from the competent authorities and do not rely on summaries that may be out of date.

Consistent naming rules and formats

Without rules, data entered by many people is bound to vary. One person writes "PT Maju Jaya", another "Maju Jaya, PT", a third "PT. MAJU JAYA". To a human, all three are clearly the same; to a system, they are three different records. Written naming rules prevent this.

Decide on things like the order in which company names are written, use of upper and lower case, permitted abbreviations, address format, phone number format, and standard units of measure. For items, set a uniform name pattern, for example item type followed by brand, size, then variant. A consistent pattern makes searching and sorting work well.

Use controlled choices where possible. Instead of letting the unit column be filled freely, provide a list of options such as piece, box, kilogram. A list of options removes spelling variations and makes reports easier. The same goes for categories, regions, and payment methods.

Document it in a short guide

Write the rules above in a short, easily searchable guide, complete with correct and incorrect examples. A guide of one or two pages that is actually read is more useful than a thick document that is forgotten. Give it to everyone who will add or change data, and update it when rules change.

Cleaning old data before migration

When a business moves from spreadsheets or an old system to ERP, the biggest temptation is to move everything as it is. Yet this is the best chance to clean up. Messy data in the old system will become messy data in the new one, only in a more expensive costume.

Start with an inventory: where is your master data stored? It is usually scattered across many spreadsheets, an old point of sale system, accounting software, and employees' personal notes. Gather it all and compare. Look for duplicates, incomplete data, inconsistent formats, and inactive records.

Then clean in stages. Merge duplicate records carefully, decide which record becomes the parent, and move over the relevant history. Fill in empty required data. Standardise formats according to the naming rules. Deactivate, do not delete, items and parties no longer used so their transaction history stays intact. And do not migrate what is truly unnecessary; a new system is the right moment to let go of old baggage.

Once cleaned, test the import with a small portion of the data first. Check the results in the new system, fix the mapping rules if there are problems, then carry out the full migration. We cover data migration in more detail in our article on preparing data migration to a new system.

Involve the people who know the data best

Cleaning should involve those who use the data every day: warehouse staff who know which items are actually the same, the sales team who understand which customers are no longer active, and the purchasing department who know the suppliers. Technical team help is important for tools and scripts, but decisions about the content of the data should come from those who understand it best.

Governance: who owns what data

Data that is clean at launch can get dirty again within months if no one is responsible. Data governance sounds heavy, but for small and medium businesses it can be framed simply: decide the owner of each type of data and how changes are approved.

A data owner is the person or department responsible for its correctness. Item data may be owned by the warehouse or purchasing department, customer data by the sales team, supplier data by purchasing, and the chart of accounts by finance. Owners do not have to type everything in, but they decide the rules and approve important changes.

Set access rights on a least privilege principle. Not everyone needs to be able to create or change master data. The more people who can add new items or customers, the greater the chance of duplication. Consider an approval flow for sensitive changes, such as changing a customer's payment terms or a supplier's bank account, because such changes also involve fraud risk. Record who changed what and when, so there is a traceable trail.

Schedule regular data cleanliness checks, for example quarterly. Look for new duplicate records, empty required data, and records that have not been used for a long time. A small routine check costs far less than a big cleanup once a year.

The effect of master data on reports and decisions

The benefits of tidy master data are felt immediately in reports. Sales reports per customer become trustworthy because each customer is recorded only once. Margin analysis per product becomes possible because each item has one record with clear cost and price. Stock planning and reordering become accurate because stock is not split across different codes.

Conversely, poor master data makes managers doubt the numbers on screen. When two reports show different figures for the same thing, or when people have to correct reports by hand before trusting them, ERP loses its main value. People go back to personal spreadsheets and data scatters again. Master data cleanliness is the guardian of trust in the system.

Common mistakes to avoid

Several mistakes occur often. Creating codes that are too clever, full of implied meaning that quickly expires, is one. Letting anyone add data without rules is another. Migrating dirty data on the grounds that it will be cleaned later almost always means it never gets cleaned. Ignoring variants so stock per size is not recorded, deleting old records instead of deactivating them, and not appointing data owners also happen often.

Another mistake is treating master data preparation as a purely technical task. It is business work that needs decisions about definitions: what is a customer, what is one item, how variants are grouped. These decisions must come from process owners, with the technical team in support.

Practical steps to prepare master data

1. 01Inventory every place where your item, customer, and supplier data is currently stored
2. 02Set definitions and rules: what counts as one item, one customer, one supplier
3. 03Design a unique, stable item code scheme and separate attributes from the code
4. 04Write a one- or two page naming and format guide, complete with examples
5. 05Clean, merge, and complete old data before migration, then test the import with a small sample
6. 06Appoint data owners, set access rights, and schedule regular cleanliness checks

Conclusion

A successful ERP is not simply one with complete features, but one whose data can be trusted. Master data is the foundation: if that foundation cracks, the building on top will keep having problems, however beautiful it looks. The time invested in structuring codes, rules, and data governance before launch pays back many times over through accurate reports and more confident decisions.

If your business is considering ERP or wants to tidy up data that has piled up, start with master data. It is an unglamorous step, but it often makes the difference between a project that runs smoothly and one that drags on.