Company Database in CSV: Free Sources, Entity Resolution, and Cross-Source Company Masters

Everyone needs a company table eventually — for CRM enrichment, TAM analysis, KYB checks, or as the spine that joins every other dataset you own. The instinct is to search “company database csv download” and hope for one clean file. The truth: excellent free sources exist, each covering a different slice of the company universe with a different identifier, and the genuinely hard, genuinely valuable work is resolving them into one entity. This guide covers the free sources worth using and what cross-source resolution involves.

The free sources that are actually good

SEC EDGAR company data. Every SEC filer with CIK, name, ticker, address, SIC code, as a free JSON/bulk download. Authoritative for US public companies (~8,000 active filers plus historical) — a tiny but high-value slice.

GLEIF LEI. The Legal Entity Identifier database: ~2.7M entities globally with verified legal names, addresses and corporate hierarchy (who owns whom) — free bulk download, genuinely open (CC0). Best free source for regulated/financial entities; sparse for ordinary SMBs.

import pandas as pd

# GLEIF golden copy (CSV, ~2.7M entities) — daily file, ~400MB
lei = pd.read_csv(
    "gleif-goldencopy-lei2.csv",
    usecols=["LEI", "Entity.LegalName", "Entity.LegalAddress.Country", "Entity.EntityStatus"],
)
us_active = lei[
    (lei["Entity.LegalAddress.Country"] == "US") & (lei["Entity.EntityStatus"] == "ACTIVE")
]
print(len(us_active))

UK Companies House. The best national registry: every UK company, officers, filings, free bulk snapshot and API. If only every country did this. US equivalents are 50 state registries of wildly varying openness (some free bulk, some $500/quarter, some nothing).

Aggregated open corpora. OpenCorporates (largest registry aggregation; API/licensing for commercial use), plus research corpora of varying staleness.

Why one clean file doesn’t exist

Each source keys differently: CIK (SEC), LEI (GLEIF), company number (Companies House), DUNS/UEI (US contracting), plain names (everything else). The same real-world company appears in five sources under six name spellings with zero shared keys. Merging them is entity resolution — normalization, blocking, match scoring, transitive merge decisions — and it’s where most internal “company master” projects quietly die:

• Name matching at scale produces both false merges (“Apple Inc” / “Apple Bank”) and false splits (subsidiaries, DBAs, renames).
• Every downstream analysis inherits your merge errors invisibly.
• Sources update on different cadences, so resolution is a pipeline, not a project.

Our Company360 master is that pipeline’s output: 3,774,207 resolved companies (full edition) linking SEC filers, patent assignees, government contractors, hiring activity and technology signals, with a crosswalk table (CIK ↔ patent assignee IDs ↔ contractor IDs) so you can audit and extend every link. The S/M editions (139,791 / 185,474 companies) restrict to entities verified by ≥2 independent sources — the high-precision core.

Once you have a spine, cross-domain questions become trivial joins:

-- Companies that patent AND win federal contracts AND are hiring for AI
SELECT c.company_name,
       c.patent_count_5y,
       c.contract_awards_usd_3y,
       h.ai_openings_180d
FROM company_master c
JOIN hiring_signals h USING (company_id)
WHERE c.patent_count_5y > 10
  AND c.contract_awards_usd_3y > 1e7
  AND h.ai_openings_180d >= 3
ORDER BY c.contract_awards_usd_3y DESC;

That query is impossible across raw sources — it is the product.

Entity resolution in practice: what “good” looks like

If you do build resolution yourself — a reasonable choice at modest scale — here’s the shape of a defensible pipeline, so you can budget honestly. Normalization first: legal-form stripping (“Inc”, “LLC”, “GmbH”, “K.K.” — a per-country suffix table), punctuation and case folding, and careful handling of meaningful tokens (“General Motors” vs “General Dynamics” must not collide after aggressive stemming). Blocking second: you cannot compare 4M × 4M pairs, so you bucket by normalized-name prefix, phonetic key, or geography and only compare within buckets — every blocking choice trades recall for tractability, and you should measure what you’re losing on a labeled sample. Scoring third: string similarity (Jaro-Winkler beats plain Levenshtein on company names) plus corroborating fields — shared address, shared officers, shared website domain — combined into a match score with thresholds you validate against a hand-labeled pair set of at least a few hundred examples. Merge decisions last, and this is the part everyone under-designs: matches are pairwise but entities are clusters, so you need transitive-closure rules with guardrails (two strong pairwise matches can chain into one absurd cluster), plus a persistent entity ID scheme that survives re-runs — otherwise every refresh reshuffles your IDs and breaks every downstream join.

