Can we hand master data cleanup entirely to the system vendor?

The technical part, yes; the judgment part, no. A vendor can help export data, use rules to flag likely duplicates, convert formats in bulk, and write import programs. But "are these two customer records the same company," "should we keep this old part number," and "which is this supplier's official name" can only be decided by internal staff who know the business. If you hand the judgment to the vendor too, all they can do is merge by literal rules, which may well merge records that should stay separate or miss ones that should be merged. A more sensible split is for the vendor to supply tools and lists of suspected duplicates, while a designated internal owner confirms them batch by batch and writes down the principles behind each decision, so the same standard applies to new records later.

Our old part numbers are already printed on packaging and catalogs. Will changing the codes cause confusion?

Yes, so you do not have to change all of them. A common approach is for the new system to use the new coding rules while keeping an "old number" field, so users can still find the same record by its old number. Numbers already in circulation outside the company, such as the model numbers customers use when ordering, can continue to serve as external item numbers, while internal part numbers are managed under the new rules, with the two mapped to each other in the system. What genuinely needs retiring is duplicate and incorrect numbers, not every old number. During the transition, prepare a cross-reference table so sales, the warehouse, and accounting can all look up how old and new numbers relate, and set a date when the old numbers stop being used.

After cleanup, how do we keep master data from getting messy again?

Policy and the system have to guard it together. On the policy side, adding and changing master data needs a clear owner and a request process, rather than whoever needs a record creating one; coding and naming rules should be written down so new staff can look them up. On the system side, you can set required fields, format checks, and automatic matching against similar names or the same business registration number when a new record is added, and keep a change history showing who changed what and when. Add periodic checks on top, such as pulling a list of suspected duplicates and a list of long-unused records every quarter, and problems get handled while they are still small instead of piling up until they all surface at the next system rollout.

Master Data Cleanup Before a System Rollout

“This customer has three records in the system. Which one do we invoice?” “The warehouse says this part number has no stock, but it’s right there on the shelf, just labeled with a different number.” Situations like these are very common in companies that have used systems for years, and the root cause is almost always the same: master data that was never cleaned up.

Master data is the most fundamental, most frequently referenced data in a system: customers, products, part numbers, suppliers, the chart of accounts. Every order, every purchase receipt, and every report is built on top of it. When master data is messy, every number downstream goes wrong with it, and the errors are hard to spot.

Master data cleanup usually gets serious attention only when a new system is being adopted, and it is often the main reason rollouts run late. What follows explains where master data problems come from, the typical forms of mess in each type of master data, how to set coding and naming rules, who should own maintenance, and the cleanup steps before a rollout, ending with a cleanup process you can divide among your team.

How master data gets messy

Master data does not become messy overnight; it accumulates bit by bit in daily work. Common causes include:

Anyone can add records. A salesperson gets a new customer and creates a record; when they cannot find an existing one, they simply create a new one, and nobody checks whether it already exists.

No naming rules. For the same company, one person writes the full name, another an abbreviation, another adds the branch name, and someone else uses English. The system cannot match them, so they become multiple records.

Each system maintains its own copy. The website ordering system, the inventory system, and the accounting software each keep a customer list with no synchronization between them, so the same customer looks different in every system.

Historical leftovers. Products are revised, suppliers merge, customers change their names, and the old records are never deactivated or flagged, so old and new coexist.

Fields used for other purposes. Pricing terms stuffed into the notes field, “do not use” or “old” appended to a name — the system cannot read this information, and only the person who created the record knows what it means.

None of these problems is serious on its own, but after a few years they add up to situations that distort management decisions, such as “the customer count on the report is far higher than the real number” or “sales of the same product are split across several line items.”

Common problems in four types of master data

Each type of master data gets messy in its own way, and the points to watch during cleanup differ.

Customer master data

The same company entered more than once, with names written differently.
No relationships set up between headquarters, branches, and stores, so it is unclear which account receivables belong to.
A contact person has left, but the record was never updated.
Individual and corporate customers mixed together, with fields used inconsistently.

The most reliable basis for matching customer records is the business registration number; for individual customers, a mobile number or email can help, but manual confirmation is still needed. If the company also runs a membership program or CRM, clarify how customer master data relates to member data first; for the design side, see A Guide to Membership and CRM System Development.

Product master data

The same product created as different items for different sales channels.
Variants (color, size, capacity) sometimes split into separate items and sometimes written into the name, with no consistent rule.
Discontinued products never deactivated, so they still show up in drop-down lists.
Sales units differ from stock units (cases versus pieces), with no record of the conversion.

Part number master data

Part numbers usually refer to the internal codes used to manage raw materials, components, and work in progress, and the problems are often worse than with products:

The same component given different part numbers because it comes from different suppliers.
Part numbers follow no rule, so you cannot tell what something is from its number.
No record of the relationships between substitute parts or between old and new versions.
Unit conversion errors that make stock quantities disagree with reality.

Part numbers are directly tied to inventory figures, so cleanup should go together with a physical stock count; for the process, see Inventory Management System Development.

Supplier master data

The same supplier entered separately by different purchasing staff.
Payment terms and bank account details kept in notes or personal files.
Old and new records coexisting after a supplier renamed or merged.
Suppliers you no longer deal with never deactivated.

