Master data in mergers and acquisitions: why the master decides whether integration works

Master data in mergers and acquisitions is the customer, supplier and material master of the companies involved, which has to become a single base once the deal closes. It sounds like an operational detail. It is, in fact, one of the factors that most delays, inflates the cost of, or simply blocks the integration between the two companies.

I have seen entire due diligence efforts focused on contracts, tax liabilities and asset valuation, with the supplier and customer master only appearing on the agenda weeks after signing. By then the problem is already in place. Each company arrives with its own ERP, its own way of creating materials, its own way of vetting suppliers. Putting that together is not copying and pasting tables.

What master data is in a merger or acquisition

Master data is the entities that sustain the company's operation: customers, suppliers, materials, general ledger accounts, assets. In a merger or acquisition, each side arrives with its own version of those entities, often in different systems. One company uses SAP, the other uses TOTVS. One classifies materials by internal family, the other uses NCM (Mercosur Common Nomenclature, Brazil's tax classification code) as its main criterion. A supplier approved at the buyer may not even exist in the acquired company's master, or may exist with a mistyped CNPJ (Brazil's company registration number).

When the deal closes, someone has to decide which master survives, which record is correct when the two systems disagree, and how to turn two different bases into a single source of truth. That is master data in M&A. It's not a report for the board to sign. It's data engineering and governance work, on a tight deadline and with direct impact on operations the day after closing.

How master data integration works in practice

The first step, even before designing the target system, is diagnosing the two bases. How many duplicate suppliers exist between the two companies when you cross-match by CNPJ. How many materials are the same item with different descriptions. How many customers appear in both portfolios, sometimes with incompatible commercial terms.

Next comes defining the survival rules, what we call survivorship in MDM. When both systems have a supplier with the same CNPJ but different record data, which record wins? Generally the rule prioritizes the most recent data and the data validated against an official source, such as the Receita Federal (Brazil's federal tax authority) for the CNPJ and its registration status. But in purchasing, for example, it may make more sense to keep the commercial terms negotiated by the company that had the active contract, even if its record is older. That isn't solved with a generic rule. It's solved by sitting down with purchasing, finance and IT at the same table.

Then comes the actual migration. And here I repeat something I have lived through in SAP projects: migrating without cleansing means carrying the old system's problem into the new system. If a supplier has a registration status that doesn't match the Receita Federal, it goes into the new base as is. If the same bolt is created three different ways across the two companies, it arrives in the unified base as three items. After the initial load comes reconciliation: comparing what was migrated against what existed in the two source systems, finding the inconsistencies, fixing them, and only then releasing the new base for full operation of purchasing, sales and invoicing.

Who is responsible for this integration

In a merger or acquisition there is normally an integration office, set up to run the process in the first months after closing. Master data should be inside that office from day one, not as an IT item that shows up later.

The work involves at least four fronts. M&A leadership sets the deadline and priority, because every week of delay in master data integration delays purchasing synergies and financial consolidation. IT handles the architecture, deciding whether the final base runs on the buyer's ERP, the acquired company's, or on an MDM platform that feeds both until the single-system decision is made. Data governance, led by the data steward, defines the quality, survivorship and validation rules the migration will follow. The business areas, mainly purchasing, sales and tax, validate that the final master serves the real operation, because they are the ones who will feel the error day to day if the wrong supplier is activated or the right customer ends up blocked.

When one of those four fronts is left out, the integration costs more later.

Which tools support the process

For the volume and speed a merger demands, doing this work in spreadsheets is not an option. The market has MDM platforms built for this, with matching engines, deduplication and approval workflows. Among the most cited are SAP Master Data Governance, for those already operating in a SAP environment who want to keep native integration with the ERP, Informatica MDM, Stibo Systems, Reltio, Semarchy and Profisee, each with different strengths depending on data domain and volume. For data quality specifically, tools such as Ataccama and Informatica's own quality layer help measure the size of the problem before migration begins.

4MDG works exactly at this point, with an MDM platform that integrates via API, via MCP and with any system, including ERPs such as SAP, TOTVS and Oracle, to support data cleansing, deduplication and governance of the customer, supplier and material master. In a merger process, that means having a neutral environment to consolidate the two masters before deciding which final ERP will receive the definitive base.

No tool replaces the business decision about which survivorship rule to apply. Technology executes the rule; it doesn't decide.

How to learn to work on this kind of project

If you already work with master data, purchasing or IT, mergers and acquisitions are one of the richest situations for deepening your MDM knowledge, because they combine data modeling, quality, governance, negotiation between departments and a tight deadline.

The study path involves understanding the fundamentals of Master Data Management, matching and survivorship techniques, and reading real integration projects. Certifications such as DAMA's CDMP help structure your knowledge in a way the market recognizes, especially for those who want to move from master data analyst to a governance or project leadership role. As I discuss in the book Master Data Management: Fundamentos e Aplicações (book in Portuguese), published by Editora Brasport, technical mastery alone doesn't solve it; you also have to translate the impact of bad data for whoever decides the project budget.

Career opportunities in this kind of project

M&A projects pay well and hire fast precisely because the deadline is short and the risk of error is high. Master data professionals, data stewards, data architects and MDM consultants with experience in post-merger systems integration are in demand at that specific moment, because few professionals in the market have actually been through this kind of project.

Consultancies specialized in M&A and integration offices usually put together temporary teams for exactly this work, which opens room both for those already working internally at a company and for those providing services as independent consultants or through a master data specialist firm.

Main questions about master data in mergers and acquisitions

When should master data integration start in an M&A? Ideally the diagnosis of the two bases starts during due diligence, before closing, so that the cost and timeline of integration are factored into the valuation of the deal.

Who decides which master survives when the two companies' systems disagree? The survivorship rule is defined jointly by data governance and the business areas involved, never by IT alone, because the impact is operational and commercial.

Is it possible to keep both ERPs running after the merger? Yes, and it is common in the first months. An MDM platform independent of the ERPs serves exactly to keep the master data base consistent until the single-system decision is made.

What is the biggest risk of skipping data cleansing in the integration? Carrying suppliers with irregular registration status, duplicate materials and customers with outdated data into the new system, which causes tax errors, purchasing disruptions and rework in the months after the merger.

Do small and mid-sized companies also need to worry about this? Yes. The smaller the IT and governance structure, the greater the chance that master data integration is done manually and informally, which raises the risk of error precisely when the company is most vulnerable, in the middle of an ownership change.

MDM Academy

MDM Academy is 4MDG's school of data governance and master data, created to train professionals who understand both the technical side and the business impact of poorly managed master data. The courses cover everything from MDM and governance fundamentals to specific topics such as data quality, LGPD (Brazil's General Data Protection Law) and market tools, always with real project examples, the kind that come up in purchasing, supply chain and SAP processes.

If you want to prepare to work on projects like master data integration in M&A, it's worth getting to know MDM Academy and also joining the Data Club, the community of professionals who share experience on master data, quality and governance in the day-to-day of Brazilian companies.

Conclusion

A merger or acquisition is decided in the negotiating room, but it is sustained, or brought down, in the master. The company may have paid a fair price for the deal and still lose months of synergy because the supplier master took six months to become reliable. Master data doesn't appear in the announcement of the transaction, but it shows up every day in the operation afterward.

At your company, the last time there was a restructuring or acquisition, did the master go into the plan on day one or was it left for later?