Search SEC EDGAR’s company database for “apple” and you get 170 registrants. Not 170 filings. 170 distinct legal entities, each with its own CIK.
Ask GLEIF, the global LEI registry, for legal entities whose name contains “Apple” and you get 368 more, across 47 countries, 138 of them in the United States.
Both of those are small numbers. EDGAR only contains entities that register securities with the SEC. GLEIF only contains entities that voluntarily obtained an LEI, which is somewhere under 1% of the world’s legal entities. Neither includes the ordinary LLC that filed with a Secretary of State last Tuesday. The real population of businesses called Apple something is far larger than either list, and nobody has counted it.
Now imagine a row in your CRM that says Apple. Which one is it?
What is actually in the list
The 170 EDGAR registrants are not near-duplicates of the company in Cupertino. They are genuinely different things, and they fail in four distinct ways.
A family of siblings with sequential names. Nine separate registrants, every one of them real:
| Registrant | CIK | State | SIC |
|---|---|---|---|
| Apple REIT Six | 0001277151 | VA | 6798 |
| Apple REIT Seven | 0001329011 | VA | 6798 |
| Apple REIT Eight | 0001387361 | VA | 6798 |
| Apple REIT Ten | 0001498864 | VA | 6798 |
| Apple Hospitality Two | 0001132747 | VA | 6798 |
| Apple Hospitality Five | 0001191813 | VA | 6798 |
| Apple Hospitality REIT | 0001418121 | VA | 6798 |
| Apple Residential Income Trust | 0001021351 | VA | 6798 |
| Apple Suites | 0001084681 | VA | 6798 |
Read down the last two columns. Every attribute you would normally reach for to break a tie is identical across the set. The only thing distinguishing these companies is the number in the name, which is the part string similarity treats as noise.
Natural persons. Of the 170, 32 carry no corporate suffix at all. Most are individuals whose surname is Apple, filing as officers, directors or beneficial owners. EDGAR stores them in the same namespace as the companies. A matcher that scores name similarity cannot tell you that one of its candidates is not an organization.
Entities that used to be called Apple and are not anymore. Three examples from the same search, each verified against the SEC’s own former-name records:
| Current name | Former name | CIK |
|---|---|---|
| AVADO BRANDS INC | APPLE SOUTH INC | 0000849101 |
| GENFINITY CORP | APPLE HOMES CORP INC | 0000934330 |
| Questrust Ventures Inc. | Apple Run Acquisition Corp | 0001586355 |
They appear in an “apple” search because EDGAR indexes former names. Your database probably does not.
Entities that merely start with the same letters. Past the first hundred results the list fills with Appleby, Applegate, AppleCare and Appleby Telecommunications. Substring matching cannot tell a name from a prefix.
And the entity you probably meant, Apple Inc. at CIK 0000320193, has three former names of its own: APPLE INC, APPLE COMPUTER INC, and APPLE COMPUTER INC/ FA. One company, four strings, one identity.
A worked example: “Apple REIT Nine”
A row arrives that reads Apple REIT Nine. It came from a 2013 vendor file, or an analyst’s spreadsheet, or a decade-old contract. Here is what each approach returns.
All four are real, active, Virginia hotel REITs. All four are the wrong company, and all four score well.
CIK 0001418121. Named Apple REIT Nine, Inc. from 15 Nov 2007 to 28 Feb 2014.
The middle lane is the one that should worry you. Exact match fails loudly: you get nothing, and you can see that you got nothing. Fuzzy match fails quietly. It hands back a real, active, correctly spelled company that happens to be the wrong one, with a score that clears a normal threshold.
Not the miss, which you can see. The confident substitution of one real entity for another, which you cannot.
Getting to the right answer needs three things a similarity score does not encode:
- Names have histories.
- Those histories have dates.
- The right record is the one whose former name matches your input exactly, while its current name does not resemble it.
That last point inverts the ranking. The correct answer scores lower on string similarity than all four errors. Similarity does not merely fail to find the answer here. It sorts the answer below the mistakes.
Context is what actually breaks the tie
Nothing about the string Apple will ever disambiguate it, because the ambiguity is not in the string. It is in the world.
What does disambiguate is context, and in practice context arrives as messy free text rather than as clean fields.
The SEC publishes an industry code for each registrant that declares one. Across the Apple-named set those codes span 13 distinct industries, and reading them is the fastest way to see how far apart these companies are:
- Electronic computers
- Real estate investment trusts
- Eating places
- Prepackaged software
- Mobile home dealers
- Insurance agents and brokers
- Health services
- Laboratory analytical instruments
- Converted paper products
- Canned and frozen food
- Blank checks
A single word about what the business does collapses 170 candidates to a handful. That word is almost never in the name.
Applealone: 170 candidates, no basis to choose.Apple, Cupertino: one candidate. Location did it.Apple, hotels: nine candidates, all Virginia REITs. Better, not resolved.Apple REIT Nine, 2013 vendor list: one candidate, and only because the date range on a former name makes it decidable.
That last one is the point. The disambiguating signal was a date, sitting in a sentence next to the name, in a format no schema anticipated. You cannot require the caller to hand you a jurisdiction code and an industry classification, because if they had those they would not need to resolve anything.
What it takes to resolve instead of guess
Reading the problem back, a system that gets Apple REIT Nine right has to do four things that a similarity score cannot.
Read unstructured context. The signal is a phrase, a city, a date, a line of a contract. It has to be interpreted, not parsed.
Carry name history with dates. An entity is the same legal person before and after a rename. A resolver that treats the current name as the identity will split one entity into two and miss the third.
Go and look when the answer is not in the index. Most businesses are not in EDGAR or GLEIF. They are in a state registry, a filing, a document. If the resolver can only rank rows it already holds, then everything outside the index is permanently unresolvable, and that is where the long tail lives.
Decline. Sometimes Apple really is undecidable, and the honest output is a shortlist plus the specific fact that would settle it, rather than a number that looks like confidence.
Notice that all four are things a person does. Which is exactly how this has been solved until now.
The part nobody puts in the pipeline diagram
Apple REIT Nine is the easy version of this problem. It is a company that registered securities with the SEC, so its name history is published, dated and free to query. Most businesses are nothing like that: no filings, a name that exists in one state registry and nowhere else, a web presence of three pages. There is no former-names index to look them up in.
For those, fuzzy matching does not return a wrong answer. It returns nothing, because there is nothing in the index to match against. So the work goes to a person, who opens a browser, reads a registry page, checks an address against a filing, and types the answer into a spreadsheet at a few minutes each. That queue is where the cost is, and it is also where the value is, because the businesses that resolve automatically are the ones you least needed help with.
Research agents are interesting for exactly that reason. Not because they score names better than a string metric, but because they do what the person was doing: read the context, go and look, weigh what corroborates, decide, and show the evidence.
Given Apple REIT Nine, that is what our resolver returns: Apple Hospitality REIT, Inc. Not a similarity score. An answer, and the record it came from.
Ready to try it? Start with free API keys or explore the entity resolution API.