If you have ever tried to join a list of companies to their SEC filings, you have
probably done it on the ticker, and you have probably had it go wrong. EDGAR does not think in
tickers. It thinks in CIKs, and once you see the shape of the data the reason becomes obvious.
What a CIK is
The Central Index Key is a number the SEC assigns to every filer: companies, funds, and the
individual officers who file Form 4s. It is zero padded to ten digits, it never changes, and it
survives everything a ticker does not survive. A company can rename itself, move from Nasdaq to
NYSE, get acquired, or drop off an exchange entirely, and its CIK is still the same number it
was in 1993. Apple is 0000320193 and has been for as long as EDGAR has existed.
Tickers do none of that. They get recycled between unrelated companies, they differ per
exchange, and a company can carry several at once. That is why the filing index published at
reapx.dev is keyed on the CIK rather than on
anything friendlier: it is the only identifier in the payload that is guaranteed to be stable
and unique.
What one row contains
A row is one filing, not one company. Across a sample of 2,691 filing rows I pulled from the
published mirror, those rows resolve to 674 distinct companies, which is the first thing that
surprises people: the average company in the set has filed roughly four times in the window.
Each row carries the accession number, the form type, the filing date and acceptance timestamp,
the direct document URL and the index URL, the fiscal year end, the entity type, the SIC code
with its description, the state of incorporation, the exchange, and a flag for whether the
filing is XBRL tagged.
The distribution of form types in that sample looks like this:
| form | rows |
|---|---|
| 10-K | 854 |
| 10-Q | 829 |
| 8-K | 380 |
| 4 | 200 |
| 10-K/A | 110 |
| 424B4 | 60 |
| SCHEDULE 13D/A | 55 |
| SD | 51 |
The thing you can answer that you could not before
Two questions become cheap once the data is keyed this way.
The first is incorporation. Of those 2,691 filings, 1,422 come from companies incorporated in
Delaware. Nevada is a distant second at 168, then Washington at 137, California at 129 and
Maryland at 123. That Delaware figure is not a surprise to anyone who works in corporate law,
but having it as a column you can group by, rather than a fact you have read somewhere, is the
difference between an anecdote and a filter.
The second is machine readability. 2,261 of the filings are XBRL tagged and 430 are not. If you
are building anything that parses financials, that ratio tells you how much of your pipeline has
to handle unstructured documents, and the isXBRL flag lets you route the two cases differently
before you download anything.
Sector concentration falls out of the SIC code the same way. In this sample the heaviest codes
are 3674 (Semiconductors and Related Devices) with 241 filings, 7372 (Services-Prepackaged
Software) with 187, 6798 (Real Estate Investment Trusts) with 161, 7370 (Services-Computer
Programming, Data Processing) with 157, and 2836 (Biological Products) with 136.
A worked example
Apple's page is at
https://reapx.dev/data/sec-edgar-scraper/0000320193/. It holds 114 observations gathered across
12 separate runs, and the form types stacked up on that one page are 10-K, 10-Q, 4, 8-K,
DEF 14A, SC 13G/A and SD. The most recent row on it when I checked reads:
accessionNumber 0000320193-26-000020
formType 10-Q
filingDate 2026-07-31
entityType operating
exchange Nasdaq
fileNumber 001-36743
fiscalYearEnd 0926
That fiscalYearEnd of 0926 is worth pausing on. Apple's fiscal year ends in late September,
not December, so any year-over-year comparison that assumes a calendar year will silently
misalign its quarters. The field is right there in the row, which means you can catch it before
you build the comparison rather than after.
For contrast, JPMorgan Chase sits at
https://reapx.dev/data/sec-edgar-scraper/0000019617/ with 20 observations across 6 runs. Same
schema, different filer, and the CIK is what lets you put them side by side without a lookup
table in the middle.
Where the numbers come from
Every page in that index is built from real runs and names the run ids that produced it, so any
figure above can be traced back to the run that returned it. Nothing is estimated and nothing is
modelled. If you want the whole set rather than one filer at a time, the source is mirrored as a
dataset on the Hugging Face Hub at
https://huggingface.co/datasets/reapxdev/sec-edgar-scraper, and the full index of filer pages
is at https://reapx.dev/data/sec-edgar-scraper/.
One last practical note: there were zero cases in this sample of a single CIK carrying more than
one ticker. That is a property of the window, not a law, and it is exactly the kind of assumption
worth re-checking against your own slice before you rely on it.
Top comments (0)