Corporate-Family Resolution Is Not a String-Matching Problem: A Public Benchmark Stratified by Name Visibility

Harshit Gupta

cs.DBSep 2, 2026

Corporate-Family Resolution Is Not a String-Matching Problem: A Public Benchmark Stratified by Name Visibility

Authors: Harshit Gupta

Organizations: Independent Researcher

Abstract

Deciding whether two supplier records belong to the same corporate family is a prerequisite for spend consolidation, credit exposure aggregation and sanctions screening. It is usually treated as entity matching, but the tasks differ: a family link connects records that are deliberately different entities, and the evidence often appears in neither record. We introduce CorpFam, a public benchmark of 54,864 candidate pairs over 10,307 corporate families, derived from 6,638,350 US federal award records in which every supplier self-reports its ultimate parent to a government registry. Pairs are stratified by name visibility: whether the names are identical after normalisation, share a distinctive token, or share none. Because strata have positive rates from 10.2% to 97.3%, we report per-stratum recall, base-rate invariant, rather than F1, which is not. The strongest of 5 matchers recovers 100.0% of identical pairs and 4.2% of invisible ones; no method exceeds 4.7% on the latter. The failure begins before matching. Blocking decides which pairs a matcher sees, and we evaluate 7 schemes spanning phonetic keys, attribute keys that ignore the name, and semantic nearest neighbours. None reaches three percent on invisible pairs, and their union recovers 6.8%. 93.2% of these links never enter the candidate set, so no matching-stage improvement can reach them. The links are real: against SEC Exhibit 21 subsidiary schedules, which share no provenance with procurement registration, 64.2% of invisible links are corroborated, against 0.16% under permuted parents and 0.41% against the same parent's wrong exhibit: two unrelated nulls agreeing to within 0.25 points. Corporate-family resolution is a retrieval problem misfiled as a matching problem; the intervention point is candidate generation, not ranking. The benchmark, adjudication log, and code reproducing every number are released.

Figures & tables

Stratum	Positive pairs	%
Identical	7,541	55.0
Visible	2,953	21.5
Invisible	3,222	23.5
All positives	13,716	100.0

Table 1: Composition of CorpFam positive pairs by name visibility. Identical pairs share a normalised name, visible pairs share at least one distinctive token, and invisible pairs share none. Negatives are generated at three per positive, giving 54,864 pairs in total.

Agreement criterion	%
Exact parent UEI	64.9
Normalised parent name	73.8
Any shared distinctive token	81.5
Substantively different parent	18.5

Table 2: Agreement between the two independent views of the same ground truth – the per-entity API and the bulk award archive – on the 248 entities where both report a distinct parent. Even the registry disagrees with itself on roughly one link in five, which bounds the accuracy any method can be credited with.

Stratum	Checked	Confirmed	%	95% CI
Identical	172	165	95.9	[91.8, 98.0]
Visible	609	548	90.0	[87.3, 92.1]
Invisible	794	510	64.2	[60.8, 67.5]
All	1,575	1,223	77.7	[75.5, 79.6]
Invisible stratum against null conditions
Wrong parent, right exhibit (20 permutations)	15,795	26	0.16	–

Table 3: Independent corroboration against SEC Exhibit 21 subsidiary schedules over 160 filings. Exhibit 21 is filed under securities law by the parent’s own counsel and shares no provenance with a supplier’s procurement registration. Documents are selected by the exhibit type EDGAR itself declares for each document in the filing, not by matching the filename. The two upper null conditions share no machinery. The permutation holds the document type fixed and randomises the company; the wrong-exhibit row holds the company fixed and substitutes a non-Exhibit 21 document from its own 10-K, chiefly Exhibit 10 material contracts and Exhibit 19 insider-trading policies. They land 0.25 points apart and are statistically indistinguishable, so the floor is a property of the matcher rather than of either construction, and the corroboration signal is specific. Non-confirmation remains weak evidence in the other direction, since Exhibit 21 omits immaterial subsidiaries and its formatting is unregulated.

				Pair completeness by visibility
Blocking scheme	Candidates	PC (%)	RR (%)	Identical	Visible	Invisible
Token blocking †	1,534,063	68.7	99.977	92.22	83.68	0.00
First-token blocking †	636,042	52.9	99.990	78.70	44.80	0.00
Q-gram blocking (q=4)	9,022,384	71.4	99.862	97.83	78.84	2.79
Sorted neighbourhood (w=20)	2,170,180	71.2	99.967	99.95	73.48	2.05
Phonetic (Soundex)	411,063	61.3	99.994	97.32	35.96	0.25

Table 4: Blocking over the full recipient roster, not merely the entities appearing in our pairs file. PC is pair completeness, the recall of true links into the candidate set; RR is reduction ratio. Rows marked † key on the same core() token function that defines the invisible stratum, so their zero recall there is an identity and not a measurement. The informative rows are the others: character q-grams, sorted-neighbourhood adjacency, phonetic keys, attribute keys that ignore the name entirely, and semantic nearest neighbours in an embedding space. None of them exceeds three percent on the invisible stratum, and unioning every scheme still leaves the overwhelming majority of those links outside the candidate set. The failure is therefore a property of candidate generation rather than of any particular key.

			Recall (%) by name visibility
