Master data during mergers and acquisitions: the integration problem nobody budgets for

I have sat through a dozen post-acquisition integration kickoffs. The pattern is remarkably consistent. Finance has a plan. Legal has a plan. HR has a plan. Nobody has a plan for master data.

Then week three arrives, someone tries to produce a consolidated customer list, and the room goes quiet. Company A has 4,200 customers. Company B has 3,100. Combined? Should be around 7,300. The actual overlap, once you account for the 800+ customers that both companies serve under different codes and slightly different names, is closer to 5,900. But nobody knows that yet, because nobody looked.

Due diligence has a blind spot

Standard M&A due diligence covers financials, legal liabilities, intellectual property, key personnel, and customer contracts. What it rarely covers is the structural quality of the data underneath those contracts. How many unique customers does the target actually have? How clean is their product catalog? Do their cost center hierarchies map to yours?

A 2023 Deloitte survey of 150 mid-market M&A deals found that 67% of acquirers reported "unexpected data integration complexity" as a top-three post-close challenge. That number has been climbing since 2019, because companies run more systems now than they did five years ago, and each system carries its own version of the truth.

The financial model says the acquisition adds 3,100 customers to your base. But if 800 of those are customers you already have, your actual growth is 2,300. That changes the price-per-customer math. It changes the revenue synergy assumptions. And you only find out after you've closed.

The four master data collisions

Every acquisition surfaces the same four conflicts. The specifics vary, the pattern does not.

Why spreadsheet-based integration fails

The default approach to post-merger master data integration is a spreadsheet. Someone exports both customer lists into Excel, runs VLOOKUP and fuzzy matching, color-codes duplicates, and emails the file around for review. I have seen this exact process at companies doing € 50M+ acquisitions.

It falls apart fast. The spreadsheet has no audit trail. Version 7 of the mapping file lives on three different laptops with three different sets of corrections. Someone renames a column. Someone else filters out records they thought were irrelevant. The canonical version is whichever one the IT lead happens to open when they start the actual migration.

Six months post-close, finance discovers that 40 supplier records were mapped incorrectly because the spreadsheet used in the migration had an outdated vendor code column. The payment terms are wrong. Invoices are going to addresses that no longer exist. Nobody can trace who approved the mapping because there was no approval process. There was just a spreadsheet.

What a governed integration looks like

The alternative is to treat master data integration the same way you treat financial integration: with a system, a process, and accountability.

Before close: Run a master data assessment as part of due diligence. Export entity counts from both systems. How many unique customers? How many products? What overlap can you estimate with a quick name-matching pass? This gives you an honest integration budget and timeline, not a guess.

Day 1 readiness: You need a consolidated view of critical entities before the first joint sales report. That means mapping the top 200 customers (the ones that generate 80% of revenue) into a single governed list. Not all 7,000. Just enough to report accurately from day one.

Ongoing merge: The remaining entities get reconciled over months, not weeks. Each mapping goes through an approval workflow. A data steward from each side reviews whether "Visser BV" and "Visser B.V." are really the same entity. The approved mapping is recorded in the audit trail. When the CFO asks in month nine why a supplier was mapped to a particular cost center, you have a name, a date, and a reason.

The hidden cost: twelve months of parallel reporting

Companies that skip master data governance during integration end up running parallel reporting for a year or more. Two sets of books, two versions of the customer list, two product catalogs. Every consolidated report requires a manual reconciliation step.

I spoke with an IT director at a manufacturing company last year who described exactly this situation. They acquired a competitor in early 2024. As of late 2025, they were still maintaining two separate ERP instances because the master data had never been properly reconciled. The cost of running two systems, two support contracts, two sets of integrations, was eating into the synergies the deal was supposed to deliver.

McKinsey estimates that 10 to 30% of expected M&A synergies evaporate during integration. Master data is rarely the sole cause, but it is almost always a contributing factor, because every other integration workstream depends on having consistent reference data to work with.

Start with these three questions

If you are in the middle of an acquisition, or planning one, ask your integration team these questions before anything else:

If your team cannot answer the first question within a day, your master data is not integration-ready. That is not a criticism. Most companies are in the same position. But the companies that acknowledge it early spend less time and money fixing it later.

Common questions