Everyone is number one. Let's uncomplicate document extraction.
For teams choosing a document extraction tool. Why the parser in front of the model matters more than the model, with our ExtractBench results and the places we fall short.
Key takeaways
- In one month, 13 OCR and document AI launches made 32 separate claims to be first or state of the art, across about 25 benchmarks.
- The parser matters more than the model. Choosing per page between OCR text, OCR text with the page image, or Markdown took GLM-5.3 Flash from 80.8 to 94.5 on ExtractBench.
- A better model moves you up. The same parser with DeepSeek V4.1 Flash scored 94.7, which would place 8th of 54.
- Every extracted value links back to the exact words and boxes on the page, so people check answers instead of re-typing documents.
- Test any vendor on 20 of your own documents, not on a benchmark someone else chose.
On this page
- A month of number ones
- What a document team actually needs
- Our approach is a smarter parser, so nothing is wasted
- The evidence is the same model on different routes
- Swap in a better model, move up the board
- What "95%" means
- Every answer points back to the page
- Where we are not first
- How to judge any vendor, including us
- Send us 20 of your documents
- Frequently asked questions
Document extraction benchmarks have never been more crowded. In the last 30 days, at least 13 new OCR and document AI models and products launched, and vendors made 32 separate claims to be first or "state of the art" across about 25 benchmarks. Nearly all of those claims are about the model. We think the bigger gains come from what sits in front of it, a parser smart enough that the model never wastes effort on the wrong input.
Get the parser right, and every better model you plug in moves you up. That doesn't mean turning every page into Markdown, or sending whole documents and whole pages as images. It means choosing, page by page, what the model gets. That might be OCR text, OCR text with the page image, or Markdown, whichever makes the most sense for that page. So instead, here's how we actually do it, what it scores, and where we are not first.
A month of number ones
Between October 12 and November 12, 2026, the claims piled up. Every example below comes from the vendors' own pages or the public leaderboards.

- One benchmark, two "firsts" a week apart. On OCRBench v2, one new open model reported 65.9 and said it ranked first. A week later another model called 54.7 on the same benchmark "state of the art".
- One model, two scores. LightOnOCR-3 scores 86.3 on olmOCR-Bench in its maker's blog and 81.2 in a competitor's comparison that rendered the pages differently.
- A claim the leaderboard doesn't show. A launch post claims 96.57 on ExtractBench. The official leaderboard, updated on November 11, puts the top system at 96.17, and the claimed system is not on it.
- Referees who also play. Several of the most cited leaderboards are run by a company whose own product sits at the top.
None of this means anyone is lying. Benchmarks measure different things, and small changes in setup move scores by several points. Every team also tunes for the test it knows best. But a buyer cannot compare two "#1" claims, and most of these numbers say nothing about whether your documents will come out right.
What a document team actually needs
A document team needs three things. Benchmarks mostly measure only the first one.
- The right value in the right field, on documents that look like yours. They might be scanned, rotated or handwritten, and 3 pages or 300.
- A way to check any value quickly, so people can trust what they did not type.
- A price per page that still works at a million pages a month.
Our approach is a smarter parser, so nothing is wasted
Most pipelines treat every page the same way, whether it needs it or not. That is where both money and accuracy leak away. Extraction does not need an exotic model or an agent that runs for an hour. It needs three ordinary parts, and a parser smart enough to give the model exactly what each page needs.
1. OCR that keeps the structure. Our own OCR, SumoOCR, returns every word with its position on the page, plus checkboxes and signatures. It keeps the layout too, so columns stay columns and table rows stay on one line. Everything else builds on this, including the source links described below.
2. A Flash-class model for extraction. Small, fast, inexpensive models like GLM-5.3 Flash are now very good at turning well-prepared input into structured data. They do it at a fraction of the cost of frontier models, and new ones arrive every few weeks. Because the hard work happens before the model, switching to a better one is a configuration change, not a rebuild.
3. The right route for each document. This is where most of the accuracy comes from. We don't turn every document into Markdown, and we don't send every page to a vision model. A fast method built on computer vision and simple algorithms picks the route.
- Short documents go to the model as OCR text and page images together. The text gives exact characters, and the image shows checkboxes, stamps and layout that text loses.
- Long documents go as OCR text. Long tables are mapped first, then read in windows of rows, so a 4,000-row schedule is never squeezed into one answer.
- Pages are rendered at the resolution they need, not one fixed DPI for everything. Dense small print gets more pixels, and a simple form gets fewer.
- Pages with complex tables go to the model as Markdown, or as a high-resolution page image.
- PDFs
- Scans and photos
- Digital files
- 01SumoOCR reads words and boxes
- 02Pick the route for each page
- 03Flash model extracts
- 04Check every answer
The routing itself is a simple, smart method built on computer vision and algorithms, so picking the route stays fast even on a 5,000-page document. It is a separate step, so it can be swapped for an LLM or another smarter system whenever that pays off.
The evidence is the same model on different routes
Routing each document, with the same extraction model, takes ExtractBench from 80.8 to 94.5. That would move it from 37th to 12th of 54 on the public leaderboard. ExtractBench is LlamaIndex's public benchmark of 370 real documents with answer keys. We ran it ourselves with the official evaluator on November 11 and 12, 2026, and these results are not on the official leaderboard. The extraction model is GLM-5.3 Flash in every row below, and only the route changes.
| Documents | One fixed route | Docsumo's route |
|---|---|---|
| Short, 252 documents | 93.1 (OCR text only) | 95.7 |
| Short sample, 24 documents | 86.0 (page images only) | 93.1 |
| Medium, 98 documents | 51.6 (one call with images) | 92.4 |
| Long, 20 documents | 27.8 (one call with images) | 88.4 |
| All 370 documents | 80.8 (one call with images) | 94.5 |
The model did not change. The route did. Scores are value F1. The one-call figures for medium, long and all documents are the leaderboard's own GLM-5.3 Flash entry, run at maximum reasoning effort, and ours ran at low effort.
Swap in a better model, move up the board
Because the parser does the hard work, the model is a part you can swap. We ran the same parser with a second Flash model, DeepSeek V4.1 Flash, and changed nothing else about how documents are prepared.

