Features
Built for documents that matter.
Most extraction tools optimize for the demo. We optimize for the production requirement: every value traceable to source, uncertainty surfaced honestly, no third-party data exfiltration. Here's what that actually means.
Signature feature
Visual field-picker
Upload a sample of your document. Draw a bounding box around each field you want extracted. Name it, set its type (text, number, date, currency, enum, table), optionally anchor it to a nearby label so the engine finds it even when the value position drifts.
That set of definitions is a Template. Save it once and run thousands of similar documents through it — clean structured data out, consistent column names, consistent types, ready for downstream systems.
- Draw, don't code — no JSON schemas, no regex
- Anchor-based matching handles position drift between similar documents
- Six field types: text, number, date, currency, enum, table
- Templates are versioned — edits create v+1, existing batches stay reproducible
Template fields
- invoice_numbertext1.00
- invoice_datedate0.99
- due_datedate0.96
- vendor_nametext1.00
- bill_totext0.98
- subtotalcurrency0.99
- taxcurrency0.97
- totalcurrency0.97
Every value links back to a region in the source — and to the model + version that read it.
Anti-hallucination spine
Verbatim grounding.
Every value the engine extracts must point back to a source span in the original document. The LLM doesn't invent — it finds. Values that can't be grounded are dropped (default) or routed to the human-review queue (configurable per template).
This isn't a feature toggle. It's structural. The is_grounded column on every extraction defaults to false — only flipped to true after a real source span is located. A crashed extraction can never accidentally surface an ungrounded value.
- Direct verbatim match → highest confidence
- Fuzzy match (1–2 char edit distance) handles OCR noise like O↔0, 1↔l↔I
- Semantic match grounds typed values (date "Jan 5" → 2026-01-05 → source token)
- No match → drop or route to review. Never invent.
Extracted field
confidence 0.97 · grounded ✓
Source span
page 1 · bbox (412, 891, 88, 18) · text matched verbatim
Quality boundary
Human-in-the-loop, by default
Confidence below the template's threshold? That field surfaces in a review queue with the source region highlighted on the original document image. The reviewer sees the field name, the engine's best guess, and exactly where it came from. One click to approve, one to correct.
Corrections feed back as exemplars that improve future extractions for that template. This is what separates "OCR with confidence scores" from a usable production workflow.
- Configurable confidence threshold per template (default 0.75)
- Source-region highlight on the page image, with text snippet context
- Per-field review — only the uncertain values, not whole documents
- Corrections logged to the audit trail (who, when, before / after)
Review queue · 3 fields
- invoice_date0.68
06/15/2026
date ambiguity (US/EU)
ApproveCorrectView source - tax0.71
$2,967.30
OCR uncertainty: 7 vs 1
ApproveCorrectView source - vendor_id0.62
AC-2024-1109
no clear anchor label
ApproveCorrectView source
Languages we actually support
Honest multilingual tiering.
Every competitor markets "100+ languages." Most of those claims fall apart on real documents — bad accuracy, broken bounding boxes for right-to-left, no Indic support at all. We label by maturity instead.
Stable means production-ready, validated. Beta means clean documents work; bring yours. Experimental means active development, accuracy varies. You always know which is which.
- Latin (Tesseract): English, Spanish, French, German, Italian, Dutch, Portuguese — all stable
- CJK (PaddleOCR): Chinese Simplified + Traditional, Japanese, Korean — stable
- Indic (Surya): Hindi, Marathi, Tamil, Telugu, Bengali, Punjabi, Gujarati, Kannada, Malayalam — stable to beta
- Arabic-script (Surya): Arabic, Persian, Urdu — stable to beta
- Hebrew + Thai + Khmer + Vietnamese — beta
- Cyrillic + Greek (Tesseract): Russian, Ukrainian, Bulgarian, Serbian, Greek — beta
- 35+ languages across 12 script families. See /languages for per-language accuracy notes + caveats.
- English
- Spanish
- Chinese (Simp)
- Chinese (Trad)
- French
- Vietnamese
- Korean
- Tagalog
- Portuguese
- Arabic (RTL)
- Hindi
- Punjabi
- Tamil
- Telugu
- Bengali
Beyond clean printed text
Handwriting + degraded scans.
Handwriting is its own problem. Tesseract degrades to 12% CER on cursive — useless. We solved it with three distinct tiers, each routed to the engine that handles that script class best.
English handwriting (Latin / Cyrillic / Greek) uses a fast vision model at 5 credits/page. Non-English handwriting routes by script — Gemini Flash for CJK (NLS 0.899 on Japanese handwriting), GPT-4o for Arabic / Hebrew, Qwen3-VL for Indic. Mixed-language handwriting (bilingual forms, immigration docs) runs a dual-engine pipeline so each script gets the right reader.
- HW-EN: Latin / Cyrillic / Greek handwriting — 5 credits/page
- HW-NE: per-script routing (Gemini Flash for CJK · GPT-4o for Arabic / Hebrew · Qwen3-VL for Indic) — 15-25 credits/page
- HW-ML: whole-page dual-engine for mixed-script documents — 30 credits/page
- Hardcoded rule: GPT-4o never processes handwritten CJK (documented hallucination risk)
- Low-confidence handwriting routes to review with the source region highlighted
Handwritten signature field
Signature
Extracted: J. Müller · confidence 0.78 · grounded ✓
confidence 0.78 < threshold 0.80
→ routed to review queue for confirmation
Forensic-grade provenance
Audit trail.
Every field carries its full lineage: which OCR tier ran, which model + version, the confidence score, the source page and bounding region, any human correction (who, when, before, after). All written to an append-only event log.
This is what makes the product auditable, not just accurate. Regulated workflows (legal, medical, financial) need to reconstruct exactly why any field reached its final state. The audit log is that reconstruction.
- Append-only — events are never updated or deleted
- Indexed by extraction, field, template, time, and event type
- 15+ canonical event types covering OCR, extraction, grounding, review
- Export-ready for compliance, SOC 2, HIPAA workflows (managed-deployment tier)
Audit log · extraction d8f3...4a91
- 14:02:01.341document_uploadedinvoice_07.pdf · 3 pages
- 14:02:02.118language_detectedscript=Latin · lang=en · 0.99
- 14:02:03.005ocr_tier_passedtier=1 · confidence=0.94
- 14:02:08.622extraction_field_extractedtotal · method=llm · 0.97
- 14:02:08.847grounding_passedtotal · edit_distance=0
- 14:02:09.011extraction_completed7 fields · overall=0.95
What runs under the hood
Progressive OCR cascade.
Right tool for the document. Cheap, fast engines first. Quality gates escalate to heavier engines only when needed. Born-digital PDFs never touch a model. Clean Latin scans run Tesseract. CJK printed text uses PaddleOCR. Indic + Arabic + Thai + Khmer route to Surya. Handwriting + complex layouts go to vision-LLM.
On Precision mode (Enterprise), two independent vision-LLM passes run on each document. Field-level reconciliation flags disagreements for human review with both candidate values surfaced — no silent guessing about which value is right.
- Tier 0: embedded PDF / Word / Excel text — 1 credit/page
- Tier 1: Tesseract — 7 Latin languages, 2 credits/page
- Tier 2A: PaddleOCR — printed CJK (Chinese / Japanese / Korean), 5 credits
- Tier 2B: Surya — printed Indic + Arabic + Thai + Khmer + Vietnamese, 5 credits
- Tier 3: vision-LLM — handwriting + complex layouts + fallback, 5–25 credits
- Tier 4: dual-pass reconciliation (Enterprise Precision), 40–80 credits
Cascade flow
- Tier 0free
Embedded text
pypdfium2
- Tier 12 credits
Tesseract
Latin scripts
- Tier 25 credits
PaddleOCR + Surya
CJK / Indic / Arabic / Thai
- Tier 35–25 credits
Vision-LLM
Handwriting + complex layouts
- Tier 4your labor
Human review
queue with source highlight
Quality gate at each tier decides whether to escalate or stop. Cheap tiers run first.
For developers
Public API.
Every feature of the product is available over a documented REST API. Generate API keys in the dashboard, pick a tier (Standard / Premium / Premium + multi-pass), integrate from any stack.
Webhooks fire on batch completion. Rate limits scale with your plan. Idempotency headers on every endpoint. OpenAPI spec at /docs.
- REST + JSON, OpenAPI 3.1 spec, Swagger UI at /docs
- Per-key API keys with scopes and rotation
- Webhooks for batch completion (HMAC-signed)
- Tier-aware rate limits (60 → 6,000 req/min by plan)
- Idempotency keys to make retries safe
Quick start
curl -X POST https://docuextract.ai/v1/extract \
-H "Authorization: Bearer $DOCUEXTRACT_API_KEY" \
-H "Content-Type: application/pdf" \
-H "X-Template: tpl_acme_invoices" \
-H "X-Tier: premium" \
--data-binary @invoice.pdf
# → { "fields": [...], "audit_id": "...", ... }Bring your own template, or use a public one from the gallery.
How we compare
The combination is the moat.
Almost every individual feature exists somewhere. No competitor combines them all: visual picker + HITL + verbatim grounding + honest multilingual labeling + per-field source provenance. That's the gap we're built into.
| Capability | DocuExtract | Typical competitor |
|---|---|---|
| Polished visual bounding-box picker | ||
| Integrated HITL review queue | ||
| Verbatim grounding (no-hallucination as guarantee) | ||
| Honest multilingual tier labeling | ||
| Multi-pass LLM agreement | ||
| Custom-template visual editor | ||
| Public API + documented OpenAPI spec | ||
| Per-field source provenance (page + bbox) | ||
| CSV + JSON export with audit trail | ||
| Async batch processing |
"Typical competitor" abstracts across Nanonets, Sensible, Rossum, Docparser, Hyperscaler APIs. Individual competitors may match on a given row; none match on the full set.
Try it on your documents.
50 free documents per month covers a real evaluation, not just a toy. Paid plans start at $99/mo when you need more.