Structured Data Extraction from Financial Reports: A Six-Model Open-Source Showdown

In the world of financial statement extraction, the JSON validator may be the most lenient reviewer of all—it only checks whether a number is a number, not whether the sign, magnitude, or source is right. A real-world failure case: a segment revenue table from an earnings report was extracted cleanly, with four operating segments each having revenue, period, and units, and the schema validation passed completely. But when someone summed the segments, the total exceeded the consolidated revenue—the model had read the "intersegment eliminations" line as a positive number, adding the eliminations back instead of subtracting them.

This evaluation focuses on open-weight models that permit commercial use, with the task of converting report text or page images into fields such as revenue, period, unit, magnitude, and segment. The premise is that the text is already available: for EDGAR filings, that means the filing's own HTML; only PDF-only sources require OCR.

It's worth noting upfront: for the primary statements of U.S. issuers, you may not need a model at all. The SEC's XBRL API returns tagged facts in base units. But the places the API misses are exactly where models earn their keep—untagged tables in MD&A and EX-99.1 earnings releases, non-U.S. annual reports that exist only as PDFs, and the segment breakdowns discussed below.

Ranking of Six Open-Source Models

1. Qwen3.8-27B: The Strongest General-Purpose Extractor

Qwen3.8-27B is Qwen's 27.8-billion-parameter dense model with native vision-language input support, under an Apache-2.0 license. It can read page images directly, eliminating the need for a separate OCR step when layout permits.

It ranks first on both evidence and capability. The model card reports a score of 91.1 on OmniDocBench v1.5, the strongest document-parsing score among the generative models in this evaluation. It supports text and image input in a single request, can output structured results conforming to JSON-schema grammar when the serving layer supports it, and has a native context of 262,144 tokens, extendable to 1 million—enough to hold an entire 10-K section. Thinking mode is on by default and should be disabled per-request for extraction, otherwise you pay for unnecessary reasoning on every field.

The limitation is size: self-hosting a 27B model requires a large-VRAM GPU, and the model card reports no finance-specific extraction scores. It's suited to schemas that require judgment—segment tables, note adjustments, and fields that require reading across rows.

2. NuExtract3: The Best Dedicated Extraction Model

NuExtract3 comes from NuMind and is built for one thing: filling JSON templates from documents. It's a 4-billion-parameter fine-tune of Qwen3.5-4B, Apache-2.0 licensed, supporting text and image input, handling multilingual documents, and running at a 131,072-token context under the vLLM configuration given in its model card. NuMind has also released quantized versions including FP8 and GGUF.

Template language is its strength. You describe the fields, and the model returns null or an empty array when values are missing. This matters enormously in finance: a model that chooses to abstain on missing segment data is more trustworthy than one that fabricates a plausible-looking number. It also offers reasoning and non-reasoning modes, and can convert pages to Markdown with tables rendered as HTML.

The data comes from NuMind's own benchmarks: in internal testing across roughly 600 documents (reportedly including invoices, movie posters, and floor plans), NuExtract3 scored 0.651 versus 0.417 for its Qwen3.5-4B base; on ExtractBench it averaged 82.35. Neither set of figures specifies coverage of financial filings.

3. Qwen3.5-4B: The Value Pick

Qwen3.5-4B is a small-scale generative model with 4.66B weight parameters, Apache-2.0 licensed. It shares the family's 262,144-token context and, like Qwen3.8, has thinking mode enabled by default unless manually disabled.

Its positioning is cost. Extracting a dozen-plus fields from the same report section each period is often good enough with a 4B model on a small GPU, and the savings at scale are reason enough to test it. The model card also reports OmniDocBench v1.5 results, but the ranking here is based on size and cost. Whether accuracy is sufficient can only be answered by your own evaluation set—test it on the hardest filings you cover, not the cleanest ones.

4. Qwen3-4B-Instruct-2507: The Most Predictable Latency

Qwen3-4B-Instruct-2507 is an earlier 4B generation, Apache-2.0 licensed. Its model card states the key difference plainly: it supports only non-thinking mode, with a native 262,144-token context.

This makes it the predictable choice. Without thinking tokens, per-field latency is stable, making it suitable for extraction services with response-time budgets, and output length is easier to control. It's older than Qwen3.5-4B, and the latter would be expected to edge it out on harder pages. Running both on the same evaluation set is cheap and will tell you whether the gap matters for your schema.

5. GLiNER2 Large: The CPU Entity-Tagging Workhorse

GLiNER2 comes from Fastino, an encoder model with 486 million parameters in the large weights, Apache-2.0 licensed. The model card describes it as performing entity recognition, classification, structured extraction, and relation extraction in a single forward pass, and calls it "CPU-first."

Speed is the selling point. For named entities rather than computed fields—company names, auditors, segment labels, or fiscal year ends—a schema-driven encoder is fast and cheap. It doesn't generate text or reason across tables, so totals that need to be reconciled against two rows of data are beyond its scope. It's suited to a pipeline's first pass: tagging entities, routing pages, and then handing numbers off to a generative model.

6. NuNER_Zero: The Lightest Zero-Shot Tagger

NuNER_Zero comes from NuMind, a 449-million-parameter zero-shot entity tagger under the MIT license. You pass in labels, and it finds the spans.

It ranks last because its task is the smallest—it only tags spans, doesn't handle schemas, and doesn't understand what numbers mean. For the simplest fields (company, auditor, date), that's enough, and a model of this size is cheap to run on every document. Its model card hasn't been updated since February 2025.

OmniDocBench v1.5 is a comprehensive benchmark in the document-parsing field, covering subtasks including layout analysis, table recognition, formula recognition, and text recognition. A higher score indicates stronger overall capability in converting page images into structured content. It is not equivalent to financial field extraction accuracy—a table being correctly recognized as a table structure does not guarantee that its "eliminations" row is assigned the correct sign. This article therefore lists OmniDocBench scores as publisher evidence, not as a basis for ranking.