A hand-labeled evaluation set is the non-negotiable piece: without measured precision/recall, you have a script, not a resolver. This is also what to demand from any vendor (including us): our datasheet reports the verification tiers and per-source match methodology, and the crosswalk table exposes raw source IDs so you can audit any merge we made.

What people build on a company master

• CRM enrichment and dedup. Match your accounts against a resolved universe; kill the duplicate-account plague at the root.
• TAM/market sizing. Count and segment actual companies rather than extrapolating from a vendor’s opaque universe.
• KYB and risk. Registry-verified existence plus cross-source corroboration (an entity seen in SEC + contracts + patents is not a shell).
• Signal stacking. The pattern above: innovation (patents) × government revenue (contracts) × momentum (hiring) — each public, each covered by our other lines (patents, contracts, hiring signals).

One architectural recommendation regardless of source: treat your company master as a slowly changing dimension, not a flat table. Keep effective-dated rows (this name, this address, verified by this source, from date X), and resolve “current state” in a view. It costs one extra column set and buys you the two things flat tables can never give back — the ability to reproduce any historical analysis exactly, and the ability to audit why an entity looked the way it did when a downstream decision was made. Every mature data team arrives at this design eventually; arriving before the first backfill crisis is cheaper.

Free sources vs. a resolved master

	Free sources (EDGAR/GLEIF/CH)	DataForge Company360
Cost	Free	From $199 (approval-gated)
Coverage	Per-source slices	3.77M companies, cross-source (full edition)
Identifiers	One per source, no crosswalk	Crosswalk: CIK ↔ assignee ↔ contractor IDs
Resolution	Yours to build	Done, with ≥2-source verification tiers
Signals	None	Patents, contracts, hiring, tech signals attached
Maintenance	Per-source pipelines	Refreshed editions

Honest guidance: need US public companies only? EDGAR’s free file ends the conversation. Need UK? Companies House. Need financial entities with hierarchy? GLEIF. The master earns its price when your question spans sources — which is most commercial questions about private US companies. Access is approval-gated (it’s a B2B line); start from the dataset page.

FAQ

Why is access approval-gated? Cross-source company data has license obligations per upstream source; we review intended use to keep every delivery within them. Same-day review in most cases.

Is this scraped LinkedIn/website data? No. Every source is an official registry or disclosure corpus (SEC, USPTO, procurement portals, public ATS postings). Provenance per field is in the datasheet.

How do you handle subsidiaries? Resolution targets the operating-entity level with parent links where sources disclose them (GLEIF hierarchy, SEC subsidiaries exhibits). The crosswalk preserves raw source IDs so you can re-aggregate differently.

How does this compare to Clearbit, ZoomInfo or Apollo? Different animals for different jobs. Sales-intelligence vendors optimize for contactability: emails, phones, org charts, refreshed continuously, priced per seat with strict no-warehouse terms. A company master optimizes for analytical spine: stable IDs, source crosswalks, verifiable provenance, delivered as data you own and can join freely. Trying to run TAM analysis on seat-licensed contact data violates most vendor contracts; trying to run outbound from a company master means you still need contact data. Many teams run both, with the master as the deduplication and segmentation layer underneath the contact vendor.

What’s the practical difference between DUNS, LEI, and UEI? Three identifier regimes solving the same problem for different masters. DUNS is Dun & Bradstreet’s proprietary number — historically the US federal contractor key, still the private-sector default, licensed not open. UEI replaced DUNS for US government contracting in 2022 (SAM.gov issues it free — one of the quiet wins for open data). LEI is the open, globally-governed identifier for financial-market entities — verifiable and free, but coverage skews to entities that touch regulated finance. No single one covers “all companies”; that’s precisely why crosswalks are the load-bearing artifact in any serious company master.

How often does company data go stale? Faster than most buyers budget for: several percent of businesses close annually, and renames, relocations and acquisitions add more churn on top. Two consequences: any snapshot older than a year should be assumed measurably degraded, and verification recency (when did a source last confirm this entity?) belongs in the schema, not just in marketing. Our master carries per-source observation dates so you can filter to your own freshness bar.

Match rate against my CRM? Depends on your market mix; the S/M tiers’ ≥2-source verification means high precision on matches. Test with the sample and your own top-500 accounts before buying up.