Invoice capture: read, match and check

Plan invoice capture as separate decisions: what does the document say, which transaction does it belong to, and does its content fit that transaction? Optical character recognition, or OCR, initially answers the reading question. It does not automatically complete the business comparison.

This example is fictional and limited to references and total amount. Order P-31 belongs to supplier S-4; its agreed total is 120 EUR. Scanned invoice I-22 names the same supplier and order. No extra items or partial payments are included in this example.

Compare captured values with their sources

The captured invoice amount differs from both the original and the order. Processing therefore creates a review task instead of passing the unchecked amount into the ERP as a confirmed liability.

The reviewer sees the relevant image section beside the captured value. They confirm 120 EUR on the original and correct the capture. A draft for 120 EUR can then proceed with a correction note. This resolves the example's reading error; payment approval is a separate later step.

Treat a genuine discrepancy differently

If I-22 actually states 1,200 EUR, the capture must not be changed to 120 EUR merely to fit the order. The document data is preserved. The responsible person checks whether the order, invoice or agreement needs changing. The initial outcome is “business clarification pending”.

If P-31 is missing from the available system, the match is unresolved instead. A clearly read amount does not create a matching order. Record that reason separately so a missing integration is not handled as an OCR failure.

Use confidence for the right question

Microsoft distinguishes word and field confidence, among other scores. A score can help route uncertain recognition for review. It does not confirm agreement with your order. Select thresholds using suitable test cases of your own; do not adopt an arbitrary value as an approval rule.

In a test environment, check the correctly read document, reading failure, genuine amount discrepancy and missing order. Expected outcomes are respectively a draft, correction review, business clarification and unresolved matching. The reason for a hold must be visible in the work queue.

Choose reading technology and the subsequent process appropriately

If an invoice already contains structured data, consider processing that first rather than only reading its rendered image again. Keep the source, corrected value and correction reason linked so that each correction can be traced. A successful import or error-free OCR run replaces neither business checking nor any required format validation. The output here is a checked capture draft, not blanket approval of the entire invoice.

Sources

• Microsoft: Read model OCR

• Microsoft: Accuracy and confidence