AI Demos Research — the structured-intelligence platform. Every verdict on these pages opens to the execution behind it.
Graded 30 October 2026

Does LlamaParse extract the same field across different layouts?

LlamaParse passed this scenario. It returned the correct identifier, subtotal, tax, and total_due values for all three differently laid out documents, and the three outputs matched the values read from the pages while keeping the same four-field schema.

1 of 1 test case passed

Every test case in this scenario has a result.

Pass rate100%1 of 1 gradable
Coverage1 of 1test case with a result
1PassDid everything it was expected to do.
0FailNo test case failed.
0Not gradableEvery result here could be graded.
0UntestedEvery test case in this scenario has a result.
The pass rate is a summary. The evidence is the test case below: what we sent, what we checked, what the tool returned, and the proof.

The test case

Each test case is judged on its own: Pass, Fail, Not gradable, or Untested. The scenario result above is based on this test case.

Same field across three layoutsPassEvidence
What we sent
Input 1Document (PDF)
Input receipt A: baseline layout with dollar amounts
Open the PDF ↗
Input 2Document (PDF)
Input invoice B: upper-left label and sales tax format
Open the PDF ↗
Input 3Document (PDF)
Input receipt C: stacked ledger with USD amounts
Open the PDF ↗
ConfigurationCaptured file (JSON)
Extraction schema: four required fields
Cited values2 values from this file
properties
{ "identifier_number": { "type": "string", "description": "The receipt or work order number that uniquely identifies this document" }, "subtotal": { "type": "string", "description": "The subtotal amount before tax" }, "tax": { "type": "string", "description": "The tax amount" }, "total_due": { "type": "string", "description": "The total amount due" } }
required
["identifier_number", "subtotal", "tax", "total_due"]
Show the whole file (1 KB)
JSON
{
  "type": "object",
  "properties": {
    "identifier_number": {
      "type": "string",
      "description": "The receipt or work order number that uniquely identifies this document"
    },
    "subtotal": {
      "type": "string",
      "description": "The subtotal amount before tax"
    },
    "tax": {
      "type": "string",
      "description": "The tax amount"
    },
    "total_due": {
      "type": "string",
      "description": "The total amount due"
    }
  },
  "required": ["identifier_number", "subtotal", "tax", "total_due"]
}
Open the JSON file ↗
What the tool returned
JSON
"extract_result": {
  "identifier_number": "RHS-70234",
  "subtotal": "$85.00",
  "tax": "$5.10",
  "total_due": "$90.10"
},

Output record: document A returned all four values

Copied from Output file 1 (JSON), lines 9–14

Open the JSON file ↗
JSON
"extract_result": {
  "identifier_number": "GLR-98213",
  "subtotal": "$210.00",
  "tax": "$17.33",
  "total_due": "$227.33"
},

Output record: document B returned all four values

Copied from Output file 2 (JSON), lines 9–14

Open the JSON file ↗
JSON
"extract_result": {
  "identifier_number": "SPD-2026-0714",
  "subtotal": "USD 150.00",
  "tax": "USD 7.50",
  "total_due": "USD 157.50"
},

Output record: document C returned all four values

Copied from Output file 3 (JSON), lines 9–14

Open the JSON file ↗
Expected vs. Found
✓Expected: The correct value from each document.Found: All three documents returned the right identifier, subtotal, tax, and total values.
Supporting proof
Proof 1Screenshot
Screenshot: document A results and confidence banner
Open original ↗
Proof 2Screenshot
Screenshot: document B results and confidence banner
Open original ↗
Proof 3Screenshot
Screenshot: document C results and confidence banner
Open original ↗
Why this result

It is a pass because the task required the same four fields across three differently laid out documents, and the returned values matched the reference values on all three while the schema stayed unchanged.

Also observed in this test case

Currency format kept. Each returned amount kept the notation printed on its document, including dollar amounts on A and B and USD amounts on C.

Confidence flags shown. The app marked one field on B and two on C below 90%, while the returned values were still correct.

Tested by Rugved Nichite · evidence dated 28 October 2026

Configuration and setup

How this tool was set up for the run and what the test needed in place. Each row is a fact from the run's records; a fact the records do not hold is left out, not guessed.

Software that produced the output
LlamaParse
Build or version
LlamaCloud web app (build v9bc3d1a1); Extract, Agentic tier
Plan or tier
Free plan (20,000 credits)
Model
Agentic extraction tier
Surface
Web app
Set up before the run
Three documents had to be tested under one unchanged four-field extraction schema: a baseline, a variant with different label wording and placement, and a third with a different money format.
Identifier field
The receipt or work order number that uniquely identifies this document
Subtotal field
The subtotal amount before tax
Tax field
The tax amount
Total due field
The total amount due
Tested
28 October 2026 · Rugved Nichite

