Data matching: what it is, how it works and why it decides whether two records are the same entity

Data matching is the process by which an MDM system compares records coming from different sources and decides whether two master records, even if written in different ways, represent the same real-world entity: the same material, the same supplier, the same customer.

It seems simple until you look inside a real material base. "Zinc-plated M6 x 20mm Allen screw" and "ALLEN SCR M6X20 ZINC" can be the same item, created by two different people, at two different times, without any system warning that it already existed. Matching is the layer that solves exactly this kind of problem, before it turns into duplicate inventory, repeat purchasing or a spend report that lies to the procurement director.

I've seen a company buying the same item in two different ways, each with its own code, its own contract and its own price history. Nobody lied, nobody made a mistake on purpose. There was simply no mechanism able to look at two similar records and say: this is the same thing.

How matching works in practice

Every matching engine starts from a simple question: which attributes do I use to compare one record with another. In the material master, it can be description, unit of measure, manufacturer, barcode or NCM (Mercosur Common Nomenclature, Brazil's tax classification code). In the supplier master, it can be legal name, CNPJ (Brazil's company registration number), address and trade name. This combination of fields used in the comparison is called a match key.

From there, there are two paths. Deterministic matching compares exact fields, with fixed rules: same CNPJ, same manufacturer code, it's a match. It is fast and predictable, but breaks at the first typing difference. Probabilistic matching, also called fuzzy matching, calculates a similarity score between records, taking into account small spelling variations, abbreviations, word order and even typos. If the score exceeds a given threshold, the system flags the two records as a possible duplicate and sends them to someone to confirm.

This second approach is the one that solves the real problem of the material master, because there is no unique key there like the CNPJ. Two analysts describe the same screw in two different ways and neither is wrong, they are just different. The matching engine compares phonetics, abbreviations and text structure to realize that the two descriptions point to the same physical object.

