A null field is not a low-confidence field
Document AI stacks increasingly return two different signals per field: a confidence score when something was extracted, and a null when the model found nothing to propose. Production write-ups in 2026 keep warning the same mix-up — routing nulls into the low-confidence queue as if absence were a shaky guess. On BuilderHelp's supplier-invoice path and Deerman's PO extraction, that conflation wastes reviewers and invents data. A missing remit-to address is a missing-data problem. A blurry total that still produced digits is an uncertain-extraction problem. They need different queues, different questions, and different stop rules.
Absence and uncertainty are different claims
A low-confidence field says: here is a candidate value, and the model is unsure. The review task is confirm or correct against the source crop. The document still offered something to argue with.
A null field says: no candidate. The model did not bind a value to that schema slot. That can mean the page truly omits the field, the layout hid it, the schema asked for something this document type never carries, or the extractor failed silently. None of those cases is fixed by polishing a float that does not exist.
When both land in the same "needs review" column, operators treat null like a blank to fill. They type from memory, from another page in the PDF, or from the last invoice they saw. That is how a missing PO number becomes a confident wrong PO number — the opposite of what a careful pipeline should do.
What goes wrong in a merged queue
Low-confidence totals get the same "look at the page" treatment as a null tax ID. That is fine for the total. For the null, looking at the page often confirms the field is simply not printed — and the useful next step is a missing-data branch: hold the post, request the missing artifact, or mark the field as not applicable for this document type.
Merged queues also poison metrics. Queue length looks like extraction quality. In reality half the tickets may be schema mismatches and absent optional fields, while the other half are genuine uncertain reads. Tuning a confidence threshold to shrink that pile does nothing for the nulls, and can let worse guesses auto-post while optional empties still clog the board.
We have seen the same shape on AP intake: optional freight or remit lines that vendors omit become perpetual "low confidence" chores. Staff fill them with zeros or copy from the wrong header. The model never claimed those values. The queue design did.
Two routes, two reviewer questions
Route low-confidence extractions fields to a confirm-or-correct UI: proposed value, confidence band if you use it for triage, and a tight crop of the source region. Ask whether the digits on the page match the proposal — not whether the reviewer can invent a better number from domain knowledge.
Route nulls on required fields to a missing-data path: show the empty slot, the schema expectation, and enough of the page to prove absence. Allowed outcomes are hold, request document, mark not-on-page with an owner, or reclassify the document type — not "type something in so we can clear the card." Optional nulls should not enter either human queue by default; they stay null and stay out of the post payload.
Keep the signals separate in storage too. Persist extracted value, confidence, and a present/absent flag as distinct columns. Collapsing null into confidence=0 for convenience recreates the merged queue in every report and every webhook consumer downstream.
BuilderHelp and Deerman: required vs optional
On BuilderHelp, a supplier invoice without a usable invoice number or total is incomplete for matching and posting. That is a required null — stop the auto-post path and open missing-data review. A missing freight line on a vendor who never prints freight is an optional null — leave it empty. Dumping both into "review because confidence is low" trains staff to invent freight and to treat a missing invoice number like a fuzzy OCR miss they can guess.
On Deerman, a line that extracts a part code with low confidence belongs next to the manufacturer catalog for confirm-or-reject. A line where the code slot is null is not a soft match waiting for a person to invent a Pfister SKU. It is either a layout miss that needs re-anchor, a description-only line that should stay unmatched, or a document that is not a PO line page. Those are different jobs than polishing an uncertain code.
In both systems the posting path should refuse to treat null-as-zero for money fields and refuse to treat null-as-placeholder for identifiers. Absence is a state. Encoding it as a default value is how quiet corruption enters the ERP.
What we check before calling the review path "done"
Does every field have an explicit present/absent outcome, separate from confidence? Do required nulls open a missing-data workflow with hold semantics, and do optional nulls stay out of the human board?
Can a reviewer clear a low-confidence ticket only by confirming against the crop — and clear a null ticket only by hold, request, not-on-page, or reclassify — with no free-text invent path for identifiers?
If those checks fail, the queue is asking people to finish the model's homework with guesses. Split absence from uncertainty, and both queues get shorter for the right reason: each card finally asks one honest question.
Questions
- Should a null field go to the same reviewer as a low-confidence field?
- No. Low confidence needs confirm-or-correct against a proposed value and a crop. Null on a required field needs a missing-data path — hold, request, or mark not-on-page. Mixing them invites invented values.
- Is null the same as confidence zero?
- No. Confidence zero still implies a candidate that scored badly. Null means no candidate. Storing null as 0.0 collapses two states and breaks routing, metrics, and audit.
- What about optional fields that are often blank?
- Leave them null and out of the human queue. Only required absences should open missing-data review. Optional blanks are normal documents, not extraction failures.
Sources
- LandingAI — Human-in-the-loop review for Document AI — Null returns route to missing-data; low confidence routes to review — do not merge.
- Related: A confidence score is not a gate
- Related: A straight-through rate is not accuracy