Cost Per Correctly Extracted Field: The True Parser Metric
By Sygnet Research, checked before publication

Key takeaways
- A parser's list price per page tells you almost nothing: in a RAG pipeline the dominant cost is the human minute spent fixing or verifying a wrong field, not the API call.
- The right unit is cost per correctly extracted field (CPCF): total pipeline cost divided by the number of fields that survive validation, not the number produced.
- Published per-page rates span more than an order of magnitude for the same page, with LlamaParse modes running from 1 credit/page (Fast) to 45 (Agentic Plus), a 45× spread, so any quote without a named mode is meaningless.
- Field accuracy differences of a few points matter more than price differences of 10×: on RD-TableBench, table similarity scores range from 90.2 (Reducto) down to 74.6 (LlamaParse) and 60.2 (Unstructured).
Why is cost per page the wrong unit for a RAG pipeline?
Because pages are an input unit and your pipeline is judged on outputs. A 40-page insurance claim might contain 60 fields you care about and 35 pages of boilerplate you never query. Paying $0.01 per page is irrelevant if the three pages carrying the table of loss amounts come back with merged columns.
Parsing quality propagates. If parsing produces incorrect structure (misaligned tables, merged columns) or chunking disrupts logical units, the retrieval component may simply fail to return the information needed for a correct answer (arXiv 2604.12047). That failure is invisible in your parsing bill and extremely visible in your eval suite. Worse, the ceiling is low even with perfect inputs: on FinanceBench, handing GPT-4-Turbo the exact pages holding the answer still left 15% of questions wrong (HackerNoon). Starting from a degraded parse puts you well below that.
Pages are what you buy; correct fields are what you actually consume.
What does "cost per correctly extracted field" mean?
CPCF is the fully loaded cost of your ingestion pipeline divided by the number of fields that pass validation, per document type. Formally:
CPCF = (C_parse + C_retry + C_review + C_reindex) / (N_fields × accuracy)
The denominator is where teams cheat. If a parser emits 60 fields per claim at 92% field-level accuracy, you have 55.2 usable fields, not 60. The 4.8 bad ones don't cost zero; they cost a reviewer's attention, or they silently poison a retrieved chunk.
A worked example at 100,000 pages/month, 15 fields per page:
- Parser A: $0.01/page, 94% field accuracy. Parse = $1,000. Usable fields = 1,410,000. Parse-only CPCF = $0.00071.
- Parser B: $0.056/page, 98.5% field accuracy. Parse = $5,600. Usable fields = 1,477,500. Parse-only CPCF = $0.0038.
On parse cost alone B looks 5× worse. Add review: at 30 seconds per flagged field and €35/hour loaded cost, A's 90,000 bad fields cost roughly €262,000 to triage, B's 22,500 cost about €65,000. B wins by a wide margin. The crossover depends entirely on your review rate, which is why the extraction accuracy evaluation checklist should be run before, not after, the procurement decision.
What do per-page list prices actually look like in 2026?
Published rates cluster between $0.0015 and $0.06 per page, with structured field extraction at the top. The table below uses vendor-published figures as reported in October 2026; verify against current pricing pages before budgeting.
| Option | Published rate | What it covers | Accuracy signal |
|---|---|---|---|
| Azure Read (OCR) | $1.50 per 1,000 pages (S0, US East) | Raw text, no fields | Text only, no table structure |
| Azure Layout / prebuilt | $10.00 per 1,000 pages | Tables, invoice/receipt/ID fields | 82.7 table similarity on RD-TableBench |
| Azure custom extraction | $30.00 per 1,000 pages | Your own trained fields | Needs labelled training data |
| LlamaParse Fast | 1 credit/page, ~$0.00125 | Plain text, no AI layout reconstruction | Not usable for tables |
| LlamaParse Agentic Plus | 45 credits/page, ~$0.056 | Tables, diagrams, images | 74.6 on RD-TableBench |
| Unstructured PAYG | $0.03/page after 15,000 free pages/month | Partition + load ETL | 60.2 on RD-TableBench |
Two traps worth naming. First, SKUs stack: a scanned invoice needing line items and reliable low-quality-scan reading is Prebuilt ($10) + Layout ($10) + high-resolution add-on ($6), so $26 per 1,000 pages (parsli.co). Second, failures still bill. On LlamaParse's quota model, failed parse attempts (malformed PDFs, timeouts, parsing errors) still consume quota, so your effective rate is list price divided by success rate. A 6% hard-failure rate turns $0.056 into $0.0596 before anyone looks at the output. LlamaExtract-Agentic failed 9.8% of documents on LongExtractBench.
How do you measure field accuracy without building a gold set that costs more than the parser?
Sample stratified, label once, reuse forever. You do not need 10,000 annotated documents. For most production document types, 150 to 300 documents stratified by layout family, scan quality and language gives you field-level accuracy with confidence intervals tight enough to make a vendor decision.
Label at the field level, not the page level. For each target field record: present/absent in the source, value extracted, exact-match or normalized-match verdict, and the page/bbox provenance. Normalization rules (dates, amounts, VAT numbers) must be fixed before labelling or you will spend the whole evaluation arguing about 1 234,56 versus 1234.56.
Page-level benchmarks do not substitute for this. OmniDocBench's end-to-end score is computed as the mean of (1 − text edit distance)×100, table TEDS and formula CDM (OmniDocBench), which is a good proxy for document reconstruction and a poor proxy for "did we get the policy number right." TEDS rewards structural similarity of the whole table; your pipeline may only need four cells from it. We wrote about this gap in why table parser benchmarks fail RAG accuracy.
A parser that scores 95 on a public benchmark and 78 on your own 200-document sample is telling you something true about your documents, not something false about the benchmark.
Which cost components do teams systematically forget?
Four, in rough order of size: human review, re-ingestion, retries, and evaluation maintenance. Human review dominates at almost any realistic volume. Price it explicitly: flagged-field rate × seconds per field × loaded hourly cost. If your parser returns no per-field confidence, your review rate is effectively 100% of fields for any field that carries financial or legal consequence, and the parser's price becomes a rounding error.
Re-ingestion is the sleeper. Change your chunking strategy, switch embedding models, or add a field to the schema, and you reparse the corpus. A parser with a 48-hour cache helps here: LlamaParse re-parses the same file for free within 48 hours because results are cached by default, which covers a tuning loop but not a six-month schema migration. Budget at least one full corpus reparse per year.
Retries and dead-letter handling need a line too. Documents that fail hard need routing, storage and eventually a human. Pipelines that treat failure as an exception rather than a steady-state percentage will blow their budget the first time a client sends 4,000 phone-camera scans. The RAG document ingestion checklist covers the operational side of this.
When is the cheapest parser the right answer?
When the documents are born-digital, single-column, table-free, and the downstream task tolerates noise. Internal wikis exported to PDF, press releases, clean contracts without schedules: run text extraction, spend nothing, move on. Open benchmarks show pdfplumber reaching 93.4% TEDS on table extraction across 353 documents (PDF-Bench), which is a reminder that free deterministic tools are strong on well-formed digital tables.
The economics flip when scans, nested headers, multi-column layouts or handwriting appear. OmniDocBench results make the ranking brutal: Unstructured-0.17.2 scored 0 on English table TEDS and 0.064 on Chinese, while MinerU-pipeline-2.1.1 reached 77.4 and PaddleOCR PP-StructureV3 reached 77.2. A tool that returns nothing usable for tables has an infinite cost per correct field on table-heavy documents, whatever its page price. Route by document class instead of standardizing on one parser: classification is cheap ($3.00 per 1,000 pages on Azure) relative to over-parsing everything with an agentic mode.
Sygnet builds document extraction with per-field confidence and provenance, which is the input CPCF needs; our view on model families is in OCR vs VLM, and the trade-offs of running this yourself in build vs buy IDP.
FAQ
How do I calculate cost per correctly extracted field in practice?
Take one month of real production volume. Sum parser spend, retry spend, reviewer hours × loaded rate, and amortized reparse cost. Divide by (fields produced × measured field accuracy) from a labelled sample of 150-300 documents of that type. Do it per document class: invoices, claims and KYC packs will differ by 5× or more, and a blended number hides exactly the workload that is killing your margin.
Is a 2-point accuracy gain worth paying 5× more per page?
Usually yes at production volume. At 15 fields per page and 100,000 pages a month, two points of field accuracy is 30,000 fewer wrong fields. At 30 seconds of review each, that is 250 hours a month. The parser price difference on the same volume, moving from $0.01 to $0.056 per page, is $4,600. The arithmetic rarely favours the cheap parser once review is loaded in. Run your own numbers with the ROI calculator.
Do public benchmarks like OmniDocBench predict performance on my documents?
Partially. OmniDocBench provides Chinese-English pages with fine-grained annotations and a unified scoring protocol, and is an excellent stress test for end-to-end parsing, but it is restricted to two languages and largely to clean or semi-clean scans. If your corpus is French handwritten medical forms or phone-camera delivery notes, treat public scores as a shortlist filter and your own labelled sample as the decision.
One email when we publish something worth your time.