Entity Matching and Name Collisions in Indian Litigation Search
Why two unrelated people or companies with the same name get mixed up in Indian court records, why the same party can also look like two different ones, and what a search process needs to tell them apart.
Explainer · Litigation Search Technology
Search for "Ramesh Kumar" or "ABC Enterprises" in an Indian court database and you will not get one result. You will get dozens, sometimes hundreds, belonging to entirely different people and companies who simply happen to share that name. This is the entity matching problem: working out whether two records that carry the same name are actually about the same real person or company, or about two unrelated parties who happen to be named alike. Get this wrong one way and you miss a case that genuinely belongs to the party you are checking. Get it wrong the other way and you attribute someone else’s litigation to them. This explainer covers why entity matching is hard in the Indian context, the two failure modes it causes, and what a search process needs to get it right.
- The problem: a litigation search on a common Indian name or generic company name often returns records belonging to several unrelated entities, not just one.
- Two failure modes: collisions (different entities wrongly treated as the same, a false positive) and name variation (the same entity missed because it was spelled differently, a false negative).
- Why India is especially prone to this: a huge pool of shared personal names, no single national identifier used in court filings, and company names that shift across mergers, rebrands, and group structures.
- What works: combining contextual signals such as father’s name, address, CIN, and case context, with enough underlying detail for a human reviewer to confirm identity.
- What to check in a tool: whether it catches spelling variants, and whether it exposes enough case detail to tell same-named entities apart, not just whether it returns results.
01Why entity matching is hard in Indian litigation search
Entity matching, sometimes called entity resolution, is the process of deciding whether two records that name a party are about the same real-world person or company, or about two different ones. Every time a litigation search tool returns a result, it is implicitly making this decision. In India, it gets this wrong more often than most people realise, for reasons that are structural rather than accidental.
India has an enormous pool of shared names
India has over a billion people, and personal names are far less diverse than the population. Names such as Mohammed Khan, Suresh Sharma, Sunita Devi, or Rajesh Kumar are carried by thousands of unrelated individuals across the country. A litigation search on any of these names will pull in every case involving anyone who shares it, not just the one person you are actually checking.
There is no single identifier tying a person to their court cases
Court records are built around the name as it was typed in the filing. There is no consistent practice of also recording a national identifier such as Aadhaar or PAN in the case caption. A father’s name, age, or address sometimes appears alongside the party name, but not reliably, and not in a standard field a search tool can rely on across every court. This means the name is often the only handle you have, and a name alone cannot always tell two people apart.
Company names collide too, and they change over time
Businesses face the same problem from a different angle. Generic or descriptive company names, such as “Shree Enterprises” or “National Traders”, are registered by unrelated promoters in different states, sometimes dozens of times over. A single company can also appear under an older registered name from before a merger or rebrand, a shortened trade name, and its full legal name, all in different filings for the same underlying dispute.
Group structures add another layer
Many Indian business groups run several groups companies that all carry a shared brand name with only a suffix or business line changed, for example a group using one brand name across a real estate arm, a finance arm, and a trading arm. A litigation record naming the brand alone, without the full registered entity name, can leave real doubt about which specific group company the case actually concerns.
A separate but related job
This page is about telling entities apart, not about tracking a matter once it is confirmed as yours. For that, see what a litigation tracker is.
02The collision problem: different entities, same name
A name collision is when a search returns a record that genuinely matches the name you typed, but belongs to a completely different, unrelated party. This is a false positive, and it is the more dangerous of the two failure modes because it looks like a hit rather than a gap.
Consider a bank running a litigation check on a loan applicant named Suresh Patel. A name search returns forty records. Most of them belong to other Suresh Patels scattered across different states, with no connection to the applicant at all. If the reviewer treats the volume of results as a red flag without checking which records actually belong to this specific applicant, a creditworthy borrower can be wrongly flagged, delayed, or declined because of someone else’s litigation history.
The same risk runs the other way in vendor or counterparty onboarding, director background checks, and M&A due diligence: a genuinely serious case belonging to the party you are checking can sit unnoticed in a long list dominated by unrelated same-named entries, simply because no one had a reliable way to separate the two.
A search that returns forty results for a common name has not necessarily found forty cases against your party. It may have found one case, buried in thirty-nine that belong to someone else entirely.
03The reverse problem: one entity, many spellings
The opposite failure mode is just as common: the same real person or company appears under several different spellings across Indian court records, because Indian names are transliterated from many regional languages with no single standard romanisation, and because clerks, typists, and scanning software each introduce their own variation. A search for one spelling can miss records filed under another, even though every one of them is about the same party.
This is a well-studied problem in its own right, and it deserves its own depth rather than a summary here. If your immediate concern is a search that returns nothing because a party name is spelled differently in the record, see our explainers on phonetic name matching and proximity case search, and the step-by-step guide on searching cases when a name is misspelled.
The reason it matters here is that a search tool cannot treat these two failure modes in isolation. A tool tuned only to catch spelling variants, without any way to separate genuinely different entities, will simply widen the collision problem: it will now also pull in more spelling variants of unrelated same-named parties. Good entity matching has to solve both problems together, not one at the expense of the other.
04What good entity matching looks like
No single signal reliably tells two same-named Indian parties apart on its own. What works is combining several imperfect signals, each of which narrows the possibilities.
| Disambiguating signal | What it narrows down | How reliably it is available |
|---|---|---|
| Father’s or husband’s name | Separates individuals who share an identical first and last name | Present in some criminal and civil filings, not standard across all courts |
| Address or location | Narrows which of many same-named individuals is meant | Sometimes present, but addresses also repeat and can be outdated |
| PAN (individuals) | A unique financial identifier, in principle | Rarely captured inside the court record itself |
| CIN, the Corporate Identification Number (companies) | Uniquely identifies a registered company regardless of name changes | Consistently available in MCA records; sometimes cited in company litigation |
| DIN, the Director Identification Number | Links a named individual to the companies they direct | Useful for cross-referencing, less so for pinpointing a person within a single case caption |
| Case context: opposing party, subject matter, court, advocate | Does not identify by itself, but corroborates whether two records plausibly belong together | Almost always present, making it the most consistently usable signal |
Two further principles matter as much as the list of signals itself. First, coverage and depth still come first: a tool with narrow coverage cannot disambiguate records it never retrieved in the first place. Second, the underlying record has to expose enough detail, such as the full case text, the other party’s name, the court, and the date, for a human reviewer to make the final call with confidence, rather than asking them to trust a name match alone.
05How entity matching works in practice
A well-built litigation search process handles this in layers, rather than relying on any single technique.
Cast a wide net first
The search layer applies proximity and phonetic matching so that spelling and transliteration variants of the same name are all retrieved together, rather than missed because they were typed differently. This solves the false-negative side of the problem, covered in depth in the explainers linked above.
Then narrow using context, not just the name
Once a broad set of name-matching records is retrieved, the system, or the reviewer, uses whatever contextual signals are available: a father’s name, an address, a CIN, the identity of the opposing party, the court, or the timeframe, to group records that plausibly belong to the same entity and separate out the ones that do not.
Surface enough detail for a human to confirm
Fully automatic entity resolution, with no human check, carries real risk in a legal context, because the cost of a wrong call runs in both directions: wrongly clearing a party with real litigation, or wrongly flagging a party with none. The safer design surfaces the full underlying record, not just a name match, so a trained reviewer can make the final identity call by reading the actual case detail rather than trusting an algorithm’s guess.
Keep the case, and its identity, linked going forward
Once a record is confirmed to belong to a specific party, that link should persist. A case that started at a lower court and moved on appeal should stay connected to the same confirmed entity through every stage, rather than requiring the disambiguation work to be repeated each time the matter resurfaces in a different court.
06Why this matters for due diligence and litigation screening
Entity matching is not a theoretical data problem. It sits directly in the path of decisions that involve money and risk.
- Banks and NBFCs screening a borrower or guarantor need to know which litigation results are genuinely about the applicant, not about a same-named stranger, before they act on them.
- M&A and private equity teams running due diligence on a target company or its promoters cannot afford to either miss a real dispute buried in noise, or waste diligence time chasing unrelated cases.
- Companies checking a director or promoter’s background need confidence that a case attributed to that individual is actually theirs, not another person carrying the same name.
- Corporate legal and procurement teams onboarding a vendor or counterparty face the same question at a smaller scale, but the underlying risk of a wrong call is the same.
For a structured way to run this kind of check, see our litigation due diligence checklist for India, our explainer on what a litigation search report is, and the guide to checking the litigation history of a director or promoter.
07Where Claw fits
Claw is an all-in-one legaltech platform for Indian advocates, law firms, and corporate legal teams, combining AI-based case search, an AI legal assistant (Legal GPT), case management, and compliance automation across all Indian courts and tribunals. It is positioned as India’s first all-in-one legaltech platform of this kind.
On the entity matching question specifically, Claw’s case search is built to be name-tolerant: it applies proximity and phonetic matching so that spelling and transliteration variants of the same party are retrieved together, across its database of 30 crore judgements spanning 25 High Courts (1980 to 2026) and the Supreme Court (1950 to 2026), with results in under 5 seconds. That solves the missed-match side of entity matching described above.
For the collision side, that is, telling two same-named but unrelated parties apart, Claw returns verified, court-ready citations with the full underlying case detail, including the opposing party, court, and date, so a reviewer can confirm identity from the actual record rather than a bare name match. Claw does not currently offer automated cross-database identity resolution against external identifiers such as PAN or CIN. Once a case is confirmed as belonging to a specific party, Claw’s case management layer can track it going forward across its coverage of 8,200 plus courts, including tribunals and district courts, so the confirmed identity does not have to be re-established each time the matter resurfaces.
08Frequently asked questions
What is entity matching in litigation search?
Entity matching, also called entity resolution, is the process of deciding whether two records that carry the same or a similar name are about the same real-world person or company, or about two unrelated parties who happen to share a name. Every litigation search tool makes this decision implicitly whenever it returns results for a party name.
What is a name collision in Indian court records?
A name collision happens when a search returns a record that matches the name you typed but belongs to a completely different, unrelated person or company. Because millions of Indians share common names, and many companies share generic names, this is a routine occurrence in Indian litigation search, not an edge case.
How is a name collision different from a misspelled name?
A misspelled or variant name is the same entity, recorded under a different spelling. A name collision is a different entity, recorded under the same or a very similar name. The first causes missed results (false negatives) and the second causes wrong results (false positives), and a search process needs to handle both, not just one.
How do you tell two same-named parties apart in Indian court records?
No single field settles it reliably. In practice, reviewers combine whatever contextual signals are available, such as a father’s or husband’s name, an address, a company’s CIN, a director’s DIN, or details of the case itself like the opposing party, the court, and the date, to judge whether records plausibly belong to the same entity.
Why does this matter for banks and due diligence teams?
A litigation screen that cannot separate a loan applicant or a director from unrelated same-named individuals can wrongly flag a clean party or, just as seriously, bury a real case in a long list of unrelated results. Both outcomes carry real cost, which is why entity matching quality matters as much as raw search coverage in due diligence work.
Can search technology fully automate entity matching?
Not reliably, at least not without human review. Because the signals available in Indian court records are incomplete, fully automatic identity resolution risks getting it wrong in either direction. The safer approach is a search tool that casts a wide net, surfaces enough case detail for a person to confirm identity, and lets a trained reviewer make the final call.