> For the complete documentation index, see [llms.txt](https://docs.zingg.ai/latest/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zingg.ai/latest/zingg-concepts/zingg-configuration/field-definition/match-types/exact-match.md). # EXACT Match No tolerance for variation. Two values must match perfectly for EXACT to score them as a match. The right choice for trusted identifiers and categorical fields. ### What `EXACT` does `EXACT` compares two field values and scores them as matching only when they are identical. There is no tolerance for typos, abbreviations, case differences, or format variation. Use `EXACT` for any field where a difference in value means a definite difference in entity trusted identifiers like SSN, national ID, passport number, tax code and for categorical fields like country codes and boolean flags where variation is not expected. ### What `EXACT` matches and what it does not
Value AValue BMatch?
123-45-6789123-45-6789Yes - identical
123-45-6789123-45-6780No - single-digit difference
USUSYes - identical
USusYes - both values are lowercased by a case-normalization preprocessing step before the comparison runs, so "US" and "us" both become "us" and match
truetrueYes
true1No - EXACT does plain equality with no boolean coercion, so "true" and "1" do not match
2024-01-152024-01-15Yes
2024-01-1501/15/2024No - no date parsing under EXACT; differing formats are compared as literal strings
[null]123-45-6789Yes - EXACT treats a null on either side as an automatic match; add NULL_OR_BLANK if you want nulls excluded
### When to use `EXACT`
National identifiers - SSN, passport, tax ID, national ID These fields are reliable unique identifiers. An exact match on SSN means the two records are definitively the same entity. Any tolerance on these fields creates false positives that are very difficult to correct after the fact. Always use `EXACT` on trusted identifiers. In Zingg Enterprise, also add them as deterministic matching conditions; an exact match on a trusted identifier produces a guaranteed match with score 1 before the probabilistic model runs. → [Deterministic vs Probabilistic Matching](/latest/zingg-concepts/zingg-entity-resolution-platform/deterministic-vs-probabilistic-matching.md)
Date of birth, event dates Dates should not have fuzzy tolerance. "1985-06-15" and "1985-06-16" are different dates of birth - those are different people. Use `EXACT` for all date fields. If your date formats vary across source systems, normalise them upstream before matching - do not use `FUZZY` to bridge\ format differences on dates.
Country codes, boolean flags, categorical variables Short categorical codes where variation is not expected: "US", "GB", "IN", true/false,\ status codes belong with `EXACT`. These fields should have no tolerance. If a record says "US" and another says "UK", they are different countries. `FUZZY` would score them as similar (two-character strings\ sharing one character). `EXACT` does not.
### When not to use `EXACT`
Any field with known format variation Email addresses entered with and without dots, phone numbers with and without country codes, names that appear in short and long form - none of these are safe with `EXACT`. `EXACT` on a phone number field will miss "+1-415-555-0123" and "4155550123" as a match even though they are the same number. Use `FUZZY` or the field-specific match type (EMAIL for email, PINCODE for postal codes).
Name fields Never use `EXACT` on name fields. Even internally consistent data has legitimate name variations - legal name vs common name, maiden name vs married name. Use `FUZZY` for names.
{% hint style="success" icon="right-long" %} **Related types:** * `FUZZY` - use when variation is expected * `PINCODE` - EXACT-like for postal codes with format normalisation built in * `DONT_USE` - exclude from matching entirely **Read more**: [Match Types](/latest/zingg-concepts/zingg-configuration/field-definition/match-types.md) {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.zingg.ai/latest/zingg-concepts/zingg-configuration/field-definition/match-types/exact-match.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.