How to Parse SEC 10-K Filings Into Sections for AI Agents
Style-based parsing turns a 10-K into titled sections an agent can read. On NVIDIA’s FY2026 filing, 1,211 flat HTML blocks become 534 AlphaCreek nodes — including Our Businesses with a live citation URL.
How to Parse SEC 10-K Filings Into Sections for AI Agents
Table of contents
- Short answer
- How to parse SEC 10-K filings
- What AlphaCreek MCP returns on this 10-K
- Why a 2018 regex gist fails on a 2026 10-K
- What should parsing produce for AI agents?
- 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 FY2026 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?
- Questions builders ask
- Methodology and update context
- Next step
Short answer
Parsing a SEC 10-K into sections means recovering issuer sub-headings such as Our Businesses — not only regulatory Items such as Business or Risk Factors — so an AI agent can read one titled unit and cite it.
ToC in this article means table of contents: the filing’s Part/Item list. It is not this page’s outline. The MCP tool get_filing_toc returns that filing ToC.
The method is a five-step, style-based pipeline: download primary HTML, treat each <body> child as one block, mark PART/ITEM in the body (not the ToC), detect sub-headings from CSS, then nest paragraphs and tables under the nearest title. On NVIDIA’s FY2026 10-K (nvda-20260125.htm), that HTML stream is 1,211 sibling blocks. Regex slices of Item 1A / 7 / 7A do not recover Our Businesses.
Why it matters: An agent that only knows “you are in Item 1” still cannot cite a passage. It needs a titled node.
Practical takeaway: Follow the five steps below. Use sec-parser or sec2md if you build the tree yourself. If you want that tree hosted, connect AlphaCreek MCP. For OSS versus hosted MCP servers, see Best SEC EDGAR MCP servers.
How to parse SEC 10-K filings
How to parse SEC 10-K filings for an agent is a five-step pipeline. The output is a section tree, not a list of regex slices.
- Download the primary HTML, not only the complete submission
.txt. NVIDIA’s FY2026 primary document isnvda-20260125.htm. - Treat each direct child of
<body>as one candidate block. NVIDIA has 1,211 of them: 1,048<div>, 84<hr>, and the rest inline XBRL. - Mark PART and ITEM boundaries from standardized text (Part I, Item 1. Business), and prefer the body hit over the table of contents.
- Detect issuer sub-headings from inline CSS (
font-weight:700, size, color). NVIDIA paints titles in brand green#76b900. Tag name is still<div>. - Nest following paragraphs and whole tables under the nearest title. Leaves of that tree are what the agent reads.
Open-source tools that already do this classification include sec-parser (TopSectionTitle, TitleElement, TextElement, TableElement) and sec2md (markdown with PART/ITEM extraction).
Do not stop at “extract Item 1A.” NVIDIA’s Item 1A still spans hundreds of body blocks. The useful unit is a titled child such as a single risk theme. The next section shows the live AlphaCreek tree and citation URL for NVIDIA’s Our Businesses node. For how hosted MCP compares with open-source servers, see Best SEC EDGAR MCP servers.
What AlphaCreek MCP returns on this 10-K
These are live tool responses from AlphaCreek MCP on 26 August 2026. The agent path is list_filings → get_filing_toc → read_node_content.
list_filings(ticker="NVDA", document_type="10-K", limit=5) — newest row:
| Field | Value |
|---|---|
artifact_document_id | NVDA_10-K_000104581026000021 |
document_date | 2026-01-25 |
filing_date | 2026-02-25 |
document_url | nvda-20260125.htm |
Older 10-K ids in the same list: NVDA_10-K_000104581025000023, …24000029, …23000017, …22000036.
get_filing_toc(artifact_document_id="NVDA_10-K_000104581026000021") — header and Item 1 excerpt:
FILING: NVDA 10-K 2026-01-25 | artifact_document_id=NVDA_10-K_000104581026000021
1 | TopSectionTitle | Part I
1.1 | TopSectionTitle | Item 1. Business
1.1.1 | TitleElement | Our Company (~4142 tokens approx)
Our Businesses (~103 tokens approx)
We report our business results ...nterprise workstation graphics.
Our Markets (~101 tokens approx)
1.1.8 | TitleElement | Business Strategies (~3957 tokens approx)
1.2 | TopSectionTitle | Item 1A. Risk Factors (~122 tokens approx)
1.3 | TopSectionTitle | Item 1B. Unresolved Staff Comments
1.4 | TopSectionTitle | Item 1C. Cybersecurity
The 2018 gist regex never emits 1.1.2 or Item 1C (1.4). The ToC does.
read_node_content(artifact_document_id=..., node_id="1.1.2") expands the ToC title into two citeable blocks. The title node is only the heading. The segment sentences are on the child. NVIDIA reports two segments: Compute & Networking (Data Center, networking, AI software, Automotive platforms) and Graphics (GeForce and Quadro/NVIDIA RTX) (Our Businesses).
NODE_ID: 1.1.2
TITLE: Our Businesses
CITATION_URL: https://alphacreek.ai/sec/reader?doc_id=NVDA_10-K_000104581026000021&node_id=sp-1.1.2
NODE_ID: 1.1.2.1
CITATION_URL: https://alphacreek.ai/sec/reader?doc_id=NVDA_10-K_000104581026000021&node_id=sp-1.1.2.1
CONTENT_START
We report our business results in two segments. The Compute & Networking
segment includes… The Graphics segment includes GeForce GPUs…
CONTENT_END
That CITATION_URL is what a gist regex slice cannot produce. Connect MCP if you want this path hosted instead of operating ingest.
Why a 2018 regex gist fails on a 2026 10-K
A widely copied notebook, How to Parse 10-K Report from EDGAR (SEC), was written against Apple’s 2018 10-K .txt. We ran that gist’s patterns against NVIDIA’s FY2026 filing on 26 August 2026. It fails in a way you can reproduce.
The gist’s item regex is:
regex = re.compile(r'(>Item(\s| | )(1A|1B|7A|7|8)\.{0,1})|(ITEM\s(1A|1B|7A|7|8))')
It only hunts Items 1A, 1B, 7, 7A, and 8. It never hunts Item 1, Item 1C, or issuer titles such as Our Businesses.
| Input we tried | What the gist does | Result on NVIDIA FY2026 |
|---|---|---|
Primary HTML nvda-20260125.htm | Step 2 looks for <DOCUMENT> / <TYPE> | Zero <DOCUMENT> tags. The notebook cannot isolate a 10-K section. |
Complete submission .txt (11.5 MB, 111 <DOCUMENT> parts) | Same regex inside the 10-K part | 10 matches. The first >Item 1A. is the ToC table cell (…_16">Item 1A.</a>), not the body heading. |
| Body Item 8 | Same regex | Body uses Item 8. / Item 8.; Item 7 uses a normal space. The pattern is layout-fragile. |
Even if you keep the last match of each Item and slice item1a → item1b, you still get one Risk Factors blob. You do not get the 17 titled Item 1 nodes AlphaCreek stores under 1.1. That is the information-gain gap versus the gist: regex can sometimes find Item labels; it does not build a tree an agent can cite.
“Table of Contents” appears 81 times in NVIDIA’s primary HTML (running headers plus the real ToC). A first-hit regex will keep latching onto the ToC.
What should parsing produce for AI agents?
Parsing is often described as “extracting Business, Risk Factors, and MD&A.” That is only the map. Agents read the destinations.
| Layer | What it is | NVIDIA FY2026 example | Useful for |
|---|---|---|---|
| Major boundaries | SEC Part / Item | Item 1. Business (1.1), Item 1A. Risk Factors (1.2) | Choosing which disclosure regime applies |
| Titled sub-sections | Issuer headings inside an Item | Our Company (1.1.1), Our Businesses (1.1.2), Data Center (1.1.4) | What the agent reads and cites |
Design rules for the tree:
- Every retrieval unit has a title.
- Every unit is cohesive — no mid-paragraph or mid-table splits.
- Units are addressable — stable IDs such as
sp-1.1.2.1, not “chunk 47.” - Units are human-scale — sub-section, not whole-Item and not a 512-token fragment.
What many teams build What agents need (NVDA FY2026 10-K)
───────────────────── ───────────────────────────────────
Item 1. Business (huge) Item 1. Business
Item 1A. Risk Factors ├── Our Company
Item 7. MD&A ├── Our Businesses ← read this node
├── Our Markets
└── Data Center, Gaming, …
What is the HTML structure of a 10-K filing?
A 10-K’s HTML is flat: <body> holds a long sequence of sibling blocks — mostly <div>, plus <hr> page breaks and inline XBRL — not nested <section> / <h2> trees.
NVIDIA FY2026 top-level <body> 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 |
In the body (not the ToC), Part I, Item 1, and Our Businesses are separate siblings:
| Body index | Bold styling? | Visible text (truncated) |
|---|---|---|
| 67 | yes | Part I |
| 69 | yes | Item 1. Business |
| 71 | yes | Our Company |
| 72–88 | no | Body paragraphs under Our Company |
| 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… |
Our Businesses does not wrap those paragraphs. A DOM walk that looks for “text inside the heading’s parent” fails.
<!-- 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>
There are almost no useful <h1>–<h3> tags. Titles and paragraphs share <div> + <span>. The difference is CSS.
EDGAR HTML stores titles and paragraphs as siblings. Parsing turns that stream into a tree of titled nodes.
Why does fixed-size chunking fail on SEC filings?
Download HTML, strip tags, split every 512 tokens, embed. That recipe fails because LLMs need titled, logically bounded units. Token windows do not line up with Items or with issuer sub-headings.
For agent architecture after the tree exists, see AI agents over SEC filings: RAG vs navigation.
On this NVIDIA 10-K:
- Titles separate from body. A chunk boundary can land between Our Businesses (
[89]) and the first segment sentence ([90]). - Whole Items stay too large. Item 1A still runs from body index
[224]through[585]. - Tables split mid-row. Item 8 statements are one
<div>around a full<table>. - ToC noise. “Table of Contents” appears 81 times. Classify those blocks before you embed.
What is the best way to parse SEC filings into sections?
Use style-based, structure-first parsing. Emit a tree of small nodes: title, cohesive text or an intact table, and a place in the hierarchy.
| Job | Mechanism | NVIDIA FY2026 | Who uses it |
|---|---|---|---|
| Map the filing | PART/ITEM text + skip ToC | Item 1. Business ([69]), Item 1A ([224]) | Agents choosing where to look |
| Split into readable units | CSS title detection + nesting | Our Businesses ([89]) → 3 segment paragraphs | LLMs reading one unit |
This is the pattern in sec-parser and sec2md.
Step 1. Enumerate direct <body> children (1,211 candidates on this 10-K).
Step 2. Detect Part I / Item 1. with anchored patterns. Prefer the standalone body div over a ToC table cell. Enforce document order so duplicate strings do not rewind the parser.
Step 3. Detect sub-headings with inline style, not tag name: bold weight, slightly larger size, issuer color. NVIDIA: green #76b900 + font-weight:700 for titles; black + 400 for body.
Step 4. Keep tables and paragraph divs atomic.
Step 5. Nest each block under the nearest preceding title of equal or higher rank. AlphaCreek then stamps dotted IDs (sp-1.1.2) onto that tree so read_node_content can return a citation URL such as Our Businesses.
| Approach | Finds Items | Finds Our Businesses | LLM-ready titled units |
|---|---|---|---|
| Fixed-size chunking | No | No | No |
| 2018 gist regex (1A/7/7A/8) | Partial | No | No — Item blobs |
| Style-based structure-first | Yes | Yes | Yes |
Classify visual blocks first, then build a section tree whose leaves an LLM can read.
Worked example: NVIDIA FY2026 from flat HTML to a section tree
From the sibling strip, a structure-first parser produces:
Part I ← AlphaCreek node 1
└── Item 1. Business ← 1.1
├── Our Company ← 1.1.1
├── Our Businesses ← 1.1.2
│ └── We report our business results… ← 1.1.2.1 (citation URL)
├── Our Markets ← 1.1.3
├── Data Center / Gaming / … ← 1.1.4 …
└── … 17 titled Item 1 sub-sections total
Measured 26 August 2026: MCP get_filing_toc on NVDA_10-K_000104581026000021, plus the public annotated HTML for the same artifact.
| Metric | Value | Source |
|---|---|---|
Top-level HTML <body> children | 1,211 | Primary HTML (BeautifulSoup) |
| MCP ToC lines | 536 | get_filing_toc |
Unique data-sec-parser-node-id values | 534 | Annotated reader HTML |
| Part roots | 4 | get_filing_toc (1–4) |
| Max node depth in annotated HTML | 7 | Annotated reader HTML |
| Titled sub-sections under Item 1. Business | 17 | Annotated HTML + ToC |
| Our Businesses ToC size | ~103 tokens approx | get_filing_toc line for 1.1.2 |
An agent answering “What segments does NVIDIA report?” should read 1.1.2 / 1.1.2.1, not all of Item 1:
| Unit | Agent action |
|---|---|
| Item 1. Business (whole) | Too large; weak citation |
| Token chunk #47 | May omit the title |
Our Businesses (sp-1.1.2.1) | Read this node; cite the URL |
Agents work best when they read one titled node instead of a whole Item or an arbitrary token chunk.
The NVIDIA segment sentences at [90]–[92] become children of Our Businesses because nesting assigns them to the nearest preceding title. Item 1A at body index [224] closes the Item 1 subtree.
Later, a centered bold title such as “Consolidated Statements of Income” becomes a title node, and the following <table> stays one TableElement.
How is parsing 10-K different from 10-Q?
The mechanics are the same: flat HTML, styled divs, PART/ITEM text, CSS sub-headings, atomic tables, tree nesting. What changes is the Item map.
| Aspect | Form 10-K | Form 10-Q |
|---|---|---|
| Typical length | Longer | Shorter |
| Parts | I–IV | I–II |
| Items | More standardized items | Fewer |
| HTML structure | Flat sibling divs | Flat sibling divs |
| Title detection | PART/ITEM + CSS | PART/ITEM + CSS |
If you can parse 10-K HTML into sections, you already understand 10-Q. Swap the Item registry, not the pipeline. Foreign 20-F / 6-K use the same flat HTML for narrative; 6-K often puts substance in EX-99.1, so document selection matters first.
What are common mistakes when parsing SEC filings?
- Assuming
<h1>–<h3>exist. NVIDIA uses styled<div>/<span>pairs. - Stopping at PART/ITEM. Finding Item 1 (
[69]) is necessary and not sufficient. - Running the 2018 gist regex on primary HTML. No
<DOCUMENT>tags; first Item hits are ToC. - Chunking before structure. Sibling
[89](title) and[90](paragraph) get split. - Splitting financial tables by row.
- Stripping inline XBRL before you classify the wrapper block.
- Applying 10-K ITEM logic to 8-K or 6-K without picking EX-99.1 when that is the real document.
Which open-source tools help with SEC filing parsing?
You do not need to start from BeautifulSoup alone.
sec-parser — Classifies EDGAR HTML into TopSectionTitle, TitleElement, TextElement, TableElement, and builds a tree. AlphaCreek uses this library in ingest, then adds dotted node IDs and citation URLs.
sec2md — Filings to markdown with PART/ITEM extraction and citation back to source HTML.
edgartools — Download and higher-level access. Still not a substitute for a section tree if you need titled narrative nodes.
BeautifulSoup alone can iterate NVIDIA’s 1,211 <body> children. It cannot tell [89] from [90], skip the ToC, or emit sp-1.1.2.1.
Whether you build or buy, the design goal is the same: many small titled sections, not mega-Items and not a wall of tokens.
Questions builders ask
Is finding Item 1 and Item 1A enough for AI?
No. Items are containers. NVIDIA Item 1A spans 362 body blocks ([224]–[585]). Agents need issuer sub-headings — the same granularity a human uses when they scroll to a labeled subsection.
Can I parse a 10-K with the Apple 2018 gist?
Not as a production parser. On NVIDIA FY2026 primary HTML the gist never enters Step 2. On the complete .txt its first Item 1A match is the ToC. It never emits Our Businesses.
Should I use XBRL or HTML parsing?
Both, for different jobs. XBRL / CompanyFacts for tagged numbers. HTML structure-first parsing for narrative titles inside Business, Risk Factors, and MD&A. XBRL does not give you NVIDIA’s Our Businesses paragraph. For official JSON versus DIY HTML versus hosted MCP, see SEC EDGAR API vs MCP.
How do I keep titles attached to content?
Classify title vs body, then nest following body blocks under the nearest title. Embed after that, at node granularity.
Methodology and update context
Author: Krasimir Atanasov — SEC filing ingestion, structure-first parsing, and financial AI retrieval at AlphaCreek.
Filing: NVIDIA Corporation Form 10-K for the fiscal year ended January 25, 2026 (CIK 0001045810, accession 0001045810-26-000021), primary document nvda-20260125.htm. AlphaCreek MCP list_filings reports document_date=2026-01-25 and filing_date=2026-02-25.
HTML counts: Direct <body> children enumerated with BeautifulSoup on the local primary HTML. Body indices are document-order children.
Regex failure: Gist patterns from anshoomehra’s 10-K notebook run on 26 August 2026 against the primary HTML and the complete submission .txt.
AlphaCreek MCP (26 August 2026): list_filings (NVDA, 10-K), get_filing_toc (NVDA_10-K_000104581026000021), read_node_content (node_id=1.1.2). Node 1.1.2 is the Our Businesses title; 1.1.2.1 is the segment paragraph block. Unique HTML node-id count (534) is from the public annotated reader HTML, not from the ToC line count (536).
Primary sources:
Last updated: August 26, 2026. Added the gist failure, live MCP tool trace, node counts, citation URL, and a first-screen CTA. Title unchanged.
Disclaimer: This article describes document parsing for engineering workflows. It is not investment advice.
Next step
Once you have a tree of titled nodes, the product question is navigation: ToC first, then one node read, then a citation URL beside the claim.
- DIY: sec-parser and sec2md
- Hosted: Connect AlphaCreek MCP · MCP docs · Best SEC EDGAR MCP servers
- Architecture: RAG vs navigation · Build an SEC filing agent without naive RAG · SEC EDGAR API vs MCP
Example citation from this filing: Our Businesses.