Supplier master data involves payments, so the accuracy of bank account information and the permission to change it need particularly tight control, to prevent anyone from impersonating a supplier and changing the remittance details.

How to set coding and naming rules

Before cleaning master data, set the standard for what it should look like when you are done. Start cleaning without a standard and you only turn one kind of mess into another.

Principles for coding rules:

Codes are unique and never reused. Do not assign a retired number to a new record, or historical records will point to the wrong thing.
Do not pack too much meaning into a code. Encoding category, year, and supplier into a part number looks easy to search, but as soon as the categories change, the whole coding scheme has to change. The common approach is to keep codes simple and stable and put category information in separate fields.
Fixed length and format. A fixed number of characters and a fixed character type make checking and sorting easy for the system.
Avoid easily confused characters. For example, the letter O and the digit 0, or the letter I and the digit 1.

Principles for naming rules:

For customers and suppliers, use the officially registered name as the master record name, with a separate field for the short name.
Product names follow a fixed structure, such as “brand + product name + variant,” and variants are written the same way every time.
Use full-width and half-width characters, spaces, and brackets consistently.
Do not put status words such as “old” or “do not use” in names; status should be expressed with a system field.

Once the rules are set, write them up in a short document with examples of right and wrong, so everyone who creates records can refer to it.

Who maintains master data

The root cause of messy master data is often that “everyone can change it, so nobody is responsible.”

A suggested division of responsibility:

Master data	Suggested owner	Main checks
Customers	Sales or customer-service management	Business registration number, official name, receivables ownership
Products	Product or marketing	Variant structure, listed/delisted status, sales unit
Part numbers	Production control, purchasing, or warehouse	Unit conversion, substitute parts, version relationships
Suppliers	Purchasing together with finance	Official name, payment terms, bank account

Assign a “data owner” for each type of master data, responsible for reviewing additions and changes. Other staff can submit requests, but the owner makes the final call on whether an identical record already exists and whether the format follows the rules.

This does not mean making the process cumbersome. The point is that someone has looked at every change to master data, rather than everyone freely adding records in the system. For data that changes often, such as new customer records, sales can create a record in a “provisional” status, and the owner confirms it periodically and converts it into an official record.

Cleanup steps before a system rollout

Master data cleanup should start early in the rollout, not in the last few weeks before go-live. Here is a process you can divide among your team:

Inventory the data sources. List which systems and files currently hold each type of master data, who maintains them, and how often they are updated.
Set the standard. Using the principles above, settle the coding rules, naming rules, and required fields, and get management sign-off.
Export and combine. Export data from every source into the same format, adding a “source” column so you can trace it later.
Flag suspected duplicates. Use criteria such as business registration number, name similarity, and phone number to produce a list of suspected duplicates. A system or the vendor can help with this step.
Make the judgment calls. The data owner confirms batch by batch which records to merge and which are different entities, and writes down the principles to stay consistent.
Decide what to keep and what to deactivate. Customers with no transactions for a long time, discontinued products, and suppliers you no longer deal with are marked inactive rather than deleted, keeping the history intact.
Build an old-to-new cross-reference table. Record which new record each old record maps to. This table is the basis for later converting transaction history and answering customer queries.
Fill in and correct fields. Add missing required fields and fix formats according to the new rules.
Trial import and verify. Import into a test environment first, compare samples, and run real transaction flows to confirm master data is referenced correctly.
Freeze and convert. Set a cutoff after which no new master data is added to the old system, complete a final synchronization, and then do the official import.

Master data is only the first step of data conversion; moving transaction history, opening inventory, and open receivables and payables involves many more details, which Data Migration When Replacing Systems covers next.

Common mistakes

Cleaning while rolling out. System configuration and master data cleanup happen at the same time, testing runs entirely on dirty data, and the problems only surface at go-live.
Deleting duplicates outright. Deleted records may still be linked to historical orders or receivables; merge the links first, then deactivate.
Cleaning only once. With no maintenance policy after go-live, things are back where they started within a few months.
Handing it all to part-time help or an outside contractor. Data cleanup needs business judgment, and people unfamiliar with the business easily merge the wrong records.
Rules that are too complicated. If the coding rules are too complex for the people creating records to remember, eventually nobody follows them.

Closing thoughts

Master data cleanup is manual labor, and it is also management work. Unlike a new system, its results are not visible, yet it decides whether the reports can be trusted after go-live, whether inventory reconciles, and whether receivables can be collected cleanly. The earlier you start and the earlier you put a maintenance policy in place, the less resistance a new system rollout will meet.

If you are preparing to adopt an ERP or an inventory system, or the master data in your current system is already messy enough to disrupt daily work, talk with NETVANA about the state of your data. We can help inventory data sources, produce lists of suspected duplicates, plan the import and old-to-new mapping, and add checks in the system that prevent duplicate records. Software work is quoted after a consultation, based on data volume and system scope; what each service covers is listed in the software services overview.

Further reading: Once master data is in order, see Data Migration When Replacing Systems for how to move transaction and inventory data. If you are still deciding whether to adopt a full suite, start with ERP Selection for Small and Medium Businesses. For managing part numbers and inventory, read Inventory Management System Development. And for integrating customer master data with member data, see A Guide to Membership and CRM System Development.