A document queue is not a field queue
When an OCR pipeline needs a person, the default product shape is still a document inbox: open the PDF, skim every extracted field, approve or fix, next. That feels thorough. It is usually the wrong unit of work. On BuilderHelp's supplier-invoice path and Deerman's manufacturer PO intake, most exceptions are one or two fields — a total that does not sum, a remit-to that failed a check, a part code that did not reconcile. Dumping those into a full-document review queue trains reviewers to re-read pages that already passed, burns the same attention on cosmetic noise, and still fails to give them a better tool when the whole page really is broken.
Two units of work, two questions
A field queue asks: is this value right for this region of the page? The reviewer sees the proposed string, a crop or highlight of the source, and a short reason it arrived — low confidence, failed arithmetic, catalog miss, rule breach. They confirm, correct, or mark absent. Everything else on the document stays out of the task.
A document queue asks: can this page be trusted as a whole? Type unclear, layout fingerprint drifted, too many correlated failures, unknown vendor template, or a high-stakes post that needs a full pass. The reviewer is doing classification and re-anchoring, not ticking one total.
Those are adjacent pipes. Mixing them into one "needs review" column is how a transposed tax amount becomes a twenty-minute re-audit of a clean header — and how a vendor redesign sits in the same list wearing the same label as a single low score.
What breaks when everything is a document
Throughput collapses for the wrong reason. Industry write-ups keep showing the same pattern: field-level review with grounding is fast because the task is narrow; document-level review is slower because every field becomes optional theater. If one failing field always escalates the whole invoice, your straight-through rate looks worse and your reviewers learn to rubber-stamp the fields that were never in doubt.
Signal also dies. Corrections that should teach a per-field threshold or a vendor-specific map get logged as "document fixed." You cannot tell whether people keep changing remit-to or whether they only ever touch line totals. The queue stops being training data and becomes a blob of completions.
Worst case, the UI invites re-litigation. A person who already trusts the vendor name and PO number still has to scroll past them on every exception. Fatigue sets in, and the one field that needed attention gets the same half-second glance as the ones that did not.
When the whole document still belongs in review
Field routing is the default, not a dogma. Escalate the document when type is unknown or contested — invoice vs credit vs quote — because the wrong verb makes every field dangerous. Escalate when layout drift tags a vendor cohort: the geometry moved, so individual confidence scores are lying about the same systematic miss.
Escalate when failures cluster. Three line items that fail reconcile on one page is rarely three independent typos; it is a table that shifted. Escalate when the post is high-consequence and your deterministic checks cannot cover the risk, or when a null on a required identity field means the page may not be the document you thought.
Those paths need their own labels and owners. A "full exception" queue next to a "field exception" queue is clearer than one inbox with a severity emoji. Same-day disposition still applies — neither queue is a parking lot.
How we shape the queues on live intake
BuilderHelp's AP mailbox is mixed: invoices, credits, statements, delivery tickets. Classification and type-specific posting come first. After that, money-moving fields that fail named checks — totals that do not sum, tax that breaks an invariant, remit-to that fails a rule — open as field tasks with the crop beside the value. Supporting pages stay attached as evidence without inventing a voucher or forcing a full re-key.
Deerman's PO path is reconcile-led. A part code that does not resolve against the manufacturer catalog is a field problem with a concrete question. A batch from one vendor that suddenly misses the same columns in the same week is a document or template problem — pause auto-post for that fingerprint, re-anchor, then resume. Confidence can order which field task surfaces first. It does not decide whether the whole PDF is the work item.
Downstream posting stays gated the same way we already insist: a corrected field is preparation for a post, not a silent rewrite of something already committed. The queue shape does not replace reversal discipline; it decides how much human attention you spend before the first post.
What we check before calling review "designed"
Every exception has a reason code that maps to field or document — not a generic "low confidence." Field tasks show source grounding and only the contested keys. Document tasks name why the whole page is open: type, drift, cluster, or policy.
Operators cannot approve a field task by editing unrelated fields as side effects, and cannot close a document exception by confirming a single crop while type is still unknown. Corrections write back per field with before/after so thresholds and templates can learn.
If those checks fail, you have a PDF inbox with a nicer header. The useful discipline is simple: route the smallest unit that answers the risk, keep full-document review for when the page itself is the question, and stop making every exception reopen the whole extract.
Questions
- When should a low-confidence field escalate the whole document?
- When failures cluster, type is unclear, layout drift is suspected, or policy requires a full pass for that document class. A single contested total or remit-to should stay a field task with grounding — not a mandate to re-audit every header field.
- Isn't document review safer?
- It feels safer and usually burns attention on fields that already passed checks. Safety comes from named gates, type classification, and escalation when the page is systematically wrong — not from forcing a full re-read on every exception.
- How does this relate to confidence scores?
- Scores can help prioritize which field task to show first. They should not be the sole reason a whole document enters a shared inbox. Named checks and reason codes decide the queue; scores order work inside it.
Sources
- TrueOCR — Human review without slowing operations — Straight-through vs targeted field review vs full document exception as separate routing levels.
- Invoice OCR accuracy — field-level vs document-level review — Field-level review as the efficient default; document-level for correlated or high-stakes cases.
- LandingAI — HITL review with field grounding — Route uncertain fields with bounding-box citations; keep null/missing on a separate branch.
- Related: A confidence score is not a gate
- Related: A null field is not a low-confidence field