One point that tends to cause confusion: matching is not the same thing as record validation. Validating a supplier means checking whether the CNPJ is active with the Receita Federal (Brazil's federal tax authority), whether the certificate hasn't expired, whether the registration status is in good standing. Matching is another step: after the record exists, deciding whether it had already been created before, under another name, by another person.

Who takes care of matching inside the company

The matching engine runs inside the MDM tool, but the final decision on what to do with a suspected match can't be left to the machine alone. Every mature implementation has a review flow, normally run by the domain's data steward, who receives the list of probable duplicates and confirms, rejects or adjusts.

This means data matching is not an IT-only project. Procurement needs to validate material matches because it knows the technical specification. The tax team takes part when the match involves NCM or tax classification. Supply chain comes in when the item has a packaging or unit variation that looks like a difference but isn't. The technology delivers the engine and the score. The decision about what the score means in your business belongs to those who live with the master data every day.

I defined this in my book Master Data Management: Fundamentos e Aplicações (book in Portuguese): an MDM tool without a defined data owner becomes a match engine running on its own, piling up suggestions nobody reviews.

Which tools perform master data matching

The MDM market has specific solutions for this process, each with its own way of calculating similarity and presenting the result for human review. SAP Master Data Governance, aimed at those already operating in the SAP environment, builds matching rules into the record approval flow itself. Informatica MDM has one of the most widely used match and merge engines in large implementations, with algorithms configurable by domain.

Stibo Systems and Reltio also have mature matching engines, with a strong focus on product and customer, respectively. Semarchy and Profisee bring more agile configuration approaches, which helps companies that want to implement faster without losing quality in the comparison. Ataccama, historically more tied to data quality, also offers matching as part of its package for cleansing and standardizing the base.

None of these tools replaces the business decision. They speed up the comparison and learn from the history of confirmations, but the criterion for what is or isn't the same entity is still defined by the company, in the match rule that is configured.

What happens after the match: survivorship and golden record

When two or more records are confirmed as the same entity, the system needs to decide which version of each field will survive in the final record, the so-called golden record. This decision follows survivorship rules.

A common rule is to prioritize the most recent data. Another is to prioritize the most reliable source, for example, treating the CRM as the source of truth for contact phone and the ERP as the source of truth for tax data. It is also common to use the most complete field: between two addresses, the one with the CEP (Brazil's postal code) filled in wins.

Poorly defined survivorship creates a golden record that is worse than the original records, because it mixes the wrong piece from each source. I've seen a case of a supplier master that, after the automatic merge, ended up with one branch's phone number and another branch's address. Technically it was a single record. In practice it was a wrong record, just with a nice name: golden record.

How to learn data matching in practice

Anyone who wants to really understand matching first needs to master the fundamentals of data quality and master data modeling, because the comparison logic only makes sense when you understand the structure of the domain you are comparing. After that, it is worth studying in depth the dimensions of data quality, the difference between reference data and master data, and how each tool on the market treats the similarity score.

The DAMA CDMP certification helps organize that knowledge within an internationally recognized body of knowledge, the DAMA DMBOK. It isn't about collecting certificates. It is about having the right vocabulary to discuss a match rule with a software vendor without depending only on what the salesperson presents on the slide.

In practice, the fastest way to learn is to take a real base, with known duplication, and try to configure a simple match rule: compare description and unit of measure, for example, and see how many false positives and false negatives that rule generates. Then adjust. You learn matching by adjusting, not by reading the manual.

Career opportunities in matching and MDM

Professionals who understand data matching are sought after in MDM implementation projects, in migrations to SAP S/4HANA and in any master data unification initiative after a merger or acquisition. It is a skill that mixes technical knowledge of tools with business knowledge of the domain, and that combination is rare.

Data steward, master data analyst and data quality specialist are the roles that use matching most in their day to day. As professionals advance, that experience becomes a gateway to MDM architect positions and, later, to data governance leadership. Demand for people who understand matching tends to grow along with the adoption of AI in companies, because an AI model trained on duplicated records learns the error along with the right pattern.

Main questions about data matching

Is data matching the same thing as deduplication? Not exactly. Deduplication is the result, eliminating or merging duplicate records. Matching is the technique used to identify which records are candidates for that merge before any action is taken.

What is the difference between deterministic and probabilistic matching? Deterministic compares exact fields and only considers it a match when everything lines up. Probabilistic calculates a similarity score and accepts variations in spelling, abbreviation and word order, flagging as a possible match anything above a defined threshold.

Does data matching replace human review? No. The matching engine indicates candidates and calculates the probability that they are the same entity. The final confirmation, especially for intermediate scores, should go through a data steward who knows the domain.

Does every MDM tool have its own matching engine? Most of the relevant platforms on the market, such as SAP MDG, Informatica, Stibo, Reltio, Semarchy, Profisee and Ataccama, offer some native matching engine. The quality and configuration flexibility vary quite a bit among them.

Does matching work well for suppliers in Brazil? For suppliers, the CNPJ already works as a unique key in most cases, which reduces the need for fuzzy matching. The biggest gain from matching in Brazil is in materials, where there is no natural unique key and the same part can be described in dozens of different ways.

MDM Academy

Everything I described here, from match key logic to survivorship configuration, is the kind of knowledge we teach at MDM Academy, the data governance and master data school of 4MDG. The Academy was created to train the professional the Brazilian market looks for and can't find ready-made: someone who understands technology but also understands the impact of wrong master data on purchasing, sales and financial close.

The courses combine governance theory with real cases from SAP projects, procurement and supply chain, at the pace of someone who has lived the problem firsthand, not someone who only read about it. Those who want to go beyond the courses can join the Data Club, our community of master data and governance professionals, where the topic of the day may be exactly this: why the same screw is registered three times in your ERP.

It is worth getting to know MDM Academy if you want to stop being someone who only complains about bad master data and become the person who fixes it.

Conclusion

Data matching is one of those behind-the-scenes pieces nobody celebrates when it works and everybody feels when it fails. It doesn't show up in leadership slides, it doesn't make headlines, but it decides whether your company buys at the right price, whether inventory matches reality and whether the AI you are implementing will learn the right pattern or the repeated error.

Every time someone asks me where to start an MDM project, I answer the same thing: before buying the most expensive tool on the market, understand the size of your duplication. Matching is the technique. The decision to take it seriously is yours.

In your company, have you ever stopped to measure how many times the same material is registered under different names?