Practical guides for working with SEC filings, market data and financial statements — with runnable code.
Download, parse, monitor and analyze EDGAR filings at scale — rate limits, sections, exhibits, RAG pipelines, 8-K alerts, IPO terms, 20-F/ADR and cybersecurity disclosures.
15 guidesTurn SEC filings into normalized income statements, balance sheets and cash flows via API — XBRL and non-XBRL 6-K/8-K parsing, foreign issuers, validated and reconciled, fresh within minutes — so you do not have to build the parser yourself.
A company reports after the bell and the 8-K hits EDGAR with this quarter's numbers. You reach for the exhibit and discover there is no XBRL — just HTML tables built for a human eye, not a parser.
Earnings hit the wire, the stock moves, and your XBRL pipeline does not see the quarter for another 5 to 40 days because the 10-Q is the late document by design. The number you need is already sitting in an 8-K that filed hours ago.
A company files its 10-Q and your pipeline does not reflect the quarter for hours or days, even though your API responds in milliseconds. The bottleneck was never the request. It is the ingestion that turns a filing into a statement.
You pull revenue for 2 companies to compare them, and the numbers come back under 2 completely different XBRL tags. Now multiply that across every line item, every filer, and every taxonomy year.
Your parser runs, the statements look right, and 3 weeks later a downstream chart is off by an amount nobody can explain. Gross profit does not equal revenue minus cost of revenue. The balance sheet does not balance. The failures are silent, plausible, and entirely catchable.
Your SEC filing downloader works on 3 companies, but point it at 500 and EDGAR blocks your IP — so how do you pull filings at scale without fighting the 10 req/sec wall?
You need to pull Risk Factors from a 10-K in Python, and the regex works on Apple — but how do you extract sections across the S&P 500, where a third of the results come back wrong?
You built a RAG pipeline over SEC filings and the demo went perfectly — then a real user asked about supply-chain risk and the retriever pulled 3 chunks from the table of contents.
Someone asks you to alert the team when a portfolio company files something that matters — and within a day you realize that 90% of what EDGAR sends you is noise.
It is pricing day, you need use of proceeds, dilution and lock-up terms from a 400-page prospectus, and the section you need has no item number to anchor on.
You want to retrieve a particular exhibit from an SEC filing, but how do you do it programmatically, without experiencing IP blocks, and at scale?
You run your 10-K section extractor across a global universe and wonder why Taiwan Semiconductor, Alibaba and Shell are missing — then you realize they file 20-F, not 10-K.
You want to know what changed in a company’s risk disclosures since last year, but your extractor hands you 30 pages of boilerplate and no clean way to diff them.
Every SEC filing is already free on sec.gov, so you start building on raw EDGAR — and 3 weeks later you are maintaining a rate limiter, a parser, and a retry system you never planned for.
You set up monitoring for cybersecurity disclosures in the 10-K and think you are covered — until you realize you are missing every incident filing and every foreign issuer.
You open an XBRL instance document expecting a clean income statement and find 500 tagged facts with no ordering, no subtotals, and no agreement between filers about which tag means “revenue.”
You pull total assets and revenue from the same 10-K, line them up by date, and compute return on assets. The number looks right. It is wrong, because one fact is a snapshot and the other is a flow, and XBRL encoded that difference in a way your parser just ignored.
Your team says it can build an XBRL parser in a sprint. The instance parse is a weekend. The concept map, the operations layer, and the maintenance that follows are not, and nobody ever puts those in the estimate.