One pipeline, one source of truth

The model decides:

• which filing supplies the row structure
• how presentation and calculation linkbases become an indented hierarchy
• which amount wins after a restatement (the most recently filed)
• how dimensional facts (segments, geography, products) attach to their lines

No value is scraped, estimated, or re-keyed. Python only renders.

Two features that make it trustworthy, not just convenient

Option 1: the most recent 10-K defines the rows

Adopt the labels, order and hierarchy of the latest annual report; fill backward.
It's what a reader of the current 10-K expects, and what open10k does by default.

But:

• a line presented for years and then discontinued disappears, with its amounts
• a line retagged in earlier years shows a truncated history, unless substitution catches it
• a blank early cell usually means "reported under another element," not "not reported"

Breakdowns that don't add up

Listing every disaggregation under a line was unreadable: Apple's Net sales carried 5 segments, 3 countries and 6 product categories in one list.

Group by axis instead. But a group is only honest if it partitions its parent line.

Rule: show a group if its members sum to the parent in ≥ half the years; blank its members in years they don't.
A group that sums to one member nests under it (iPhone, iPad, Mac, Wearables → Products).

Option 2: the union of every line ever presented

For ten large registrants:

The naive union is mostly repetition. Of 935 extra line items:

What still breaks, and the road not taken

The imperfections are the lesson

Any registrant, every XBRL year, in the application students already use. No subscription, no login.

• structure A discontinued line, a renamed line, a blank early year: each is a question about ASC 606, ASC 842, and managerial presentation choice
• articulation Live footing checks: students verify that the statements tie, and find the rare restatements that leave them untied
• traceability Every column links to its filing on EDGAR: audit a number back to the 10-K
• comparability Put two registrants side by side and you see why analysts standardize, and what's lost when they do (Hoitash & Hoitash 2018)

Planned: ratio analysis on as-filed data, footing exercises, tracing one line through a change in standard.

Statements an LLM can read from a URL

• No upload, no table parsing: the statements ride inside the HTML as structured data
• Exact amounts, a source filing for every year, and the page flags its own inferences

Planned evaluation: question sets over the pages (amounts, multi-year ratios, explaining substitutions and breaks), scored against workbook values, with and without the JSON.
Open questions: page size vs. context limits, and whether models respect as-filed caveats or quietly standardize.

A step toward, not an instance of, standardized data

open10k is deliberately not standardized: two workbooks side by side are not a panel.

But it removes most of the work between raw XBRL and standardization:
stable row identity across years · retagging linked with evidence · breakdowns only when they partition · every statement verified

What's left is concept identity: when are two line items the same economic thing?

Contributions

1. A free, open pipeline and site: as-filed, multi-year statements for 8,000+ registrants, with visible concept substitution and built-in arithmetic checks
2. Evidence on structure: the costs of the most-recent-report layout, the redundancy of a naive union, the limits of a calculation union, and an articulation rule for breakdowns
3. A design for financial statements LLMs can read from a URL
4. Standardization reframed as concept identity, with two routes and the baseline each must exceed

References