The distinction between sparse and dense models is also worth noting. Qwen3.8-27B is a dense model, activating all 27.8 billion parameters at inference, with high VRAM usage but predictable behavior; by contrast, mixture-of-experts models activate only a subset of parameters. Financial extraction requires cross-row and cross-table reconciliation, and dense models are generally more stable in long contexts, at the cost of a higher self-hosting barrier.

Comparison with Hosted APIs

Hosted frontier models are a different service path from the open-weight models above. OpenAI's Structured Outputs guarantees that responses conform to a provided JSON schema, and Gemini and Claude also offer schema-constrained output. Prompt caching and batch pricing (roughly half of list price) reduce the cost of stable prompts.

OpenAI's gpt-6.1-sol is priced at $2 per million input tokens and $10 for output, while gpt-6-astra is $10 and $50. Google Gemini reads PDFs natively, treating pages as images, including tables and charts, for documents up to 1,000 pages. Anthropic Claude Sonnet 5.5 is $2 and $10, offering a million-token window at standard pricing.

The cost is structural: documents go to the provider's service. Regional data residency and zero-retention terms exist, and Azure OpenAI, Vertex AI, and Bedrock can run within your cloud tenant, but the model isn't in your own cluster. Per-token costs also grow with scale.

A key caveat: schema compliance from any provider only guarantees shape. The eliminations row in the opening example could have passed strict JSON-schema output—because the error was in the sign, not the type.

How to Run These Models

Superlinked SIE is an inference layer for task-specific models, serving your document models in production alongside the OCR models and embedders a reporting pipeline needs. It has three deployment modes: SIE Cloud managed (pay-per-use, no GPU ops), self-hosted in your VPC or Kubernetes cluster (same engine, Apache 2.0), and local development.

On Cloud, Qwen3.8-27B (FP8) powers document field extraction and structured output at $0.72 per million tokens for both input and output, GLiNER2 Large is $0.186 per million input tokens, and NuNER_Zero is also available. Qwen3.6-27B, Qwen3.5-4B, and Qwen3-4B-Instruct-2507 are in the model catalog for self-hosting and local use. The SDK's extract call accepts a model ID and a list of labels, and the documentation covers generate for Qwen models, so comparing two candidates on the same evaluation set doesn't require a second serving stack.

Ranking Methodology

No single benchmark decides this ordering, because all the models on the list have published no financial extraction scores. The ranking is based on four criteria: the range of fields the model can handle (from entity labels to computed numbers); its fit for schema-constrained output, including abstention; publisher evidence (such as OmniDocBench v1.5 or template extraction scores), read as attributed claims; and runtime size and cost. Licensing is a gate, not a score—every entry permits commercial use.

Frequently Asked Questions

What if companyfacts has no segment revenue?

companyfacts, companyconcept, and frames only contain facts that use non-custom taxonomies and apply to the entire reporting entity, so segment and dimensional facts, as well as company extension tags, are excluded. You should read from the filing's own inline XBRL: each ix:nonFraction points to a contextRef, and that context carries axes and members such as StatementBusinessSegmentsAxis and segment members. Extract by axis and member, keep elimination members separate and record their sign, and finally check that segments plus eliminations equal the consolidated number.

companyfacts, companyconcept, and frames are XBRL data interfaces provided by the SEC, returning all tagged facts for an entity, all facts for a single concept, and the set of facts for the same concept across entities, respectively. The shared limitation of all three is that they only include facts using standard taxonomies that apply to the entire reporting entity, so what's excluded is precisely the dimensional segment and geographic data, as well as issuer-defined extension tags. This is consistent with the presentation logic of financial statements: segment information inherently exists in the form of axes and members and cannot be flattened into a single entity fact. To get segment revenue, you must go back to the filing's own inline XBRL and extract by axis and member one by one, rather than relying on these aggregate interfaces.

How do I avoid thousands-vs-millions magnitude errors?

Make magnitude a field. Extract the unit and magnitude declaration next to each number ("in thousands," "in millions") and then normalize in code, never in the prompt. In inline XBRL, magnitude is a tag: a number displayed as "78,678" carries scale="6" on its ix:nonFraction element, meaning 78,678 million, and decimals (such as -6) indicates rounding precision and is the correct tolerance for matching. The JSON API returns base units with no scale attribute, which you can cross-check against.

Inline XBRL is a format that embeds XBRL tags directly into HTML, widely used by U.S. issuers in their 10-Ks and 10-Qs. Each financial number is wrapped in an ix:nonFraction element, linked via contextRef to a context, which in turn carries the period, entity, and axes and members (such as segment, geography). Magnitude is expressed by the scale attribute, where scale="6" means the value is multiplied by 10 to the 6th power, i.e., millions; decimals indicates the rounding precision of that value and is the source of reasonable tolerance when comparing numbers. Understanding this markup is the fundamental way to sidestep the "thousands vs. millions" trap—magnitude isn't guessed by the model, it's read from the tag.

Should I fine-tune or prompt?

Prompt first. With typed schemas, a few examples, and thinking mode disabled, the models above often meet the bar on stable sections, and you'll learn where they fail. Only consider fine-tuning when evaluations show consistent errors that can't be eliminated through prompting (for example, a model persistently misreading a certain filing layout).

Where to Start

Start with the schema, not the model. Test Qwen3.8-27B for fields that require judgment; choose NuExtract3 for strict templates with abstention; use Qwen3.5-4B for stable, high-volume sections; and GLiNER2 for entity fields. SIE, in Cloud or in your cluster, serves your production document models through a single API.