There is a familiar arc to a disappointing ERP project. The software is chosen carefully, the implementation goes broadly to plan, and the system goes live to some relief and a little celebration. Then, over the following months, a quieter feeling sets in. The stock figures do not quite match the shelves. A report shows the same customer three times. An order goes out at last year's price. People start double-checking the system against their own spreadsheets, and once they are back in the spreadsheets, they tend to stay there. The conclusion everyone reaches is that the ERP is not very good. The conclusion is almost always wrong. The software is usually fine. What was never fixed is the data poured into it.
This is the single most underestimated truth about ERP. A modern ERP is an extremely capable machine for acting on your data at scale, and that is exactly why bad data is so dangerous inside it. Point it at clean, well-structured records and it will run your operation beautifully. Point it at duplicates, gaps, and stale values and it will act on those too, faster and more confidently than any human ever did, spreading the errors into stock, into pricing, into accounts, and into every report leadership then tries to make decisions from.
What master data actually is
It helps to be precise about what we mean. Master data is the core reference information the ERP reasons about: your customers, your suppliers, your items or products, the bills of materials that define how those items are built, your price lists, your tax rules, and the accounts they all map to. It is different from transactional data, which is the flow of events, a particular sales order or a specific invoice. Master data is the relatively stable backbone; transactions are the traffic that runs across it. Every transaction inherits the quality of the master records it touches. An invoice is only as correct as the customer, item, price, and tax record behind it.
That is why master data problems are so corrosive. They are not one-off mistakes. A single duplicated customer, a wrong unit of measure on an item, a reorder level set to the wrong number, quietly contaminates every future transaction that uses it, and in an ERP there are a great many of those.
Garbage in, at scale
The old phrase garbage in, garbage out was written for exactly this. What an ERP adds is scale and speed. In a manual world, a person entering an order might notice that a price looks wrong or that a customer already exists, and pause. The ERP does not pause. It takes the reorder level you gave it and raises purchase orders against it, correct or not. It takes the item cost in the record and values your entire inventory on it. It takes the duplicated customer and splits that customer's history across two records, so neither one tells the truth. Each of these is a small data flaw, and each is now automated, repeated, and buried inside a system people were told to trust.
The result is the loss of the one thing an ERP is supposed to deliver: a single, trustworthy version of the numbers. And once trust in the numbers goes, adoption goes with it, because people will not run a business on figures they have to double-check.
Why master data degrades
Master data rarely starts clean, and it does not stay clean on its own. The first hit usually comes at migration. Years of accumulated mess in the old systems and spreadsheets, the duplicates, the abbreviations, the half-finished records, gets loaded into the shiny new ERP under time pressure, because cleaning it felt like a task that could wait. It cannot. Whatever goes in at go-live becomes the foundation everything else is built on.
After that, it degrades because nobody owns it. If anyone can create a new customer or item however they like, with no standard for naming or required fields, then duplicates and inconsistencies are not a risk, they are a certainty. One person types Acme Ltd, another types ACME Limited, a third creates a new record because they could not find the first two, and now there are three. Multiply that across thousands of records and several years, and the master data slowly rots while everyone assumes the system is keeping itself tidy.
Getting master data right
The fix is not glamorous, but it is well understood. It starts before migration, not after. You profile the existing data to see how bad it really is, remove the duplicates, fill the critical gaps, and standardise the formats and naming so that a customer, an item, a supplier each follow one agreed pattern. Only then do you migrate the cleaned set into the new system. A new ERP is the single best opportunity most businesses ever get to fix their data, precisely because everything is being touched anyway, and cleaning first is how you avoid paying to carry the old mess into a more expensive home.
Then you keep it clean, which is mostly about ownership and rules. Decide who is allowed to create and edit each type of record, set the standards, and let the system enforce them: mandatory fields so records cannot be half-created, naming series so items and customers are coded consistently, validations that catch the obvious errors at the point of entry. ERPNext and similar platforms give you these controls precisely because master data discipline is the difference between an ERP that stays trustworthy and one that quietly decays. Master data is not a cleanup you do once. It is a standard you hold.
A worked example
A manufacturer came to us frustrated with an ERP they had gone live on a year earlier. Stock was perpetually wrong, purchasing was ordering things they already had, and the finance team had rebuilt their own parallel spreadsheets because they did not trust the system's numbers. They were ready to conclude the software was a bad fit and start again. We asked to look at the data before they replaced anything.
The item master was the problem. The same physical component often existed several times under slightly different codes, units of measure were inconsistent so quantities did not add up, and many items had no reorder level or a wrong one, which is why purchasing kept misfiring. None of this was the ERP's doing; it was faithfully acting on the records it had been given at migration. We cleaned and de-duplicated the item master, standardised the units, set the reorder levels properly, and put ownership and validation rules in place so it would stay clean. Nothing about the software changed. Within a couple of months stock was reliable, purchasing stopped double-buying, and finance quietly retired their spreadsheets. The system they had been about to throw away had been correct all along. It had simply been fed the wrong data.
Clean data is the real ERP project
The lesson for anyone implementing or living with an ERP is to treat data as the heart of the project rather than an afterthought at the end of it. The software selection matters far less than most people think, and the data quality matters far more. Get the master data clean before you migrate, give it an owner and rules so it stays clean, and an ordinary ERP will serve you well. Skip that, and the best ERP in the world will still tell you lies at scale.
If your ERP is not trusted, or you are about to implement one and want to make sure it is fed properly, the data is almost always where to look first, and it is central to how we approach ERP and CRM implementation: getting the master data right so the system earns trust from day one. Book a discovery call and we will help you make the data worthy of the system.
Frequently asked questions
What is master data in an ERP?
Master data is the core set of records your ERP reasons about: customers, suppliers, items or products, bills of materials, price lists, tax rules, and the accounts they map to. Unlike transactions, which are events like a specific order or invoice, master data is the relatively stable reference information those transactions rely on. If a customer is duplicated, an item has the wrong unit of measure, or a price list is out of date, every transaction that touches that record inherits the error. Master data is the foundation the whole system stands on, which is why its quality determines whether the ERP is trusted or quietly abandoned.
Why do ERP implementations fail because of data?
Because an ERP does not improve the data you give it, it acts on that data faster and at greater scale. If the data migrated in is full of duplicates, gaps, and stale values, the system produces wrong stock figures, mis-priced orders, and reports nobody trusts, and it does so confidently. People notice the numbers are wrong, lose faith in the system, and drift back to their own spreadsheets, which recreates the very fragmentation the ERP was meant to remove. The software is usually working exactly as designed. It is the data underneath it that was never cleaned, and that is what makes the project feel like a failure.
Should we clean data before or after migrating to a new ERP?
Before, wherever possible. Migrating dirty data into a new system just moves the mess to a more expensive place and hardwires it into every future transaction. The right sequence is to profile the existing data, remove duplicates, fill gaps, standardise formats and naming, and agree the rules for each record type, and only then migrate the cleaned set. Cleaning after go-live is far harder because the bad records are already generating live transactions and reports. A new ERP is the best opportunity a business ever gets to fix its data, and cleaning first is how you take it.
Who should own master data quality?
A named person or small group with clear authority over how master records are created and maintained, supported by validation rules built into the system. The failure mode is letting anyone create a customer or item however they like, with no standards, which is how duplicates and inconsistencies accumulate. Good practice is to define who can create and edit each record type, set naming and formatting standards, and use the ERP's own validation, such as ERPNext naming series and mandatory fields, to enforce them. Master data is not a one-time cleanup, it is an ongoing responsibility, and it needs an owner just like any other critical function.