Same owner, different LLC: anyone else running into this on old lists?

Question

Working through some old dialer data and kept noticing the same owner showing up as separate leads across different pulls, just filed under slightly different LLCs or spellings. Trying to get my hands on a real retired list, 5 to 10K records, ideally one that built up over multiple campaigns rather than one clean pull, to dig into this more. Anyone have something like that, or know who might? I would be very grateful. Thank you.

Michael Eskenasy · Answer

What you’re seeing is less a “bad list” problem than an entity-resolution problem.

The same beneficial owner can show up as ABC Holdings LLC, ABC Holdings, LLC, ABC Property Group, a personal name, a spouse’s name, or another entity that shares the same mailing address. If you treat each record as a unique lead, you end up dialing the same economic owner multiple times and your list looks much bigger than it really is.

Before hunting for a retired 10K-record list, I’d actually build the matching logic on the data you already have. Normalize LLC names, strip punctuation and suffix variations, standardize mailing addresses, then look for repeated phone numbers, mailing addresses, registered-agent information, and owner/officer names from public records.

The useful part is not just deduping. It’s building an “owner cluster.” One owner might control six properties through four LLCs. That is a much more valuable piece of information than six disconnected lead records because now you can see portfolio behavior instead of just property behavior.

I’d also be careful about over-merging. Two LLCs sharing a registered agent or attorney does not mean they share an owner. Same thing with common mailing addresses used by accountants or management companies. I’d want multiple matching signals before I treated two records as the same person.

A dirty historical list is actually useful for testing this because it exposes spelling drift, old entities, changed phone numbers, and duplicate pulls. But I’d probably anonymize it if someone shares one. You don’t need somebody else’s old personal contact data to validate the matching logic.

The real edge isn’t getting a giant retired list. It’s being able to take ordinary public-record and campaign data and recognize that 8,000 “leads” may actually represent 5,200 owners, with a few hundred of those owners controlling multiple properties.

That’s where the list starts becoming intelligence instead of just rows.

Rajiv Thapa · Answer

Appreciate the breakdown, especially separating the two mechanisms. That distinction matters more than people usually give it credit for.

On the mailing address dedup, I've actually run into a wrinkle with that exact approach. Anytime the address lands on a registered agent service, a property manager, or an attorney handling closings, you get one address that a few thousand completely unrelated owners route through. Cluster on that and you've merged strangers instead of separating duplicates, just a different flavor of the same problem you're describing with name variants.

Curious how you've handled that in practice. Do you filter known registered agent addresses out before clustering, or is there a signal you use to tell "this address converges because it's one owner's LLCs" apart from "this address converges because it's a formation service"? Feels like the kind of thing that only shows up once you're running this at real volume.

Jason Reed · Answer

Yeah, you're right, and I went and looked at my own data after you asked instead of guessing.

The collision is real but it wasn't mostly registered agents for me. Pulling all of Hillsborough (~500k parcels), the addresses that soak up the most owners were institutional landlords and government. One PO box in Scottsdale had 3,187 parcels under a pile of Progress Residential borrower LLCs. A Dallas suite had 2,790 Invitation Homes entities. Those are actually one owner so the clustering isn't wrong, they're just not leads.

Government was the bigger mess. A county real estate department had 3,064 parcels, DOT had 1,266. I found the county board of commissioners sitting at 4,351 parcels getting scored as a "portfolio owner" in my own output, which is exactly the failure you're describing and I hadn't caught it.

Closest thing to what you're talking about was a "c/o Ryan LLC" address with 2,094 parcels across a bunch of unrelated SFR funds. That's a property tax service, and those are genuine bad merges.

The thing that separated them for me was just the count. An actual local guy holding LLCs for liability has maybe 5 to 40 parcels at one address. Past that you're looking at an intermediary or an institution. I capped mine to that range and it knocked out 266 of 759 flagged portfolio owners, basically all institutions and government.

Michael's point about officer names is where I'd go next. Sunbiz gives you the registered agent and officers for any FL LLC for free and that collapses a lot of variants a name match would miss. Only thing I'd push back on is using registered agent as a match key, that's the exact field you're describing, one agent covers thousands of unrelated companies. Officers are the useful part, agent isn't.

One other thing, I track whether these owners actually resolve the foreclosure before the sale and portfolio owners come in below baseline, worse the bigger the address gets. Makes sense, institutions just let it go, they're not negotiating with you. Small sample so far so take that lightly.

Probably only shows up once you're pulling whole counties, which is why the aged list wouldn't have told you either way.

Brolty Lawn · Answer

Late to this, but the officer angle Michael mentioned is where I landed too — and there's a shortcut that made it practical.

You don't have to scrape Sunbiz one company at a time. Florida publishes the whole corporate registry as a bulk download, every entity and every officer. I

pulled it into a local SQLite file — about 12.8 million entities and 20.9 million officer rows. Once it's on disk, going from "123 Main LLC" to the actual

