OCR Before Routing: Treat Extracted Fields as Suggestions

Separate reading from deciding

Optical character recognition can turn a scan into searchable text, but a readable field is not necessarily the correct field for the next action. Consider a packet with a customer name on a cover sheet and a different name inside an attachment. An extraction tool may return both accurately while leaving the business question unresolved. Design the workflow so OCR proposes values and identifies their locations; a defined rule or person determines which value belongs in the packet.

Choose a small set of fields that matter to the workflow, such as recipient name, document date, or purchase-order reference. For each field, define its preferred source and what to do when that source is absent. Avoid asking the agent to fill every blank from surrounding context. A blank or conflict flag can be more useful than a plausible-looking value that obscures the need for review.

Keep the source visible to reviewers

A reviewer should be able to compare the proposed value with the page or region from which it came. Show the document name, page, extracted text, and any relevant neighboring text. This is especially important when a scan contains tables, handwriting, stamps, or repeated labels. A field displayed without its source can invite a quick approval even when it was taken from the wrong section.

Confidence can help prioritize review, but it is not proof that an extracted value is right for the business purpose. Microsoft’s Document Intelligence guidance describes estimated confidence for predicted words and fields, notes that not every field returns a score, and recommends considering human review in critical workflows. Test extraction quality on the actual document mix rather than borrowing a threshold from a different use case.

Route uncertainty deliberately

Define review triggers for missing fields, conflicting values, unexpected document types, poor image quality, and values that would change the destination or contents of a packet. A high-confidence OCR result can still require review if two source documents disagree. Conversely, a low-confidence field that has no bearing on the next step need not block the entire workflow. The question is what decision depends on that field.

Make the correction process easy to trace. If a person changes an extracted value, record the corrected value and the reason in a form the next team can understand. Do not silently overwrite the original extraction in the review view. Keeping proposal and correction distinct helps teams find recurring scan or template problems without implying that every correction reflects a model failure.

Pilot on the documents you really receive

Collect a permitted, representative test set that includes clean digital files, scans, rotated pages, and the attachment layouts that routinely reach the team. Compare proposed values against a human-checked reference for the fields that drive routing. Include cases where the appropriate outcome is “cannot determine.” The pilot should test whether reviewers can catch consequential errors within the workflow, not just whether text appears on a screen.

Review the exceptions after the pilot: which fields were routinely ambiguous, which source rules helped, and which documents should bypass automated extraction? Improve the intake instructions or review interface where those changes are simpler than adding another model. Measure whether OCR reduces retyping on your documents, and keep uncertain fields visible to a person before the next action.

Sources and further reading

• Microsoft Document Intelligence: Accuracy and confidence scores
• Microsoft Document Intelligence transparency note