What will document AI
actually get right?
Estimate document-level extraction accuracy, expected human-review volume, blended latency, and total cost per document — using field count and confidence thresholds instead of a single headline accuracy number.
Field-level accuracy compounds across every field on a document. See the real straight-through processing rate before committing to a rollout. No account is required, and calculations run in your browser.
Your documents
Review & processing cost
Benchmark results
Sensitivity — straight-through rate by field count
| Fields / doc | Straight-through rate |
|---|
"97% accurate" rarely means
97% of documents.
Vendor and model accuracy claims are almost always reported per field, on a benchmark set that may not resemble your documents. A document with many fields compounds that per-field error quickly: at 97% field accuracy, a 12-field document is fully correct only about 70% of the time, and a 25-field document drops below 50%.
The number that matters operationally isn't field accuracy — it's how many whole documents can go straight through without a human touching them, and what the remainder costs to review. This benchmark models that gap before a pilot meets production document volume.
What this benchmark
calculates.
Combines document volume, fields per document, baseline field accuracy, confidence threshold, field flag rate, review time and cost, and processing cost and latency.
Returns: document-level accuracy, straight-through processing rate, monthly documents requiring review, blended cost and latency per document, and the levers with the largest effect on each.
How the
calculation works.
Four steps from field accuracy to a monthly operating number.
document accuracy = baseline field accuracy ^ fields per documentdoc review rate = 1 − (1 − field flag rate) ^ fields per documentdocs reviewed = monthly volume × doc review rate, costed at the review minutes and hourly rate entered.The variables with
the largest impact.
The single biggest driver of compounding error. Splitting a long form into fewer, higher-value required fields — and treating the rest as optional — often improves straight-through rate more than improving the model.
Measure this on your own representative documents, including poor scans, unusual layouts, and edge cases — not only clean examples. A benchmark set that's easier than production will overstate the real rate.
Raising the threshold catches more true errors but also flags more correct-but-uncertain fields for review. Tune it against the cost of an undetected error, not a fixed target.
Directly drives review volume. A model that is accurate but poorly calibrated can still flag far more fields than necessary — calibration matters as much as raw accuracy.
Shaped heavily by UI design — a review screen that highlights only the flagged fields with source-document context is much faster than one requiring a full manual re-check.
Volume doesn't change the straight-through rate, but it determines whether the review team can absorb the flagged volume without becoming the bottleneck.
What the benchmark
includes — and doesn't.
This models extraction, review, and cost based on the values entered. A production rollout may also need:
- Document classification and routing before extraction
- Multi-page stitching and table/line-item parsing
- Handwriting, multi-language, or low-resolution scan handling
- Downstream business-rule validation beyond field confidence
- Reviewer training, tooling, and queue management
- Exception handling for documents that fail classification entirely
- Ongoing accuracy monitoring as document sources change
- Change management for the team currently doing manual entry
When to run
this benchmark.
- Before committing to a document AI vendor or model.
- When a pilot's accuracy claim needs translating into operational terms.
- Before sizing a human-review team for a new document workflow.
- When deciding whether to simplify a form to improve straight-through rate.
- After changing a confidence threshold or extraction model.
- When moving from a narrow document-type pilot to broader document types.
Before you commit
to a rollout.
Why is document-level accuracy lower than field-level accuracy?
If each extracted field has a small independent chance of being wrong, the chance that every field on a document is correct shrinks quickly as the number of fields grows. A document with 12 fields extracted at 97% field accuracy is only fully correct roughly 70% of the time, not 97%.
What should I use as the field flag rate?
Use the observed rate of fields falling below your confidence threshold from a representative sample of your own documents. Without a sample yet, estimate conservatively and re-run the benchmark once real extraction results are available.
Does a higher confidence threshold always improve quality?
A higher threshold routes more borderline fields to human review, which tends to raise accepted accuracy but also raises review volume and cost. The right threshold depends on the cost of an undetected error versus the cost of review.
Does this calculator include OCR or layout-parsing cost?
Cost per document is whatever you enter for your actual pipeline — OCR, layout parsing, and model inference combined. The calculator does not model those sub-costs separately. See our Document AI page for architecture guidance.
What about scanned, handwritten, or low-quality documents?
Baseline field accuracy should reflect the real document quality in production, not a clean benchmark set. Scanned, handwritten, multi-language, or low-resolution documents typically need a separately measured accuracy rate.
Does Dwayo store the values entered?
The calculation runs in your browser. Values are only shared with Dwayo if you choose to save an estimate or request an engineering review. See our privacy policy.
A useful benchmark depends on
representative documents.
Run the benchmark against documents that match your real production mix, not a vendor demo set. If the accuracy or review-volume numbers are a concern, a Dwayo engineer can review the extraction architecture before rollout.