Schema matching across systems.
Two systems were never built to agree. Schema matching is how their fields get lined up, so the same account becomes one clean record instead of two arguing copies.
Schema matching is the work of figuring out, automatically, that a field in one system means the same thing as a field in another. We walk it the way the field is built: what it is, why it is hard, how a modern system does it, what it makes possible, and where it is heading. The papers behind each idea are linked, so you can read the source yourself.
| Sales system | Billing system | |
|---|---|---|
Account NameNorthwind | → | company_nameNorthwind |
phonePhone number | → | telephonePhone number |
Deal Value48,000 USD | → | amount_usd48,000 USD |
Finding which field means the same thing as which field.
Every tool keeps records in its own shape. Schema matching is the translator that maps one shape onto another, so data can move without scrambling.
Picture two CRMs that need to agree: a marketing tool and a sales tool, same accounts, same contacts, different labels and different layouts. One calls it Company, the next calls it Account Name, a third calls it org. The information is the same. The shape is not. Schema matching is the work of figuring out, automatically, that Company here means the same thing as Account Name there, that amt_usd lines up with Deal Value.
The output is a set of correspondences, a map: this column here goes to that column there. Sometimes one to one, sometimes many to one, as when first name plus last name fold into a single full name. That map is what a migration or a sync then runs on. Get it right and you can pour two systems into one. Get it wrong and the same account shows up twice, a contact arrives half filled, and a pipeline goes stale because nobody can tell which record is live.
One distinction to keep clean, because the rest of this page depends on it. Schema matching lines up the fields and columns: Company equals Account Name. Entity matching, also called record linkage, lines up the rows and records: deciding that these two account rows are the same real company and should merge. The CRM pains you feel, a duplicate account, a half-filled contact, touch both. This page leads on schema matching and names record matching as its close cousin. We try never to blur them.
| Source field | Relationship | Target field |
|---|---|---|
| Account Name | Same concept | Company |
| amt_usd | Units established | Deal Value (USD) |
| first + last | Transformation | Full Name |
| product.name | Different concept | person.name |
A label is a weak clue, and there are too many of them.
The same idea hides behind different labels, the same label hides different ideas, and two schemas create hundreds of possible pairings, most of them wrong.
The label barely tells you anything.
cust_nm, Client, and Account Name mean the same thing and share almost no letters. Meanwhile name can be a person in one table and a product in another. Matching on the label alone is guesswork.
Same idea, different layout.
One system stores a phone number as a single string. Another splits country code, area, and number into three fields. One address field versus five. The information matches, the shape does not, so a clean one-to-one map does not exist.
Hundreds of possible pairings.
Two schemas with dozens of fields each create hundreds of candidate pairs, and several fields will look plausibly like several others. The system has to rank, not just guess.
No single signal is enough.
The name says one thing, the data type says another, the constraints say a third. Any one of them alone is fragile. Real systems must weigh them together, and weighing is its own problem.
A wrong match is worse than no match.
A confident but wrong correspondence silently corrupts data downstream: the duplicate account, the half-filled contact, the stale pipeline record. That is why the field treats output as a proposal to confirm, not a final answer.
Some fields only context can settle.
Closed can mean a won deal or a closed support ticket. The right match depends on what the surrounding data is about, which a surface comparison of names and types misses.
Read several clues, then weigh them together.
The survey by Rahm and Bernstein lays out a clean taxonomy that doubles as a teaching order. Each rung is a kind of clue. Good systems climb several and combine them.
- Name
- Labels, abbreviations, and synonyms.
- Values and type
- Dates, amounts, identifiers, and sample values.
- Constraints
- Keys, uniqueness, and required fields.
- Structure
- Parent records and related fields.
The taxonomy from the 2001 survey as a ladder: no single clue decides. The score builds as the rungs combine.
1Read the names, then read the values
Start cheap, then look inside the column.
The first pass compares column headers and labels: exact matches, shared words, abbreviations, synonyms. org is close to company, qty is close to quantity. Cheap and useful, and not enough on its own.
The second pass reads the actual data. A field full of dates lines up with a field full of dates, money with money, emails with emails. Looking at the values inside a column, called instance-level matching in the survey, catches pairs the names would miss and rejects pairs the names would wrongly suggest.
Different names
cust_nm
client_name
account_labelMay describe the same concept.
Same name
product.name
person.nameDescribes different concepts.
2Read the rules, then read the structure
Constraints carry meaning. So does where a field sits.
Constraints are a strong clue: this field is required, this one is unique, this one is a key that points at another table. Two fields that are both the unique identifier of an account are strong candidates even when their names differ.
Fields do not float. They sit inside tables that relate to other tables. Similarity Flooding (Melnik et al., 2002) formalized this: model both schemas as graphs and let confidence flood along the connections, so agreement between neighbors reinforces agreement between fields. If two parent records already match, their children are more likely to match too.
| Source path | Target candidate |
|---|---|
| Account.billing_city | Organization.billing_address.city |
| Contact.home_city | Person.home_address.city |
Both fields contain city names, but their parent relationships differ.
3Combine the matchers and weigh them
Run many matchers, then settle on one decision.
No single clue wins, so good systems run several matchers and combine their scores. COMA (Do & Rahm, 2002) made this the central idea: run many individual matchers, combine them with explicit strategies, and reuse correspondences confirmed on past matches so the system improves over time.
Earlier, Cupid (Madhavan et al., 2001) had shown a strong single pipeline that fused name, data type, and structure with a tree-matching step. The shared lesson is the same: many signals, one ranked decision.
Combine signals using the selected rule or learned model.
4From hand-coded rules to learned meaning
Let a model read what a field means.
Newer work replaces brittle rules with models that read meaning. On the close cousin of record matching, Ditto (Li et al., 2020) framed entity matching as a question a pre-trained language model can answer, do these two records refer to the same thing, using the model's grasp of language plus injected domain hints. We name it clearly as the sibling task: it matches rows, not columns.
A more recent direction points a language model at the schema itself. Matchmaker (Seedat & van der Schaar, 2024) builds a self-improving program that generates candidate correspondences, refines them, and scores confidence, with no labeled training set. This reads context and synonyms more flexibly than the classic signals.
Field: acct_nm
Type: text
Samples: Acme, Globex
Parent: customer recordThe proposal uses the name, values, type, and context.
5Keep a person in the loop
Matching proposes. A person confirms.
Across every method above, the output is a ranked proposal with confidence, not an irreversible decision. A reviewer confirms or corrects before anything merges. The field has held this posture from the 2001 survey through the language-model papers, for one plain reason from earlier on this page: a wrong match is worse than no match.
That turns mapping hundreds of fields by hand, which is slow and error-prone, into reviewing and confirming a ranked list, which is faster and more consistent, with a person still on the final call.
| Proposal | Review |
|---|---|
| Account Name → Company | Confirm meaning |
| amt_usd → Deal Value | Confirm currency |
| close_dt → Closed | Reject: date is not a boolean |
Version the mapping and test it on representative values.
Good matching is the quiet plumbing under a trustworthy record.
At the field level: migrations that do not scramble the data, one trustworthy view of an account, syncs that keep agreeing, and less hand-mapping. Reporting and forecasting all depend on records that line up.
This family of techniques is how the industry gets two systems that were never built to agree to line up cleanly. Here is what that alignment looks like as an everyday outcome for a seller, described at the outcome level, not as a claim about how any one product is built.
The same account stops showing up twice.
When fields line up correctly and duplicate rows are reconciled, the same company stops appearing twice in your view. See Clean CRM.
A contact arrives with its fields full.
When fields land in the right slots, a contact arrives filled in, not half empty. See After-meeting notes.
Your pipeline reflects the live record.
Reconciled records mean the pipeline reflects the current account, not a stale duplicate, so reporting and forecasting stand on data that lines up.
Less mapping by hand.
Reviewing and confirming a ranked list is faster and more consistent than mapping hundreds of fields by hand, with a person still on the final call.
This explainer covers published research. To see how AI REV Voice helps with sales conversations, explore Prism.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
From rules to models that read context.
The arc runs from name-and-type heuristics, through combined matchers, to models that read what a field means in context. This handles synonyms and ambiguous labels more flexibly than fixed rules.
Language models help, but not for free.
A measured study (2024) points an off-the-shelf language model at the problem and finds it is not a free win: how much context the model is given matters, and it still proposes rather than decides. Any reported gain belongs to its source paper, never to anyone reading this page.
Less labeled data needed.
Methods that reuse past confirmed matches, as COMA does, and self-improving programs, as Matchmaker does, reduce the up-front labeling burden that made classic learning approaches expensive.
A reason, not just a score.
A direction worth naming: matches that come with a reason a reviewer can read, so the review step is faster and more trustworthy.
A person still confirms.
Every generation of this field, including the newest, treats the output as a high-quality proposal for review. Better proposals, not removed humans.
The papers behind this page.
- Rahm & Bernstein (2001). A survey of approaches to automatic schema matching. The VLDB Journal.
- Madhavan, Bernstein & Rahm (2001). Generic Schema Matching with Cupid. VLDB.
- Melnik, Garcia-Molina & Rahm (2002). Similarity Flooding: a versatile graph matching algorithm and its application to schema matching. ICDE.
- Do & Rahm (2002). COMA: a system for flexible combination of schema matching approaches. VLDB.
- Li, Li, Suhara, Doan & Tan (2020). Deep Entity Matching with Pre-Trained Language Models (Ditto, the record-matching cousin). arXiv:2004.00584.
- Seedat & van der Schaar (2024). Matchmaker: self-improving large language model programs for schema matching. arXiv:2410.24105.
- Schema Matching with Large Language Models: an Experimental Study (2024). arXiv:2407.11852.
Keep reading.
Sibling explainers in the Research section.
Talk. Done.
Clean records start with fields that line up. See what a spoken call turns into.
No app required. Just your phone number.