How to Parse SEC 10-K Filings Into Sections for AI Agents
A structure-first workflow for splitting 10-K and 10-Q HTML into titled sections without breaking tables, with NVIDIA FY2026 as a worked example.
How to Parse SEC 10-K and 10-Q Filings Into Small Titled Sections for AI
Table of contents
- Short answer
- What should parsing produce for AI agents and LLMs?
- Why is SEC 10-K and 10-Q HTML hard to parse?
- What is the HTML structure of a 10-K filing?
- Why does fixed-size chunking fail on SEC filings?
- What is the best way to parse SEC filings into sections?
- Worked example: NVIDIA 10-K from flat HTML to a section tree
- How is parsing 10-K different from 10-Q?
- What are common mistakes when parsing SEC filings?
- Which open-source tools help with SEC filing parsing?
- FAQ
- Where to go from here
- Methodology and update context
Short answer
Parsing a SEC 10-K or 10-Q into sections means recovering issuer sub-headings like Our Businesses — not only regulatory Items like Business or Risk Factors — so AI agents and LLMs can read one titled, cohesive unit at a time.
Short answer: The goal of parsing is not merely to locate major Items. It is to split the filing into many small, titled sections — Our Company, Our Businesses, Consolidated Statements of Income — each with its paragraphs and tables attached, so an agent can read one coherent unit at a time, cite it, and fit it in context. In a large-cap 10-K, the <body> alone can contain more than 1,000 sibling <div> blocks (NVIDIA's FY2026 filing has 1,211 top-level children); treating that flat stream with structure-first, style-based parsing — classifying each block, detecting PART/ITEM boundaries and CSS-styled sub-headings, then building a section tree whose leaves are human-scale disclosure units — is what turns an 80-page Item 1 blob into nodes an LLM can actually use.
Why it matters: LLMs and agents do not consume a whole 10-K. They consume passages with titles. In NVIDIA's (NVDA) FY2026 10-K, the sub-section title "Our Businesses" at body index [89] is a sibling <div> to the segment paragraphs at [90]–[92] — not a parent wrapper. If you only split at Item 1 vs Item 1A, you hand the model an enormous undifferentiated block. If you chunk by token count, you separate titles from body text. Both fail for serious filing Q&A.
Practical takeaway: Use structure-first, style-based parsing to recover issuer sub-headings inside each Item, keep tables atomic, and emit titled nodes an agent can target individually — then optionally embed or index at that granularity, not at arbitrary token boundaries.
What should parsing produce for AI agents and LLMs?
Parsing SEC filings is often described as "extracting Business, Risk Factors, and MD&A." That is only the first level of structure. For AI agents, RAG pipelines, and LLM tool calls, the useful output is one level deeper: small sections that each have a title and a bounded body of text or a table.
Think in two layers:
| Layer | What it is | Example (NVIDIA FY2026 10-K) | Useful for |
|---|---|---|---|
| Major boundaries | SEC Part / Item | Item 1. Business, Item 1A. Risk Factors, Item 7. MD&A | Orienting inside the filing; choosing which disclosure regime applies |
| Titled sub-sections | Issuer headings inside an Item | Our Company, Our Businesses, Sales and Marketing | What agents and LLMs actually read — one retrieval unit, one citation, one context window |
Item 1. Business in a large-cap 10-K can run dozens of pages. An agent asked "What segments does NVIDIA report?" does not need all of Item 1 loaded at once. It needs the Our Businesses node — title plus the paragraphs that describe Compute & Networking and Graphics.
The parsing goal, stated for downstream AI:
- Every retrieval unit has a title — not orphaned paragraphs floating in a token chunk.
- Every unit is cohesive — no mid-paragraph or mid-table splits.
- Units are addressable — stable IDs or paths (e.g.
Item 1 > Our Businesses) so an agent can say "read this node" instead of "search the embedding index and hope." - Units are appropriately sized — typically sub-section scale (hundreds to a few thousand tokens), not whole-Item scale (tens of thousands) and not arbitrary 512-token fragments.
Regex-only PART/ITEM splitting gives you layer 1. Style-based structure-first parsing gives you layer 2 — which is what makes filings legible to LLMs.
What many teams build What agents need (NVDA FY2026 10-K)
───────────────────── ───────────────────────────────────
Item 1. Business (80 pp.) Item 1. Business
Item 1A. Risk Factors ├── Our Company (+ paragraphs)
Item 7. MD&A ├── Our Businesses (+ paragraphs)
├── Our Markets (+ paragraphs)
└── Sales and Marketing (+ paragraphs)
Major Items are the map. Titled sub-sections are the destinations — the nodes an LLM reads, cites, and reasons over.
Why is SEC 10-K and 10-Q HTML hard to parse?
A Form 10-K or 10-Q downloaded from SEC EDGAR looks like a single HTML file, but it mixes prose, financial tables, cover-page boilerplate, inline XBRL tags, page breaks, and a table of contents. Parsing that file is harder than finding "Item 1" because the sections inside each Item are what agents need, and those inner titles are not labeled with semantic HTML.
Four properties of EDGAR HTML make that hard:
There are no reliable HTML heading tags
Modern web pages use <h1>–<h3> or <section> elements to encode outline structure. EDGAR issuer HTML typically does not. Issuers render headings as styled <span> text inside plain <div> wrappers. Section titles and body paragraphs often use the same tag name — the difference is inline CSS (font-weight:700, font size, color), not semantic HTML.
In NVIDIA's FY2026 10-K, the sub-section title Our Businesses and the opening paragraph of that section are both <div> wrappers around <span> text. Same tags, different styles: bold green for the title, normal black for the body. There is no <h2>Our Businesses</h2>. A parser that looks for heading elements will not find this boundary; one that reads inline CSS will.
The same section names appear twice
Every substantial 10-K contains a table of contents with Part I, Item 1, Item 1A, and page numbers — and later, the body repeats those same PART/ITEM strings. In NVIDIA's filing, a parser that treats the first "Item 1. Business" it finds as the section boundary will latch onto the TOC table; the real Item 1 body content starts at body index [69].
Structure is visual, not semantic
SEC filings are disclosure documents formatted for human reading on EDGAR, not for DOM-tree traversal. The logical hierarchy (Part → Item → sub-heading → paragraph → table) is expressed through document order and styling, not nested containers.
What is the HTML structure of a 10-K filing?
A 10-K filing's HTML structure is flat: the <body> element contains a long sequence of sibling block-level tags — mostly <div>, plus <hr> page breaks and inline XBRL elements — rather than nested <article> / <section> / <p> hierarchies.
What "flat" means in EDGAR HTML
Structure-first parsers (including sec-parser) begin by collecting direct children of <body>. Each non-empty top-level tag becomes one candidate semantic block. There is typically no enclosing section wrapper around "Item 1. Business" and its paragraphs.
To make this concrete, we analyzed NVIDIA Corporation's Form 10-K for the fiscal year ended January 25, 2026 (accession 0001045810-26-000021). The <body> has 1,211 direct children:
| Top-level tag | Count | Typical role |
|---|---|---|
<div> | 1,048 | Titles, paragraphs, table wrappers |
<hr> | 84 | Page breaks |
<ix:continuation> | 50 | Inline XBRL continuations |
<ix:nonnumeric> | 29 | Standalone XBRL narrative blocks |
There is no HTML5 outline. The filing reads as roughly one thousand consecutive sibling blocks.
Example from a real 10-K: sibling titles and paragraphs
In the body of NVIDIA's filing (not the table of contents), Part I and Item 1 appear as separate top-level divs. So do sub-section titles and the paragraphs that follow them. Each row below is its own <body> child:
| Body index | Bold styling? | Visible text (truncated) |
|---|---|---|
| 67 | yes | Part I |
| 68 | no | (empty spacer) |
| 69 | yes | Item 1. Business |
| 70 | no | (anchor div) |
| 71 | yes | Our Company |
| 72–88 | no | Body paragraphs under Our Company (one div each) |
| 89 | yes | Our Businesses |
| 90 | no | We report our business results in two segments. |
| 91 | no | The Compute & Networking segment includes… |
| 92 | no | The Graphics segment includes GeForce GPUs… |
The critical point for anyone trying to parse SEC filings into LLM-ready sections: "Our Businesses" and the paragraph starting "We report our business results in two segments" are sibling <div> elements. The title does not wrap the paragraph. A DOM tree walk that looks for "text inside the heading's parent" will fail — and an agent that only knows "you are in Item 1" still does not know which sub-section it is reading until this boundary is recovered.
Here is the actual HTML for the sub-section title and its opening paragraphs (abbreviated attributes):
<!-- body child [89]: sub-section title — sibling, not parent of [90] -->
<div style="margin-bottom:3pt;margin-top:12pt;text-align:justify">
<span style="color:#76b900;font-family:'NVIDIA Sans',sans-serif;font-size:9pt;font-weight:700;line-height:120%">
Our Businesses
</span>
</div>
<!-- body child [90]: body paragraph — sibling of [89] -->
<div style="margin-bottom:9pt;text-align:justify">
<span style="color:#000000;font-family:'NVIDIA Sans',sans-serif;font-size:9pt;font-weight:400;line-height:120%">
We report our business results in two segments.
</span>
</div>
<!-- body child [91]: body paragraph — sibling of [89] -->
<div style="margin-bottom:9pt;text-align:justify">
<span style="color:#000000;font-family:'NVIDIA Sans',sans-serif;font-size:9pt;font-weight:400;line-height:120%">
The Compute & Networking segment includes our Data Center accelerated computing
and networking platforms and AI solutions and software, and Automotive platforms
and autonomous and electric vehicle solutions including software.
</span>
</div>
<!-- body child [92]: body paragraph — sibling of [89] -->
<div style="margin-bottom:9pt;text-align:justify">
<span style="color:#000000;font-family:'NVIDIA Sans',sans-serif;font-size:9pt;font-weight:400;line-height:120%">
The Graphics segment includes GeForce GPUs for gaming and PCs, and Quadro/NVIDIA
RTX GPUs for enterprise workstation graphics.
</span>
</div>
NVIDIA uses brand green (#76b900) and bold weight for section titles; body text uses normal weight and black. Other issuers use different colors and fonts, but the pattern repeats: titles are visually distinct spans in their own div, not semantic heading tags. Earlier in Item 1, Our Company follows the same pattern; later sub-headings include Our Markets and Sales and Marketing.
Why flat EDGAR HTML breaks naive parsers
Three common approaches fail on this structure:
- Heading-tag assumptions — Searching for
<h1>–<h3>finds almost nothing useful in typical issuer HTML. - Nested-section assumptions — Expecting
<section>wrappers around Item content does not match EDGAR output; paragraphs are peers of titles. - Fixed-size chunking — Splitting the file every N tokens cuts between sibling divs, separating "Our Businesses" from the paragraph that belongs to it.
The fix is not a smarter chunk size. It is to classify blocks first, then group them into a logical tree.
EDGAR HTML often stores titles and paragraphs as siblings; parsing turns that flat stream into a tree of titled nodes.
Why does fixed-size chunking fail on SEC filings?
Teams building RAG or agent pipelines over SEC filings often start with a familiar recipe: download HTML, strip tags, split into 512- or 1,000-token chunks, embed, retrieve. It fails on 10-K and 10-Q HTML because LLMs need titled, logically bounded units — and token windows do not align with either major Items or issuer sub-headings.
For a deeper treatment of downstream agent architecture, see AI agents over SEC filings: RAG vs navigation.
Fixed-size chunking creates four recurring problems — all visible in the NVIDIA FY2026 10-K:
- Titles get separated from body text. A chunk boundary can land between NVDA's "Our Businesses" title (
[89]) and the first segment sentence at[90], leaving the LLM with body text but no sub-section identity. - Whole Items are still too large. Even perfect PART/ITEM splitting leaves NVDA's Item 1A Risk Factors spanning body indices
[224]–[585]— far larger than a useful agent read. Agents need individual risk themes, MD&A sub-topics, and note headings. - Tables get split mid-row. NVDA's consolidated financial statements in Item 8 are single top-level
<div>wrappers around full<table>elements; row-level chunking breaks numeric fidelity. - TOC and cover-page noise pollute retrieval. In NVIDIA's filing, "Table of Contents" appears 55 times as a running header. Classify and filter those blocks before embedding.
What is the best way to parse SEC filings into sections?
The best general approach is style-based, structure-first parsing whose output is an LLM-ready section tree: many small nodes, each with a title, cohesive body text or an intact table, and a stable place in the filing hierarchy.
The pipeline has two jobs that serve different consumers:
| Job | Mechanism | NVDA FY2026 example | Who uses it |
|---|---|---|---|
| Map the filing | PART/ITEM regex + deduplication | Item 1. Business ([69]), Item 1A. Risk Factors ([224]) | Agents choosing where to look |
| Split into readable units | CSS title detection + tree nesting | Our Businesses ([89]) → 3 segment paragraphs | LLMs reading and citing one unit |
Skipping the second job leaves agents with Items that are too coarse. Skipping the first leaves sub-sections without regulatory context. This is the pattern used by open-source tools such as sec-parser and sec2md.
Step 1: Treat each top-level HTML block as one candidate element
Parse the filing HTML and enumerate direct children of <body> (skip empty whitespace nodes). Each <div>, table wrapper, or standalone XBRL block becomes one element in an ordered list. In NVDA's FY2026 10-K, that yields 1,211 top-level candidates before classification.
Split conservatively; default to one block = one element unless a wrapper clearly contains multiple semantic units such as a label plus a table.
Step 2: Detect major boundaries with PART and ITEM text
SEC 10-K and 10-Q filings follow standardized Part and Item numbering. Detect lines that start with patterns such as Part I and Item 1. using anchored regular expressions, then map them to canonical section identifiers (e.g. part1item1 → Business, part1item1a → Risk Factors).
This gives agents orientation — which regulatory bucket they are in — but not LLM-sized reads. Two practical rules prevent false positives:
- Prefer body occurrences over TOC rows. When the same Item text appears in a table cell and in a standalone div, prefer the non-table occurrence as the real section start — in NVDA's 10-K, the body
Item 1. Businessdiv at[69]wins over earlier TOC matches. - Enforce document order. Promote a candidate Item boundary only if its canonical order is ahead of the last accepted section — so TOC back-references and duplicate strings do not rewind the parser.
At this stage, major section titles become typed boundary markers (often called TopSectionTitle in sec-parser terminology).
Step 3: Detect sub-section titles with inline CSS styling
This is the step that makes filings usable for LLMs. Within Item 1 of NVDA's 10-K, issuer sub-headings such as Our Company ([71]), Our Businesses ([89]), and Sales and Marketing ([142]) each become a named node whose paragraphs an agent can load independently.
Detect these by inline style, not tag name:
| Signal | Typical meaning | NVIDIA 10-K example |
|---|---|---|
font-weight:700 (or ≥600) on most characters | Heading candidate | Item titles, sub-headings |
Larger font-size (e.g. 10pt vs 9pt) | Higher-level title within an Item | Item 1. Business vs Our Businesses |
| Distinct color (issuer-specific) | Visual section break | Green #76b900 titles vs black body |
| Normal weight, no highlight | Body paragraph | "We report our business results in two segments." |
Use a style threshold — e.g. a bold signal applies only if at least ~80% of characters in the block share that style — and filter repeated page headers before promoting a block to title.
Step 4: Keep tables and paragraphs atomic
Cohesion rules matter as much as boundary detection: keep whole tables together, keep EDGAR paragraph divs together, and split mixed wrappers only when a top-level block clearly combines prose and a table. In NVDA's Item 8, each financial statement table stays inside one top-level div — do not merge across a title, table, or Item boundary.
Step 5: Build a section tree after classification
The ordered flat list preserves EDGAR document sequence. A second pass builds a tree: nest each paragraph and table under the nearest preceding title; nest sub-headings under their Item; nest Items under their Part.
The leaves of this tree are the LLM retrieval units — e.g. the Our Businesses node containing three segment paragraphs, not Item 1 containing eighty pages.
Conceptually, content after a Part/Item title nests under it until the next Part/Item, and content after a styled sub-heading nests under that sub-heading until the next title of equal or higher visual rank. An agent workflow then looks like: inspect the tree → pick a titled node → read that node's text. Each node still points at the original block for citation and traceability.
Comparison: approaches vs what LLMs need
| Approach | Finds Items (Business, 1A, MD&A) | Finds sub-section titles (Our Businesses, …) | LLM-ready titled units |
|---|---|---|---|
| Fixed-size chunking | No | No | No — arbitrary fragments |
| Regex-only PART/ITEM split | Yes | No | No — Items too large |
| Style-based structure-first | Yes | Yes | Yes |
The parser first classifies visual blocks, then builds a section tree whose leaves are titled units an LLM can read.
Worked example: NVIDIA 10-K from flat HTML to a section tree
Starting from the flat sibling strip in NVIDIA's FY2026 10-K, a structure-first parser produces a logical tree fragment like this:
TopSectionTitle Part I
└── TopSectionTitle Item 1. Business ← major boundary (map)
├── TitleElement Our Company
│ └── TextElement …
├── TitleElement Our Businesses ← LLM retrieval unit
│ ├── TextElement We report our business results in two segments.
│ ├── TextElement The Compute & Networking segment includes…
│ └── TextElement The Graphics segment includes GeForce GPUs…
├── TitleElement Our Markets
│ └── TextElement …
└── TitleElement Sales and Marketing
└── TextElement …
What an agent reads vs what it skips
An agent answering "What segments does NVIDIA report?" should target the Our Businesses node — not all of Item 1, and not a 512-token chunk that might start mid-paragraph:
| Unit | Approx. scope | Agent action |
|---|---|---|
| Item 1. Business (whole) | Entire Business disclosure | Too large; poor citation |
| Token chunk #47 | Arbitrary text span | May omit title or split mid-thought |
| Our Businesses node | Title + 3 segment paragraphs | Read this node; cite as Item 1 › Our Businesses |
Agents work best when they read one cohesive titled node instead of a whole regulatory Item or an arbitrary token chunk.
Several details matter: flat indices 89 and 90 become parent and child in the tree because classification + nesting rules assign paragraph blocks to the nearest preceding title; Item 1. Business is detected by standardized Item 1. text, while Our Businesses is detected primarily by bold green styling at 9pt. The next major boundary, Item 1A. Risk Factors (body index 224), closes the Item 1 subtree.
Financial statement areas later in NVDA's filing follow the same mechanics: a centered bold title div such as "Consolidated Statements of Income" becomes a TitleElement, and the following div containing a full <table> becomes a single TableElement — one titled unit an agent can load when the question is about reported income-statement lines, not all of Item 8.
The tree is the interface between raw EDGAR HTML and LLM/agent tools. Navigation picks a branch; read_node (or equivalent) returns title + cohesive content for that node only. Embedding, if used at all, works better on these titled units than on the raw filing.
How is parsing 10-K different from 10-Q?
The parsing mechanics are the same for 10-K and 10-Q: flat EDGAR HTML, styled divs, PART/ITEM boundaries, CSS sub-headings, atomic tables, tree nesting. What differs is the canonical Item registry — which Item numbers exist and what they are called. In both forms, the LLM-facing output is the same shape: a tree of titled sub-sections inside each Item, not one blob per Item.
| Aspect | Form 10-K | Form 10-Q |
|---|---|---|
| Typical length | Often 150–300 pages | Shorter |
| Parts | I–IV | I–II |
| Items | ~27 standardized items | ~13 standardized items |
| HTML structure | Flat sibling divs | Flat sibling divs |
| Title detection | PART/ITEM text + CSS styling | PART/ITEM text + CSS styling |
| Sub-section headings | Issuer-specific styled divs | Issuer-specific styled divs |
If you learn to parse 10-K HTML into sections, you already understand the hard part for 10-Q. Swap the Item map, not the pipeline.
Foreign private issuers filing 20-F or interim 6-K reports use the same flat HTML patterns for narrative content, though 6-K layout is less standardized than 10-K/10-Q — document selection (primary filing vs exhibit) matters more for those forms.
What are common mistakes when parsing SEC filings?
-
Assuming
<h1>–<h3>exist. NVDA's FY2026 10-K uses styled<div>/<span>pairs throughout Item 1 — no semantic heading tags. Search for visual signals and PART/ITEM text instead. -
Stopping at PART/ITEM boundaries. Finding NVDA's Item 1 (
[69]) and Item 1A ([224]) is necessary but not sufficient. Without CSS sub-heading detection, you have no Our Businesses-scale units for LLMs to read. -
Chunking before structure detection. Embedding arbitrary text splits loses title–body relationships that only exist as sibling blocks in the source HTML — e.g. NVDA body
[89](title) vs[90](first paragraph). -
Treating the table of contents as the body. NVDA's TOC repeats the same Item strings as the real sections. Use order-aware deduplication and prefer the body occurrence at
[69]over earlier TOC matches. -
Splitting financial tables by row. Keep each table as one element inside its titled node; extract structure separately if you need row-level access.
-
Ignoring inline XBRL inside styled spans. Cover pages and fiscal-year lines embed
ix:nonnumerictags inside bold spans. Classify the wrapper block; do not strip tags blindly before understanding block boundaries. -
Applying 10-K ITEM logic to 8-K or 6-K without document selection. Current reports and foreign interim filings may put substantive content in exhibits (e.g. EX-99.1 press releases). Pick the right HTML document before parsing.
Which open-source tools help with SEC filing parsing?
You do not need to build everything from scratch. Several open-source projects implement structure-first ideas:
sec-parser — Classifies EDGAR HTML into semantic element types (TopSectionTitle, TitleElement, TextElement, TableElement) and exposes a TreeBuilder for hierarchy.
sec2md — Converts filings to markdown with PART/ITEM extraction, page-aware chunking for RAG, and citation traceability back to source HTML.
edgartools / edgar-parser — Higher-level helpers to download filings and extract qualitative sections or XBRL facts.
BeautifulSoup alone is a building block, not a complete solution. It can load NVDA's nvda-20260125.htm and iterate the 1,211 <body> children — but you still need classification rules for titles, tables, PART/ITEM boundaries, TOC deduplication, and tree nesting.
Whether you build or adopt, the design goal is the same: parse SEC filings into many small sections with titles — sub-section nodes an agent can read one at a time — not a handful of mega-Items or a flat wall of tokens.
FAQ
Is finding Item 1 and Item 1A enough for AI?
No. Items are containers, not retrieval units. In NVDA's FY2026 10-K, Item 1A Risk Factors spans 362 body blocks (indices [224]–[585]). Agents need issuer sub-headings and paragraph groups under titles — the same granularity a human analyst uses when they scroll to a labeled subsection, not when they open the whole Item PDF.
Why are SEC filings flat HTML?
EDGAR publishing workflows emit sequential block-level elements — mostly <div> tags — with visual formatting applied via inline CSS. NVIDIA's FY2026 10-K has 1,211 such top-level <body> children and no HTML5 outline. The result is a flat sibling stream that mirrors printed page layout more than nested document structure.
Can I parse a 10-K with BeautifulSoup alone?
BeautifulSoup can load the DOM and iterate <body> children, which is the right first step on a filing like NVDA's nvda-20260125.htm. It cannot, by itself, tell a sub-section title ([89]) from a body paragraph ([90]), detect PART/ITEM boundaries reliably, deduplicate TOC matches, or group siblings into a section tree. You need classification and nesting logic on top.
Should I use XBRL or HTML parsing?
Use both for different jobs. Inline XBRL (and the separate XBRL instance document) is the right source for numeric financial facts — revenue, assets, EPS — with units and periods attached. HTML structure-first parsing is the right source for narrative disclosure — prose, tables, and issuer sub-section titles inside Business, Risk Factors, and MD&A. XBRL does not give you NVDA's Our Businesses segment narrative; HTML style-based parsing does. A complete financial AI stack routes by question type; narrative agent reads use the titled section tree.
What is the difference between a section title and a paragraph in EDGAR HTML?
Usually the tag name is the same (<div> containing <span>). The difference is inline style: titles tend toward bold weight, slightly larger font size, and sometimes issuer brand color; body paragraphs use normal weight. In NVDA's 10-K, green #76b900 at font-weight:700 marks titles; black at font-weight:400 marks body text. PART/ITEM lines are identified by standardized text patterns at the start of the block.
How do I keep section titles attached to their content?
Classify title blocks and body blocks separately, then nest following body blocks under the nearest preceding title in a section tree — rather than flattening the filing to text and chunking by token count. In NVDA's Item 1, paragraphs [90]–[92] nest under the Our Businesses title at [89]. The output should be named nodes (title + body), not anonymous chunks. If you embed for retrieval, embed at sub-section node granularity after parsing, not before.
Where to go from here
Once filings are parsed into a tree of small titled nodes, the next engineering question is how agents navigate and read that tree — table of contents at the Item level, targeted reads at NVDA's Our Businesses node (Item 1 › Our Businesses), citation URLs tied to specific nodes rather than similarity search over arbitrary chunks.
For architectural comparisons, see AI agents over SEC filings: RAG vs navigation. For the full agent workflow that consumes this section tree — filing selection, TOC inspection, targeted node reads, and citation-backed answers — see how to build an SEC filing agent without naive RAG.
Teams that prefer not to maintain ingestion and parsing infrastructure can use hosted SEC filing retrieval layers (including AlphaCreek MCP) that expose pre-parsed table-of-contents navigation and section reads — but the parsing principles above apply regardless of whether you build or buy. To compare hosted MCP options, see best SEC EDGAR MCP servers for AI agents.
Methodology and update context
Author: Krasimir Atanasov — SEC filing ingestion, structure-first parsing, and financial AI retrieval infrastructure at AlphaCreek.
Methodology: HTML structure statistics and body-index examples were derived from NVIDIA Corporation Form 10-K filed January 29, 2026 for the fiscal year ended January 25, 2026 (CIK 0001045810, accession 0001045810-26-000021), primary document nvda-20260125.htm. Top-level <body> children were enumerated with BeautifulSoup; indices refer to direct body children in document order.
Primary sources:
Last updated: July 2026
Disclaimer: This article describes document parsing techniques for engineering and research workflows. It is not investment advice.
Related reading: AI agents over SEC filings: RAG vs navigation · How to build an SEC filing agent without naive RAG · Best SEC EDGAR MCP servers for AI agents
