How to Parse XBRL into Clean Financial Statements
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.”
Turn 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.
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 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.
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.
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.
You point your scraper at an earnings exhibit and it works perfectly on one company. Then you try the next filer and columns misalign, signs flip, and every value is off by a factor of a million.
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.
Your pipeline handles XBRL perfectly, so it misses every 8-K earnings release and every foreign 6-K interim entirely. You decide to build a parser for them, and the estimate says a sprint. The estimate is wrong, and one of the 2 filings is already parsed for you.
You add TSMC or Toyota to your model and the fundamentals come back empty. The data exists — it just lives in 20-F and 6-K filings that your feed never learned to read.
You add Canadian National or Enbridge to your model and the fundamentals come back empty. The company reports every quarter, the statements are audited and public, but it files a 40-F instead of a 10-K — and your pipeline has never seen that form before.
Your feed covers the S&P 500 perfectly and every spot check passes. Then someone asks for ASML or TSMC and the fundamentals come back empty — not because the data is missing, but because 3 pipeline shortcuts quietly drew the coverage boundary right through the foreign universe.
You write the ticket: "build a financial statements database." Then you start, and you discover that 4 of the 5 ETL stages are the parser — the rate limiter, the XBRL concept map, the non-XBRL interim parser — and the database you actually wanted is the piece you never quite reach.
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 history looked stable. Then a prior year's numbers changed underneath you, a chart that was correct last quarter is now wrong for a period 2 years back, and nobody on your team touched that data. The company restated — and your pipeline was never built for it.