How this scenario is graded

How we decide Pass, Fail and Not gradable. The same rules apply to every tool tested on this scenario.

How results are decided

Each test case gets one result per tool: Pass, Fail or Not gradable. A test case we haven't run yet shows Untested. There are no partial results.

The rules
  • Pass: the tool did everything the test expected, and nothing it said contradicts the correct answer.
  • Fail: at least one expected behaviour clearly didn't happen; the test case's result says which one and quotes the tool.
  • Not gradable: our evidence couldn't settle the outcome (for example a record we needed is missing). It is never counted as a fail, and the test case's result says what's missing.

Where this sits in the benchmark

This page is one cell of a larger study: one tool, one scenario. Only this benchmark's frame appears here.

LevelNameScope
BenchmarkStructured Document Extraction →19 scenarios · 10 tools
CapabilityField Extraction →
ScenarioThe same field across layouts →
ToolLlamaParse →

History of this result

What has happened to this result since it was first published. Runs and grades are never overwritten: a retest or a re-grade publishes a new result and keeps the earlier one readable.

from the publication record
6 November 2026First publishedStructured Document Extraction v1

Act on this result

Nothing filed here edits the run or the grade. A challenge opens a review, and a review can produce a new run or a re-grade — which becomes the current result and leaves this one in the history.

This matches what I see

You run the same kind of test against your own setup and get the same behaviour.

Agree →
This does not match

Yours behaves differently. Tell us what you got, with a screenshot if you have one.

Disagree →
Point out an issue

Something here is wrong — a reference value, a transcription, a grade.

Report an issue →
Request a retest

On a newer build, a larger dataset, or your own setup.

Request a retest →
We have fixed this

Tell us what changed and we schedule a rerun of the failing test case. The old result stays as history.

Vendor notice →
Filed against this evidenceNothing yet. Challenges, counter-evidence and fix notices appear here with their outcome, and stay on the page after they are resolved.
Cite this result
aidemos.com/benchmarks/structured-document-extraction/results/llamaparse/the-same-field-across-layouts · 1 pass · 0 fail · coverage 1/1 · graded 2026-10-30

The same record is available as structured data through the AI Demos MCP server, with the counts, the coverage and every per-test-case reason carried as fields.

Verify the proof files

These files support this result. Open a file to inspect the original evidence.

Input 1 · Document (PDF) ↗application/pdf · 54 KB
Input 2 · Document (PDF) ↗application/pdf · 8 KB
Input 3 · Document (PDF) ↗application/pdf · 7 KB
Output file 1 (JSON) ↗text/plain; charset=utf-8 · 3 KB
Output file 2 (JSON) ↗text/plain; charset=utf-8 · 3 KB
Output file 3 (JSON) ↗text/plain; charset=utf-8 · 3 KB
Proof 1 · Screenshot ↗image/png · 135 KB
Proof 2 · Screenshot ↗image/png · 139 KB
Proof 3 · Screenshot ↗image/png · 133 KB
File fingerprints (SHA-256)

A fingerprint identifies the exact file used for this result.

Input 1 · Document (PDF)a96bbe1c5b22336e7b54169baf72b85e45eabf1312cd293a1821017b52fa85f7
Input 2 · Document (PDF)4a0b1754da9f52ce35a783d58f8e8a1b5e1353b5b992d5553122886f1cd4a638
Input 3 · Document (PDF)0276d246d69482340b53797f4eaa21831977cede22c8c8f14fc48dbf84757660
Configuration · Captured file (JSON)5eed02263359f834fb4627a052fca7d88d892e785c7bee3d38320e177a2e00b3
Output file 1 (JSON)78a8c120ac84b0f772d0293da71e6fe563f22d731456a73d8aa18c20c282a5bc
Output file 2 (JSON)187b31d4bdea43ce55775b3fe9804ff95d05f7378fc397db43bf74a629fca625
Output file 3 (JSON)cf682e30d1b4c9bf4acd691f430b384fb78d4067f39188638916028fe5a92a58
Proof 1 · Screenshotf5737a1438e5580f5a42387b4412109f82a17c5c8ea3451ce67a40f494178b49
Proof 2 · Screenshot2793f22d6551b0bb0a2d3fa8c042b1c0eca46d108d0a80b2896149fb7dcce853
Proof 3 · Screenshot75667ab33915ef7859d980cad41322d3b1cabb71ca0ef9e46ea0fceedcc07ca9