Method	AP	Prec.	Identical	Visible	Invisible
Exact (normalised)	65.4	97.3	100.0	0.0	0.0
Token Jaccard	73.5	91.8	99.2	43.5	0.0
Sequence ratio	74.7	94.7	100.0	15.8	3.8
TF–IDF char 3-gram	78.7	89.6	100.0	49.9	4.2
MiniLM embedding	–	88.6	100.0	64.3	4.7

Table 5: Baselines on the CorpFam test split, with thresholds selected on validation and applied unchanged to test. Recall is reported per stratum rather than

F_{1}

, because the strata have positive rates of roughly 97%, 10% and 17% respectively, so a per-stratum

F_{1}

largely reflects that base rate rather than the method: the final row shows a classifier that answers yes to every pair, which attains perfect recall everywhere and an

F_{1}

ranging from 18 to 99 across strata. Recall depends only on a stratum’s positives and is therefore comparable across them. Average precision is threshold-free and computed over the whole split, since precision depends on the shared negative pool. Every method recovers essentially all identical pairs and almost no invisible ones.

Negative kind	Exact	Jaccard	SeqRatio	TF–IDF	MiniLM
Random	0.0	0.0	0.0	0.0	0.0
Hard string	1.0	3.6	1.6	4.6	6.5
Same block	0.5	2.2	1.7	3.2	2.6

Table 6: False-positive rate (%) by negative kind on the test split. Random negatives are nearly free; the difficulty is concentrated in negatives that share a blocking key or distinctive tokens, which is what a deployed pipeline actually sees after blocking.

	Overall			$F_{1}$ by name visibility
Feature set	P	R	$F_{1}$	Identical	Visible	Invisible
Name features only	79.1	47.6	59.5	96.9	51.3	31.2
Attributes only	40.1	98.4	57.0	96.2	42.6	59.9
Name $+$ attributes	49.5	81.7	61.7	96.9	49.0	58.4
Answer yes to everything	38.6	100.0	55.7	96.9	40.6	59.4
positive rate	38.6	–	–	93.9	25.5	42.2

Table 7: Supervised logistic regression over name and attribute features, evaluated on the subset of test pairs carrying attributes (address, city, state, ZIP, country, phone, doing-business-as name) on both sides. Read every cell against the two floor rows. Each stratum of this subset has its own positive rate, so an

F_{1}

here carries the base rate as much as the model. On the invisible stratum the attribute-only model clears the floor by half a point, and the other two feature sets score below it. Attributes do not rescue the stratum. The deeper obstacle is coverage: attributes exist on both sides for a small minority of pairs, because a parent is frequently a holding entity that never transacts and therefore has no address at all.

Condition	Cands	Pair $F_{1}$	P	R	$F_{1}$	fam. (%)
			B-cubed			Exact
Blocked	5,080	32.2	85.8	45.4	59.3	16.6
Oracle	536,130	39.4	84.3	45.1	58.8	14.9

Table 8: Family-level clustering over the 902 families with two or more children, scored on test with thresholds chosen on validation. Blocked takes candidates from token blocking as in deployment; Oracle scores every within-split pair. Removing blocking raises pairwise

F_{1}

but lowers exact family recovery, because the additional candidates introduce false links that merge distinct families through transitivity. Only a small minority of families are recovered exactly under either condition, and exact recovery is what a spend rollup depends on.

Entity Resolution

Entity resolution links records that refer to the same real-world entity across datasets despite differences in names, attributes, formats, and languages.

See all 40 papers

Entity Resolution in Practice: Lessons from a Self-Serve Pipeline
Jul 28, 2026Kaushik Pavani, Ganga Aluri, Pravin Jadhav +2Entity Resolution
Walmart
OpenSanctions Pairs: Large-Scale Entity Matching with LLMs
Feb 24, 2026Chandler Smith, Magnus Sesodia, Friedrich Lindenberg +1Entity Resolution Entity Linking
University of Oxford · OpenSanctions
Snippet-Driven Supply Chain Discovery with LLMs: Scaling Visibility in China
May 27, 2026Hiroto Fukada, Takayuki MizunoRelation Extraction KG Construction
Graduate Institute for Advanced Studies (SOKENDAI) · National Institute of Informatics · Tokyo, Japan

Jul 28, 2026J/K move · Enter open · S save

Entity Resolution in Practice: Lessons from a Self-Serve Pipeline

Kaushik Pavani, Ganga Aluri, Pravin Jadhav, Neeraj Prasad+1

Walmart

Entity Resolution

Open paper AskPDF arXiv

We built and evaluated a self-serve entity resolution (ER) system on six benchmarks spanning 864 to 5M records, and three lessons emerged that are absent from existing ER literature. (1) No single matching algorithm wins everywhere - a self-serve pipeline cannot predict its next dataset, so we recommend training several algorithm families per dataset and letting an automatic bake-off pick the winner. (2) Precision and recall need separate fixes, not a shared threshold - precision needs hard rule-based vetoes, recall needs more diverse candidate retrieval. (3) One false-positive link can silently merge unrelated entities - assuming "A matches B" and "B matches C" implies "A matches C" lets a single bad link chain hundreds of records together, so every cross-group merge must be actively re-verified. We hope these lessons save practitioners the months of dead-end experiments that led us to them.

Abstract

Entity Resolution

Explore similar work

Entity Resolution in Practice: Lessons from a Self-Serve Pipeline

OpenSanctions Pairs: Large-Scale Entity Matching with LLMs

Snippet-Driven Supply Chain Discovery with LLMs: Scaling Visibility in China