In a wholesaler that's been running for fifteen years, the product master data is never clean. Nobody broke it on purpose — it's just that every sales rep added a new SKU whenever the old one wouldn't come up in the search box. After a decade the company has three times as many "products" as it actually buys.
Duplicates, variants of the same item under different codes, dead SKUs from five years ago, entries like "Test 01", "Little cable", "Temporary product", and units of measure nobody remembers ("pkg." — is that a carton or a shrink-wrap?). Everything lives in the same dictionary and poisons every downstream decision: stock levels, margin reports, the Allegro integration, the quote sent to the customer.
This piece is about how to clean up product master data in a 15–50-person trading or manufacturing company, without shutting down sales for a month and without overpaying for a full-blown MDM (Master Data Management) project.
Where the chaos comes from
Three most common sources, in this order.
First: every sales rep adds an SKU "for right now". A supplier ships a new product, a customer wants a quote today, so the rep sets up "KAB-M-2M-BIA" at 3:47 pm. That the same cable already exists in the database as "KABEL-2M-M-BIALY" — nobody had the will to check. The ERP doesn't enforce EAN uniqueness because the EAN field is optional, and the supplier name differs by one typo.
Second: ERP-to-ERP migrations. The company switches from Subiekt to Comarch Optima, the whole catalogue is imported "as is", with no cleanup. Two years later nobody knows which SKUs came from the migration and which from day-to-day work. On top of that there are test entries someone added during the migration to check "whether this can even be entered" — and they stayed.
Third: supplier changes. The company switches its cable supplier from "Elektrocentrum" to "HurtElektryk", and the new supplier uses different codes. Instead of updating the supplier code on the existing SKU — a second SKU is created. Three years later you have two parallel dictionaries for the same range.
12,800 SKUs, of which 5,400 are duplicates or dead
At one of our clients — a 22-person electrical wholesaler in south-eastern Poland, using Comarch Optima for 9 years — the board wanted to run a "real stocktake" after their first thorough accounting audit. Starting point: 12,807 active product records in the dictionary, while the warehouse (around 3,800 sqm) physically held an estimated 4,000–5,000 distinct items.
After three weeks of analysing the Optima export it turned out:
- 3,190 SKUs had zero stock movement in the last 24 months and zero on hand.
- 1,480 SKUs were duplicates (the same products under different codes — most often differing by a single space, case, or an old supplier code).
- 220 SKUs were working entries: "Test", "New product", "Cable — check", "TEMPORARY".
- 510 SKUs had an empty EAN, even though the physical products had barcodes printed on them.
- 340 SKUs had "pcs" as the unit of measure, when in reality they were sold by the metre or in bulk packs.
The real number of actively sold SKUs was 7,417. That's 42% fewer than the ERP showed. Consequences: the annual stocktake took 4 days because the count list had 12,800 lines. A sales rep typing "YDY 3×1.5 cable" got four different SKUs back and picked the one that happened to have stock (not always the "main" record), which made the top-selling-products report show artificial fragmentation.
The cleanup took 8 weeks. Approach: 2 weeks of audit and merge rules, 5 weeks of merging at 100–200 records per day (each merge signed off by the sales rep responsible for that product group), a final week of housekeeping. Cost: PLN 24k, including a GS1 integration for EAN validation. Payoff: the next stocktake took 1.5 days instead of 4, the search finally returned one record per query, and the top-100 selling products report showed — for the first time in years — what management always intuitively knew the company sold.
Nothing magic. Four people, one shared rule, eight weeks.
What to delete and what to leave alone
This is the most delicate question, because every sales rep will defend "their" SKUs like sovereign territory.
Delete without hesitation: test entries ("Test", "ABC product", "NEW"), records with all identification fields empty (no EAN, no supplier code, no image, no sales), and one-off records set up for a single order 6+ years ago and never used since.
Merge (don't delete): duplicates. The critical difference: deleting a record with sales history destroys your historical reports. Merging means one code becomes the "master", and the duplicates are marked inactive with their history redirected to the master. Comarch Optima and enova365 have dedicated functions for this. In Subiekt it's done with a SQL script — carefully, and only after restoring the database to a test environment.
Archive, don't delete: dead SKUs (no sales for 24+ months, but historical sales exist). Set them to "inactive", drop them from the sales reps' default views, but keep them in the database. Three years from now, at the tax audit, you'll thank yourself.
Don't touch: records you're not sure about. One bad decision to merge products that are actually different (a 10A and a 16A fuse that look similar in the name) will wreck your stock reports. The rule: if in doubt — leave it and come back in a second pass.
How to run the cleanup without paralysing sales
Four rules that work in every project.
Backup the database first, always. Before anyone touches a record, you take a full ERP backup and restore it to a test environment. The first week you work only on the copy — only once the merge rule is clear and verified do you move changes to production.
Batches of 100–200 records per day, not all at once. It's tempting to write a script that "cleans everything up over the weekend". In practice, such scripts always merge something they shouldn't. Manual work at 100–200 SKUs per day, signed off by the responsible sales rep, is slower but doesn't set fires.
Assign an owner per product group. In every wholesaler there's someone who knows cables best, someone who knows lighting, and someone who knows fittings. They sign off the merges — not IT, not a sales rep from the next region, not the board. Without this the rule "merge KABEL-2M-BIA with KAB-M-2M-BIALY" collapses in the first week, because it turns out one is white PVC and the other is white LSOH.
Log every decision. A simple Google Sheet: master code, merged codes, date, who signed off, reason. Six months in, somebody will ask "what happened to SKU X", and you need to have the answer in 30 seconds, not two days of digging in the ERP.
Keeping the master data clean afterwards
The cleanup is a one-off event. Keeping the master data clean — is a process. Three things, without which you'll be back in the same place in two years.
Assign one person responsible for creating new SKUs. Not "every sales rep in their own way" — one person in the company, with rules. It can be the CEO's assistant, it can be the warehouse manager, it can be the owner — as long as it's one person.
Block the ERP from creating a record without required fields. Comarch Optima, enova365 and Subiekt all let you enforce EAN, supplier code, unit of measure and category as mandatory. That's 10 minutes of ERP admin work and half the problem disappears at source.
Every quarter, generate a report of "new SKUs created in the last 90 days" and skim it. 15 minutes per quarter saves you weeks of cleanup three years from now.
If your product master data has ballooned and you don't know how many products you actually have — you don't need a half-million-złoty MDM project. Half an hour with someone who does this in Optima, enova and Subiekt regularly is usually enough to scope the work.
Cleaning up master data isn't an IT project — it's a management project. Without deciding who owns the data, no ERP will keep it tidy on its own.