humans on the filing is a millisecond lookup instead of a scrape that gets rate-limited by lunchtime. That's what made clustering on people instead of entity

names doable at county scale.

So the chain is parcel → owner string → entity → officers, and you cluster on the officer. Not the LLC name, not the mailing address.

The trap is that officer names over-merge exactly the way mailing addresses do. First time I turned it on, one of my own LLCs had a manager with a fairly

common name and it cheerfully pulled in a few dozen unrelated people who happened to share it. Same failure as the registered agent problem, just a different

field.

What fixed it was refusing to merge on one signal. An officer match is a candidate, not a match — I want a second independent fact before two records

collapse: shared mailing address, entities filed in the same window, an actual recorded document tying them together. One fact and it stays flagged as

"probably, go look." Two and it merges. A confidently wrong merge costs me a lot more than a missed one.

Anyway, I've got most of this automated at this point. Happy to walk anyone through how it's wired if it's useful.

Jason Reed · Answer

That "same owner across different LLCs" thing is one of the most under-appreciated sources of dirty list data. Two things are usually happening: real investors/landlords hold properties in separate LLCs on purpose (liability), so one human owner legitimately shows up as several entities, and on top of that, list vendors don't do entity resolution, so spelling variants ("123 Main LLC" vs "123 Main, L.L.C.") get counted as different leads. The fix that's worked for me is to stop deduping on owner name and dedup on the mailing address instead. The tax-billing address is where all an owner's LLCs usually converge, so clustering by that collapses the duplicates and, as a bonus, surfaces your true portfolio owners (multiple hits on one mailing address = someone worth a personalized call). For studying decay, an aged list stacked across campaigns is the right idea, but you'll learn more building it yourself from repeated county pulls than buying someone's, you'll see the same owners move and refile in real time.

Igor Ganapolsky · Answer

This is a great thread — the entity-resolution work Michael, Jason, and Brolty are describing is real and necessary if you're working recycled dialer data. But I want to push back on the premise a little: the reason you're spending hours building dedup logic and SQLite databases is because everyone's working the same recycled lists from the same 3-4 providers (PropStream, ListSource, BatchLeads). The lists are worked to death by every wholesaler in market, then sold again as "fresh" pulls, and you end up doing forensic data science just to figure out which of your 10K leads are actually the same person.What if the list itself wasn't recycled?County tax deed auctions publish a fresh list every year — these are specific parcels where the owner fell 1-3+ years behind on property taxes, the county went through the entire legal process (court filings, legal notices, hearings), and now the county is selling the deed at auction. The list is public record: parcel number, owner name of record, tax debt amount, property address. No entity resolution needed because you're not dialing 10K names — you're researching 20-30 specific parcels with named motivation (couldn't or didn't pay taxes for years).The data quality is structurally different: the county already did the work of identifying the most motivated sellers. They sent the legal notices. They ran the process. They set the auction date. The list is clean by design — one parcel, one tax debt, one owner of record. No LLC spelling variants because the county assessor already resolved that when they billed the taxes. No recycled leads because the list resets every auction cycle.For someone with your data skills, Rajiv, the play isn't building better dedup on a PropStream pull — it's pulling the tax deed list directly from the county (free), cross-referencing the Property Appraiser for market values (free), and identifying the biggest spreads between tax debt and ARV. That's your short list. Then you find cash buyers who want those specific properties. You're not competing with 50 other wholesalers on the same worked-over list — you're working a list most wholesalers don't even know exists.The entity-resolution problem goes away entirely when your lead source isn't a recycled commercial list.

Rajiv Thapa · Answer

This whole thread is exactly the kind of thing I was hoping to run into here. Appreciate all three of you taking the time.

Michael, the owner-cluster framing is spot on, and Jason, seeing you actually go pull your own numbers to check it made this a lot more useful than it would've been as theory. The hub-address pattern you found (Progress Residential, Invitation Homes, a county government department scoring as a "portfolio owner") is almost exactly what I ran into on a large municipal dataset I was testing against. Same mechanism, different flavor. A handful of high-frequency address and name tokens ended up pulling tens of thousands of unrelated records into one giant cluster before I caught it. Cost me a fair bit of time to untangle, so seeing your 5 to 40 parcel range as a rough sanity check is genuinely useful, I'll be stealing that.

Brolty, the officer-match-as-candidate-not-match rule is the exact lesson I learned the hard way, just from a different angle. My mistake was letting the clustering step act as the decision maker instead of treating it as a dumb aggregator sitting downstream of the actual judgment calls. Once I separated "is this a candidate worth looking at" from "should this actually merge," the false merges mostly went away. Sounds like you landed on the same principle from the officer-name side.

Curious how you're handling the human side of this once you're past the automated matching. Are you reviewing flagged candidates yourself, or is any of this getting handed off to someone else to eyeball before it's treated as confirmed?

Same owner, different LLC: anyone else running into this on old lists?

Most Popular Reply