What is entity resolution?

Hand a resolver a file and what comes back is a decision for every row: which real-world entity this record describes. That output is a partition — a set of clusters with a stable identifier on each, rather than a table of similarity scores — so that everything downstream, from a spend total to a credit exposure to a duplicate-supplier count, is computed over the company rather than over the rows.

Two words in that definition do the work. "Real-world" means the target of the decision is a company that exists outside your database, so correctness is checkable against something other than your own data; a resolver that only makes rows agree with each other is a deduplicator, and it can be perfectly self-consistent and completely wrong. "Partition" means the decisions must be mutually consistent: if A is B and B is C, then A is C, whether or not the system ever compared A with C directly. That transitivity is where most of the danger lives, and we come back to it below.

The unit that matters commercially is the entity, not the pair. A system that gets 99 pairwise decisions right out of 100 can still weld two large companies into one record, because a single wrong edge propagates through the transitive closure and takes every record on both sides with it. That is why this site publishes cluster metrics beside every pairwise number and why a vendor who will only show you pairwise precision is showing you the flattering half.

Some of your rows carry a field that settles the question outright, and matching on exact agreement of those fields is deterministic matching. Two records carrying the same company registration number scoped to the same register are the same company; two records carrying the same LEI are the same legal entity. There is no score involved and no threshold to tune, because the register has already done the resolution and the record is quoting its answer.

The value of a deterministic rule is that it is decisive in both directions. Conflicting strong identifiers are as informative as agreeing ones: two records with different, well-formed LEIs are not the same legal entity, and a probabilistic scorer that lets a strong name and address similarity outvote that conflict has a bug rather than an opinion. In our own resolver, conflicting registration numbers, LEIs and DUNS numbers are held at magnitudes large enough that no combination of positive evidence the model can see is able to overcome them, and the magnitude is re-derived and re-checked every time the weights are refitted rather than hand-set once and trusted.

The failure mode of deterministic matching is subtle and it is about scope, not about strings. A registration number is only an identifier when you know which authority issued it. A six-digit number with no register attached will happily collide with a charity reference, a VAT fragment or another country's company number. Getting this wrong produces high-confidence wrong merges, which is the most expensive kind, and it is the commonest defect we see in hand-built matchers.

Fuzzy matching computes a string distance and applies a cut-off. It is a useful component, and it is not a resolver. Four things separate the two, and each of them is a place a fuzzy-match project stalls.

The first is that a similarity score is not a probability. A Jaro-Winkler of 0.92 is not a 92% chance of being the same company; it is a statement about characters. Nothing about it tells you what fraction of pairs scoring 0.92 are true matches, so a threshold on it is a guess dressed as a parameter. Calibration is what turns a score into something you can act on, and fuzzy matchers do not have it.

The second is that fuzzy matching produces pairs, not clusters. Whatever your threshold, you still have to decide what to do when A matches B, B matches C, and A does not match C. Take the transitive closure and you merge companies that never scored against each other. Do not take it, and you have an incoherent partition where the same record belongs to two entities.

The third is that a string comparison has no way to be decisive about a conflict. It cannot say that two records carrying different LEIs are definitely different companies, because it never looked at the LEI as an identifier. So its errors are unbounded in the worst direction: the most similar strings in a company register are precisely the sibling entities you must not merge.

The fourth is that fuzzy matching has no way to abstain. It returns a number for every pair, so the answer to "we cannot tell" is a mid-range score that some downstream consumer will threshold into a decision anyway. A resolver treats "unresolved" as a first-class outcome with its own contract, which is a decision somebody made on purpose rather than a feature nobody built.

A resolver that always answers is not more useful than one that sometimes declines; it is the same resolver with the declines relabelled as guesses. So the design question is what happens to the records whose evidence genuinely will not carry a decision. On our own 317-company fixture the name-plus-country-and-town-prose tier historically resolved 99.37% (315/317, 95% CI [97.7, 99.8]); the two that did not are same-stem company groups, and they came back as a five-candidate shortlist rather than as a guess with a plausible score attached. Historical 2026-08-29 recording with earlier identifier arrivals seeding the catalogue. This does not measure a business description, email footer or generic verification purpose alone. Two same-stem groups remained unresolved.

The truncated name is where this gets concrete. A name cut off by a field-length limit has often lost the tokens that would have discriminated it, and no model recovers information that is not there. That tier resolves 58.10% (61/105) on the same fixture, and the balance abstains with a shortlist. Read that figure next to the 100% (317/317) identifier tier before you read any average: a blend across input shapes tells you nothing about the shape your own file is in.

The corollary is that a match rate quoted without an abstention rate is unreadable. So is the reverse — perfect precision at zero automation is trivially achievable by never deciding anything. Our continuous-integration gate reports 1.0000 precision on 357/357 automated merges and an automation rate of 63.10% in the same table, because either figure alone is a different and much weaker claim.