Two people pull a customer count from two different systems and get two different numbers. Nobody’s lying, both reports are technically accurate, and yet the meeting stalls for ten minutes arguing about which figure to trust. Multiply that across customers, suppliers and products, and you’ve got the exact reason ERP rollouts stumble even when the software itself is fine.
TL;DR
- Master data is the core records your business runs on: customers, suppliers, products, locations. Everything else in your ERP references it.
- Messy master data doesn’t just look untidy, it breaks workflows, skews reports and creates real compliance exposure.
- “Single source of truth” means one accurate version of each record that every part of the system reads from, not five slightly different copies.
- Cleaning master data properly takes real time. Rushing it is the single most common reason rollouts feel broken in the first few months.
- Blue Lotus 360’s implementation process treats master data cleanup as its own stage, not something squeezed in before go-live.
What master data actually is
Master data is the small set of core records that everything else in your business points back to: your customers, your suppliers, your product list, your locations. Transactional data, an invoice, a delivery, a purchase order, is created constantly and changes fast. Master data is meant to stay stable underneath it, the reference points everything else relies on being correct.
The problem is that master data rarely stays clean on its own. It accumulates duplicates, drifts out of date, and picks up inconsistencies as different people enter it slightly differently over the years. “ABC Ltd,” “A.B.C. Limited” and “ABC (UK) Ltd” might all be the same customer sitting in your system as three unrelated records, each with its own order history nobody’s connected.
Where it usually goes wrong
Master data problems tend to show up in the same handful of places, whichever business you’re in:
| Area | What breaks | What it costs you |
| Customers | Duplicate profiles, mismatched contact details | Missed orders, confusing service history, repeat marketing to the same person |
| Products | Inconsistent codes, mismatched units of measure | Stock counts that don’t match reality, pricing errors customers notice fast |
| Suppliers | Same supplier registered under different names | Duplicate payments, awkward audits, weaker negotiating position |
| Locations | Inconsistent site or warehouse codes | Deliveries and stock transfers going to the wrong place |
None of these are dramatic on their own. A duplicate supplier record doesn’t sink a business. But they compound. A finance team that can’t trust the numbers stops using the reports and goes back to their own spreadsheet. An operations team that’s been burned by a wrong stock figure starts double-checking everything manually. That’s how a perfectly good ERP system ends up running at half its intended value within a year, not because anyone decided to abandon it, but because trust in the data quietly eroded.
What “single source of truth” actually means
It’s one of those phrases that gets used so often it stops meaning anything specific. In practice, it means exactly one thing: for any given customer, supplier or product, there’s one accurate record, and every part of your system reads from that same record rather than keeping its own separate copy.
Larger organisations sometimes call this a “golden record,” built by merging every version of a record across systems and deciding, field by field, which value is actually correct. For most SMEs that’s overkill as a formal process, but the underlying discipline is exactly the same: pick which system owns which piece of information, and stop letting duplicates and half-updated copies drift apart.
Getting your data ready before it moves anywhere
Start by finding out how bad it actually is. Before assuming your data’s fine, actually look. Export your customer list and sort it alphabetically. You’ll usually spot the duplicates within the first few minutes, not because you were looking for them specifically, but because they’re genuinely that common.
Decide what “correct” looks like before you clean anything. Should addresses follow a specific format? Should customer names always match what’s on the VAT invoice? Agreeing this upfront means you’re cleaning toward a consistent standard, not just tidying records individually and creating new inconsistencies in the process.
Fix the data, don’t just hide it. Archiving old records is fine. Deleting the parts of a record that are wrong and leaving the rest untouched isn’t a fix, it’s a smaller version of the same problem.
Test with a small batch before trusting the whole thing. Clean a hundred customer records properly, check they behave correctly in a test environment, then scale up. Finding a mapping problem in a hundred records is a quick fix. Finding the same problem after ten thousand records have already moved is a much longer one.
Someone needs to actually own this
Master data problems tend to spread when nobody’s clearly responsible for a given type of record. Sales adds a customer with slightly different details than finance already has on file. Nobody notices until a report doesn’t add up months later.
You don’t need a formal governance committee for this at SME scale. You just need clarity: who decides what a “correct” customer record looks like, who has the final say when two versions disagree, and who’s actually checking new records as they’re added rather than assuming everyone’s following the same convention. Even naming one person per data type as the point of contact solves most of the drift before it starts.
Where Blue Lotus 360 fits in
Blue Lotus 360’s implementation process treats master data as its own stage, not a rushed afternoon squeezed in before go-live. The team works through your customer, supplier and product records with you, flags duplicates and inconsistencies early, and helps set the standards your data should follow going forward, not just for the migration itself.
That matters because clean data at go-live only stays clean if the structure supporting it does too. If you’re planning a move onto a new ERP system and want to get master data right from day one rather than firefighting it six months in, a demo is a good place to see how that process actually works.
FAQ Section
What’s the difference between master data and transactional data?
Master data is the stable core records your business references constantly: customers, suppliers, products, locations. Transactional data is what happens against those records, orders, invoices, deliveries, and it changes constantly by design.
How long does master data cleansing usually take?
It depends heavily on how many years of accumulated duplicates and inconsistencies you’re dealing with, but it’s rarely a quick task. Businesses that treat it as a proper stage of implementation, rather than something to rush through, tend to have far fewer problems in the months after go-live.
Do small businesses really need formal master data management?
Not in the enterprise sense of dedicated governance committees and matching software. But the underlying discipline, one accurate record per customer, clear ownership, consistent standards, matters just as much at SME scale. It’s just simpler to put in place.
What’s a “golden record”?
It’s the single, agreed-correct version of a record once duplicates and conflicting copies have been resolved. Every system then reads from that version instead of maintaining its own separate copy that can quietly drift out of sync.
Can master data be cleaned after go-live instead of before?
Technically yes, but it’s considerably harder. Once duplicate or inconsistent records are live in a working system, with transactions and history attached to them, untangling them takes far more effort than sorting the same issues out beforehand.
