Ask a finance director why two reports showing the same metric disagree, and you will eventually arrive at the same place: the customer exists three times. Once as "Acme Industries LLC", once as "ACME Industries", once as "Acme Ind. (Dubai)". Each has its own transaction history, its own credit limit and its own address. Revenue by customer is therefore wrong, credit exposure is understated, and the account manager reviewing the relationship is seeing a third of it. This is the least glamorous problem in enterprise systems and one of the most expensive. Master data management — the discipline of defining, governing and maintaining the core entities that everything else references — gets funded reluctantly, usually after a reporting failure embarrassing enough to require an explanation. By 2012 the problem had become acute for a specific reason. Organizations had spent the previous decade acquiring companies, adding systems and building data warehouses on top of both. Every acquisition brought its own customer list, item codes and chart of accounts. Every new system created another place where a customer record could be created. The reporting layer was being asked to reconcile master data that nobody owned.
Where Master Data Actually Breaks
Four entities cause most of the damage, and each fails in a characteristic way. Customers. Duplicates are created because entry is fast and searching is slow. A sales user typing a new order finds it quicker to create a record than to work out whether the existing one with a slightly different spelling is the same company. Multiply by three years and several offices, and the customer list has a duplication rate that nobody has measured. Suppliers. Same mechanism, worse consequences. Duplicate vendor records enable duplicate payments, obscure total spend by supplier during negotiations, and — as fraud teams learned repeatedly — create cover for fraudulent vendors that look like legitimate ones. Items and materials. Different codes for the same physical item mean inventory appears in two places, purchasing buys what it already has, and stock levels are simultaneously too high and reported as too low. Chart of accounts and cost centres. Multiple entities with locally evolved structures make consolidation a mapping exercise performed in a spreadsheet by one person, every month. That spreadsheet is a single point of failure and it is usually undocumented. What these share is that the damage appears far from the cause. A duplicate created during order entry in March becomes a board-level reporting discrepancy in September, and by then the connection is invisible.
Why MDM Projects Fail
Most organizations attempt this at least once. A large proportion of those attempts produce a cleansed dataset that degrades back to its original state within two years. The failure modes are consistent. Cleansing without governance. A one-time de-duplication exercise removes the duplicates and changes nothing about the process that created them. The same creation patterns resume immediately. This is the single most common error and it is expensive because the cleansing itself is genuinely hard work. Buying a tool and calling it a programme. MDM software matches, merges and manages hierarchies competently. It cannot decide what a customer is, who is allowed to create one, or which system wins when two disagree. Those are organizational decisions, and no tool makes them. No named owner. Master data ownership sits awkwardly between IT, which runs the systems, and the business, which creates the records. When it is nobody's objective, it receives nobody's attention. Boiling the ocean. Programmes that attempt every entity across every system simultaneously run for years and deliver late. The ones that work start with a single entity where the pain is quantified. Treating data quality as a project. It is an operational function, like reconciliation. Projects end. The creation of bad master data does not.
Practical Guidance for Master Data Management
- Start with one entity and quantify the current damage. Duplicate rate, duplicate payments recovered last year, hours spent on manual consolidation. A number converts this from hygiene to a business case.
- Name an accountable data owner in the business, not in IT. Someone whose objectives include the quality of that entity, with authority over the process that creates it.
- Fix creation before fixing history. If the inbound process still generates duplicates, cleansing history is a recurring cost. Controls at the point of entry — search-before-create, mandatory identifiers, approval for new records — do more than any retrospective exercise.
- Define the entity in writing. What is a customer: a legal entity, a billing relationship, a group? Most disagreements about duplicates are actually unresolved definitional questions.
- Designate one system of record per entity and enforce it. Other systems subscribe. Bidirectional creation authority guarantees divergence regardless of tooling.
- Use external identifiers wherever they exist. Trade licence numbers, tax registration numbers, company registration numbers, standard product codes. Matching on names is a losing strategy in any market, and especially where transliteration varies.
- Measure quality continuously and report it. Duplicate rate, completeness of mandatory fields, records without an owner. A monthly number that someone is accountable for is what prevents regression.
- Build remediation into the operating rhythm. A standing allocation of effort to merges and corrections, not a project that closes.
The Regional Complication
Gulf organizations face a harder version of the matching problem than most. Entity names exist in Arabic and English with multiple valid transliterations of the same name. Group structures are frequently complex, with related entities across several free zones and jurisdictions that are legally distinct but commercially one relationship. Trading names diverge from licence names. Name-based matching performs poorly under these conditions, which makes identifier-based matching — trade licence, tax registration — considerably more important here than in markets where a single consistent legal name can be relied upon. Organizations that build their master data strategy around name similarity discover the limitation slowly and at scale.
Why This Matters More Now Than It Did
For two decades the consequence of poor master data was bad reporting, which organizations tolerated because someone in finance manually corrected it before it reached anyone important. That buffer is disappearing. Automated processes do not apply judgement to a duplicate. Analytics platforms aggregate whatever they are given. And AI systems asked to analyse customer profitability, recommend credit decisions or identify supplier concentration will read the master data as fact, produce a confident answer, and give no indication that the underlying entities are fragmented. The common framing — that AI requires clean data — understates the change. What has actually happened is that the human correction layer, which quietly absorbed master data failures for twenty years, is being removed. The errors were always there. They were simply being caught by someone who knew that Acme appeared three times. That makes master data management, the least interesting item on any IT roadmap, a prerequisite for most of the things currently at the top of it.
Common Questions
What is master data management?
The discipline of defining, governing and maintaining the core business entities — customers, suppliers, items, accounts — that every system and report references, so that the same real-world entity is represented consistently everywhere.
Why do duplicate records keep coming back after a cleansing project?
Because cleansing addresses history while the process that creates duplicates continues unchanged. Without controls at the point of creation and a named owner, the data returns to its previous state within a year or two.
Where should an MDM programme start?
With a single entity where the damage can be quantified — usually suppliers, because duplicate payments and spend visibility produce a hard number — rather than with every entity across every system at once.
Does MDM software solve the problem?
No. Tools match, merge and manage hierarchies well, but they cannot define what a customer is, decide who may create one, or determine which system is authoritative. Those decisions are organizational and must be made before the tool adds value.
Master Data Assessment — Outpace measures your actual duplication rate, finds where bad records are being created, and puts ownership and controls where they will hold.