# False Matches – Definition, FAQs & How Dedupely Helps > False matches explained: why deduplication false positives happen, from shared info@ emails to common names, and how to reduce and reject them. - URL: https://dedupe.ly/glossary/false-matches - Section: glossary - Site index: https://dedupe.ly/llms.txt - Any page: append `.md` to its URL for this plain-text form --- [Glossary](https://dedupe.ly/glossary) False Matches ## False Matches False matches are records that a deduplication rule flags as duplicates even though they belong to different people, companies or deals. Also called deduplication false positives, they happen when records agree on the values a rule compares, such as a name, a shared info@ email address or a company's main phone line, while the records themselves describe different things. False matches are one side of a trade-off built into duplicate searching. Stricter rules produce fewer of them but miss more real duplicates, which are called false negatives. Looser rules find more duplicates and more false matches. Because a merged false match combines two customers into one record, and merges are often hard to reverse, teams reduce them before merging, with stronger field combinations, checks on suspicious sets and review. See how Dedupely sorts real duplicates from false matches in your CRM [Try for free](https://v2.app.dedupe.ly/signup) [Talk to sales](https://meetings.dedupe.ly/meetings/gaby-salinas/talk-to-sales) Overview False matches are records a deduplication rule pairs as duplicates even though they describe different people, companies or deals. They often come from shared values, such as an info@ email or a main office phone, and are reduced with stronger field combinations, safety checks and review before merging. On this page - What Are False Matches? - How False Matches Work - Why False Matches Matter for CRM Teams - Getting Started With False Matches - Key Takeaways: False Matches - Frequently Asked Questions About False Matches - Related Terms and Concepts See how Dedupely sorts real duplicates from false matches in your CRM [Try for free](https://v2.app.dedupe.ly/signup) [Talk to sales](https://meetings.dedupe.ly/meetings/gaby-salinas/talk-to-sales) ### What Are False Matches? A false match, or false positive, is a duplicate set whose records only look alike to the rule that grouped them. The rule did what it was set to do: it compared the chosen fields and found the same values. Those values just weren't unique to one person or company. A simple example: a contact search matches on email + phone. "Maria Lopez, info@brightdental.com, (555) 010-4400" and "Daniel Kim, info@brightdental.com, (555) 010-4400" both work at the same dental practice and were entered with its front-desk inbox and main line. The rule pairs them, but they're two people, and their names show it. Common sources include shared inboxes and phone lines, common names such as J. Smith, placeholder values like N/A, family members or colleagues who share one address, and related companies, such as a parent and its subsidiary, that share a website. False matches appear on every object: contacts and companies in HubSpot, leads and accounts in Salesforce, people and organizations in Pipedrive, and leads in Close. The opposite error is a false negative: a real duplicate the rule misses, such as two records for one person with a typo in the email. There are a few ways to keep false matches low. Tightening the rule, with more fields or stricter methods, stops them before they appear and suits large searches. Checks on the results, such as a cap on set size or a block on placeholder values, catch patterns a rule lets through. Reviewing sets by hand catches cases no rule anticipates, and rejecting a false pair keeps it from returning. Resources: - [What is a duplicate?](https://dedupe.ly/blog/what-is-a-duplicate) ### How False Matches Work False matches come from the matching stage, before anything is merged. Each step of a duplicate search can let one in, and each has its own fix: - **Choosing the fields.** A field many records share, such as last name, city or company phone, pairs records that only happen to agree on it. Pairing it with a field that belongs to one record, such as a personal email or customer ID, keeps those records apart. - **Choosing how loosely to compare.** Looser methods, such as similar or fuzzy matching, treat close values as the same, so two different names one letter apart, such as "Dana" and "Diana," can pair. Keeping at least one field strict limits what a loose field lets in. - **Skipping words.** Ignored terms make a field more lenient. Skip a word that tells two records apart, such as "North" in a branch name, and the records look the same. - **Grouping the matches.** One shared value can pull many records into one set, so a set far larger than a real duplicate is a sign of false matches. - **Checking before merging.** Size limits, placeholder checks and review catch the false matches a rule lets through. A false pair that's rejected stays out of later results, so no one reviews it twice. Each fix trades some reach for precision. A stricter rule produces fewer false matches and finds fewer real duplicates too, so it's worth checking the false negatives it creates as well. Resources: - [Match Options](https://dedupe.ly/knowledge-base/match-options) (KB) ### Why False Matches Matter for CRM Teams A merged false match does lasting damage. Two customers become one record: one person's email or owner can replace the other's, their calls, notes and deals share a timeline, and the next message can reach the wrong person. Reports then count one customer where there were two, and the error is hard to spot after the merge, because the record looks clean. False matches also cost time before anything is merged. Every set that needs a second look slows down review, and a search known to produce them can't be trusted to run in bulk or on a schedule. That keeps automation limited to the searches with the fewest false matches, and leaves the rest of the work to people checking sets one at a time. When the same false pairs come back after every search, that review work repeats too. Avoiding them by matching too strictly has a cost too. The false negatives stay in the CRM: duplicate contacts inflating counts, activity history split across records, two reps working one account and, in CRMs that bill by contact count, records paid for twice. The goal is a balance that fits each search: strict where an automatic merge depends on it, and looser where a person reviews the results before anything changes. Resources: - [Why your CRM database is turning into a mess (and how to fix it)](https://dedupe.ly/blog/why-your-crm-database-is-turning-into-a-mess) ### Getting Started With False Matches Start by finding the shared values in your data before building a rule: role inboxes such as info@ and sales@, main office numbers, placeholder values and the most common names. Those are the values most likely to pair records that aren't duplicates, so they show which fields can't be trusted on their own. Build each search on a few fields, with at least one that belongs to only one record, such as a personal email address or customer ID. Run it, then look at a sample of the sets before merging, starting with the largest ones and the ones found by looser methods, since that's where false matches show up first. Reject the false matches you find, so they don't return in later results, and send uncertain sets for review instead of guessing. When the same kind of false match keeps appearing, change the rule rather than rejecting each pair. Check for false negatives as well, using a few known duplicates, so a tighter rule doesn't hide the real ones. In Dedupely, a Duplicate Search can compare several fields, each with its own Match Option, and records pair only when every field meets its criteria, so a shared inbox or main line isn't enough to pair two people on its own. Rejected Matches carries out the review step, removing a false match from current and future Duplicate Searches until you choose to restore it. Resources: - [Rejected Matches](https://dedupe.ly/knowledge-base/rejected-matches) (KB) - [Duplicate Searches](https://dedupe.ly/knowledge-base/search-pads) (KB) ### Key Takeaways: False Matches False matches are records paired as duplicates that describe different people, companies or deals. They come from values many records share, such as info@ emails, main phone lines, common names and placeholders, and from loose methods or ignored words that make different values look the same. Fewer false matches often means more false negatives, so each search needs its own balance, with checks and review before merging. In Dedupely, a Duplicate Search combines several fields, each with its own Match Option. Safety Settings hold matches with more than 20 records or built on poor or example data out of bulk selection and Auto Merge. Manual Review holds uncertain sets, Rejected Matches keeps false pairs out of current and future searches, and Merge History records the original values of every merge. Resources: - [Dedupely product overview](https://dedupe.ly/product) ### Frequently Asked Questions About False Matches #### Why does exact matching produce deduplication false positives? Because exact matching checks that values are the same, not that they belong to the same person or company. When a value is shared, an exact match on it pairs records that aren't duplicates. Shared inboxes like info@, a company's main phone line, common names and placeholder values such as N/A all repeat across unrelated records, and an exact match treats each repeat as a duplicate. Very short values add to the problem: an exact match on a first initial pairs every record with "J." in that field. Exact matching on a unique identifier, such as a personal email or customer ID, rarely causes this, so the fix is often the field rather than the method: combine the shared field with one that tells records apart. In Dedupely, Exact matches identical values while ignoring capitalization. Safety Settings hold back matches built on poor or example data by default, and a Very short values rule, off by default, can hold back matches on values like a single letter. #### What's the difference between false positives and false negatives in deduplication? A false positive is a pair of records flagged as duplicates that aren't, and a false negative is a real duplicate the search misses. A false positive risks merging two different customers into one record. A false negative leaves a duplicate in the CRM, where it keeps splitting history and inflating counts. The two move in opposite directions: a stricter rule, with more fields or exact comparisons, produces fewer false positives and more false negatives, and a looser rule does the reverse. Because a wrong merge is often harder to fix than a missed duplicate, many teams accept a few false negatives on searches that merge without review, and use looser searches where a person checks each set. In Dedupely, each field in a Duplicate Search gets its own Match Option, such as Exact, Similar, Fuzzy, Similar Words or Domain Root, so one search can keep a strong field strict while another is compared more loosely. Rejected Matches then keeps the false positives a looser search finds out of future results. #### How do you reject a false match so it doesn't come back? Mark the set as not a duplicate in your deduplication tool, so later searches leave it out instead of flagging it again. Without a rejection, the same records match each time the search runs, because their values haven't changed. Rejecting works on one pair or set: it records that these records are different, and it leaves the rule as it is. If the same kind of false match keeps appearing, such as many contacts sharing one office line, it's the rule that needs changing, with a stronger field or a stricter method. In Dedupely, rejecting a match removes that duplicate set from current and future Duplicate Searches. A rejection can be reversed with "Remove from Rejected" if a set turns out to be a real duplicate after all. Matches found by Dedupely Intelligence, Dedupely's AI duplicate matching, can be rejected and restored as well. When Auto Match sends a notification, you open Dedupely to merge the new matches, send them to Manual Review or reject the false ones. #### How do you keep shared emails like info@ from creating false matches? Don't let a shared email decide a match on its own: pair it with a field that belongs to one person, such as first and last name. Role-based addresses like info@, sales@ or support@, and addresses a household or team shares, sit on records for different people, so an email-only rule on contacts groups them together. The same address means something different on another object. On companies, a shared email domain is often a sign of a real duplicate, so the right rule depends on what's being matched. A filter or a separate search can keep role-based addresses out of a contact search that runs unattended, and the sets they do create are worth a check before merging. In Dedupely, a Duplicate Search that compares Email with First Name and Last Name pairs records only when each field meets its criteria, so two people who share info@acme.com stay apart. On a company search, Domain Root compares the core domain of an email or website, so sales@acme.com and support@acme.com can point to the same company. #### Can a false match be merged by mistake, and can you undo it? Yes, a false match can be merged by mistake, and in many systems the merge can't be fully reversed. It happens most often in bulk or scheduled merging, where no one looks at each set, or when a reviewer trusts a match that looks right on the surface. Undoing it means splitting one record back into two: finding the original values, recreating the second record and moving the right calls, notes and deals back to it. That's why the checks come before merging: review a sample, hold back large or placeholder-based sets, and keep automatic merging to searches with few false matches. In Dedupely, merges can't be undone. Safety Settings keep risky matches out of bulk selection and Auto Merge, and Auto Merge sends low-confidence matches to Manual Review instead of merging them. If a false match is merged, Merge History shows each original record with its values and can be downloaded as a CSV, so you can recreate the records and restore their values by hand. ### Related Terms and Concepts #### [Exact matching](https://dedupe.ly/glossary/exact-matching) Exact matching produces few false matches on unique identifiers and more on shared values, such as a main phone line. The field it's used on decides most of the false matches it creates. #### [Fuzzy matching](https://dedupe.ly/glossary/fuzzy-matching) Fuzzy matching pairs names that sound alike, which brings in more real duplicates and more false matches. Keeping another field strict limits what it lets in. #### [Multi-field matching](https://dedupe.ly/glossary/multi-field-matching) Multi-field matching is the main way to cut false matches, because a shared value only pairs records when another field agrees too. #### [Ignored terms](https://dedupe.ly/glossary/ignored-terms) Ignored terms make a field more lenient. Skipping a word that tells two records apart is a common source of false matches. #### [Merge safety](https://dedupe.ly/glossary/merge-safety) Merge safety holds back the matches most likely to be false, such as oversized sets or matches built on placeholder data, before they're merged in bulk or on a schedule. #### [Manual review](https://dedupe.ly/glossary/manual-review) Manual review is where uncertain sets go for a person to decide. It's the place to sort out the false matches a rule can't tell apart from real duplicates. Skip to content