Both models jump when they sit behind the parser, and the better model lands higher. GLM-5.3 Flash takes us to 12th, and DeepSeek V4.1 Flash to 8th. DeepSeek did need a few safeguards of its own, such as a retry when it spends its whole answer budget thinking. The leaderboard ran DeepSeek alone with reasoning off, and ours used low reasoning. Every new Flash model is another chance to move up, without a rebuild.
What "95%" means
95% of the 370 documents score 80 or higher, 83% score 90 or higher, and none score below 50. A single average hides a lot, so here is the spread by kind of document. These are short documents read as OCR text plus page images, and a document can fall into more than one kind.
| Kind of document | Documents | Value F1 |
|---|---|---|
| Clean digital | 116 | 97.7 |
| Photos and rotated pages | 23 | 96.5 |
| Scanned | 116 | 93.6 |
| Handwritten forms | 55 | 93.1 |
Field-level and document-level accuracy are different things. A 300-field financial statement at 99% per field comes out fully correct only about 5% of the time. That is why the next part matters as much as the score.
Every answer points back to the page
Because we run our own OCR, every value we extract is tied to the exact words it came from and their bounding boxes on the page. Click a total and you see it highlighted on the invoice. Click a row in a 40-page schedule and you land on that line.
| Field | Extracted value | Read |
|---|---|---|
| Vendor name | Northeast Kitchen Equipment | |
| Invoice number | NKE-9921 | |
| Invoice date | 2026-08-12 | |
| Due date | 2026-09-11 | |
| Payment terms | Net 30 | |
| PO number | 5498 (handwritten) |
| Field | Extracted value | Read |
|---|---|---|
| Vendor address | 37 Bridge St, Westbrook, ME | |
| Bill to | Harbor Street Bakery LLC | |
| Ship to | 22 Thames St, Portland, ME | |
| Remit to | PO Box 3170, Portland, ME |
| Field | Extracted value | Read |
|---|---|---|
| Item code | WT-3072 | |
| Description | Stainless work table, 30 x 72 in | |
| Quantity | 2 | |
| Unit of measure | EA | |
| Unit price | 385.00 | |
| Amount | 770.00 |
| Field | Extracted value | Read |
|---|---|---|
| Subtotal | 23,250.00 | |
| Sales tax rate | 5.5% | |
| Sales tax | 1,278.75 | |
| Freight | 121.25 | |
| Total due | 24,650.00 |
This is what makes extraction usable in practice.
- Reviewers check, they don't re-read. They look at the few values that seem unusual, each one a click away from its source.
- Auditors see where every number came from, down to the word on the page.
- Mistakes are obvious. When a value is wrong, you can see where it was read and why.
Our take. We'd put a good model inside a good harness, with every answer checked, retried when broken and linked to its source. Then people stop re-typing documents. They look only at the few values that seem unusual, and clean documents go straight through. That is touchless processing, with no re-keying, fewer slips than manual entry, and a person only where a person is needed.
A score tells you how often extraction is right across a benchmark. A link from every answer to its words lets you check any answer on the document in front of you.
Where we are not first
Our best run, with DeepSeek V4.1 Flash, would place 8th of 54 on ExtractBench, 1.5 points behind the top system, at about a seventeenth of its cost per page. With GLM-5.3 Flash we would place 12th.

- Cost. The top system costs 7.5 cents a page. Ours costs 0.32 cents with GLM and 0.43 cents with DeepSeek, which is 0.1 cents for parsing plus the model at its list price. Every system that scores higher than either run costs between 3 and 19 cents a page.
- A better model has a bigger bill. DeepSeek scores higher than GLM but writes 2.4 times as many output tokens, so it costs 37% more per page and takes longer.
- Long documents are our weakest area, at 88.4 with GLM and 86.8 with DeepSeek.
- Short documents. The same model reading page images alone at maximum reasoning effort scores 96.3, slightly above our 95.7 at low effort. Low effort is faster, at 25 seconds per short document against 58.
How to judge any vendor, including us
- Test on 20 of your own documents, not on a benchmark someone else chose.
- Ask for document-level accuracy, not only field-level.
- Give them your longest document and time it.
- Click a value and see whether it takes you to the page it came from.
That is the whole idea. Build a parser smart enough to waste nothing, use a fast model you can swap for a better one, and keep an answer you can check. Do that, and the leaderboard takes care of itself.
Send us 20 of your documents
We'll run them through the same parser and show you the results, with every value linked to its source. Book a demo to set it up, or start a free trial and upload them yourself.
Frequently asked questions
What is ExtractBench?
ExtractBench is LlamaIndex's public benchmark of 370 real documents with answer keys. It scores how well a system pulls out the values a schema asks for, document by document.
Does a better LLM fix document extraction on its own?
Only partly. In our runs the same Flash model went from 80.8 to 94.5 when the parser prepared each page better. A better model then added a little more on top.
Should every PDF be converted to Markdown before extraction?
No. Markdown helps on pages with complex tables. Converting every page, or sending whole documents as images, wastes effort and can lose detail, so choose per page.
How should I compare document extraction vendors?
Test on 20 of your own documents and ask for document-level accuracy. Time your longest document, and check that every value links to its source. Book a demo to run that test with us.