Invoice OCR and extraction

A usable extract is a set of fields a reviewer can open next to the invoice image and confirm on a cited page and line. Header values (vendor legal name as printed, invoice number, invoice date, currency, purchase order number when the document shows one, tax, freight, and the invoice total as printed) and each line item (description, quantity, unit of measure if shown, unit price, line amount, and tax) must carry a citation: which page, and which line or region on that page.

The outcome you are buying is quality, not completeness. If a field is unreadable, it stays empty. Empty is the correct stored value. Inventing a total so the form looks finished is a control failure. Accounts payable still keys the exception. The model does not close the gap by guessing.

Citation is the difference between OCR that ran and an extract AP can use. Without a page and line, a reviewer compares a filled box to a multi-page PDF by eye. With a citation, they jump to the printed source. That is also the audit trail when someone later asks why a total was accepted.

Ingest first. Do not extract from a screenshot in chat or from a file on a shared drive with no message metadata.

Capture the source. Typical intake is a PDF attached to an AP inbox, a vendor portal file saved as PDF, or a multi-page scan emailed as an attachment. Keep the original bytes. If the message is HTML with an embedded image, store that image as the page to cite, not a print-to-PDF that reflows the layout.

Normalize without destroying evidence. Render each page so the vision model sees the same geometry a human sees. Do not crop away letterhead. Do not deskew so aggressively that line numbers drift. Do not merge email body text onto the invoice page unless that body is the invoice.

Run extraction with citations required in the schema. Every field the AP system will store needs a page index and a line or region. Line items are a list, not a paragraph of text. Header total, tax, and freight are separate fields. If the document has no line-item table, return a single line only when the page actually shows that description and amount.

Stop at extract. The record is a proposed invoice, not a posted invoice. Do not write a GL account, do not consume a purchase order, and do not mark the vendor paid.

An invoice pre-flight check belongs after ingest and beside extraction. Wrong legal entity, an attachment that is a statement rather than an invoice, or a file that is not readable as pages should fail pre-flight instead of producing a confident but unusable extract.

Vic.ai, Stampli, Docsumo, and Workday sit in the same class: inbox or upload, model extract, human exception queue. Configure that class so unreadable fields remain blank and so a person must confirm before anything posts. Product names do not replace citation quality on the extract itself.

If the image does not support a value, store nothing for that field.

Blur, a stamp over the footer, a folded scan edge, and a vendor PDF that puts the total in tiny type on a dark band all produce the same temptation: the rest of the invoice looked fine, so the model fills the total from line-item arithmetic. That is inventing a total from a blurry page. It is the failure that most often looks like a successful extract.

Do not fill a missing PO. If the invoice does not print a purchase order number, the PO field stays empty. Match may fail later, and that failure is correct. Inventing a PO from a recent order for the same vendor, from an email subject line, or from a usual PO for that cost center turns a missing-document problem into a false match.

Do not copy a subtotal into the total field because the total line was cut off. Do not copy a prior period's tax. Do not fix a transposed invoice number. Those edits belong to AP at the keyboard, with the image open.

When a field is empty, the exception reason should name the field and the page that was unreadable, not a generic low-confidence flag. Reviewers need to know whether to zoom page 3 or to request a resend from the vendor.

Treating extraction as posted is the second failure that looks operationally convenient. A filled header and a line table in the AP system is still a draft until a person accepts it or keys the blanks.

On an exception, AP opens the cited page and line for every posting-critical field the model filled: vendor, invoice number, date, total, tax, PO if present, and each line amount. AP types values only for empty fields, from the image or from a vendor resend, never from memory of what the vendor usually bills. AP rejects the file if it is not an invoice (statement, packing slip, or contract). AP leaves the draft unposted if the total cannot be read. Do not approve on a line-item sum.

The queue is not a rubber stamp. If citations are missing, send the extract back; do not reconstruct cites by scrolling. If the model filled a total you cannot see on the page, clear that total and treat it as empty even when the model returned a high score.

Posted means the ERP has accepted the invoice under match and payment policy. Extracted means a structured proposal exists. Keep those states distinct in status, permissions, and reports. A dashboard that counts invoices processed as extracts completed will hide unkeyed exceptions and will train the team to trust filled boxes.

Once header and lines are cited, empty fields are truly empty, and AP has keyed or confirmed posting-critical values, the record can move.

The three-way match agent should receive only confirmed quantities, prices, and a PO number that appeared on the invoice or that AP keyed from a valid source. A missing PO must remain missing so match fails closed.

GL coding suggestion can run on confirmed vendor, amounts, and line descriptions. It should not run on an invented total. Coding a guessed amount creates an entry that will not reverse cleanly.

duplicate and fraud detection needs the invoice number and total as printed. An OCR guess that swaps a digit creates both false duplicates and missed duplicates.

Illustrative path, not a measured result: a three-page PDF arrives in the AP inbox. Pages 1 and 2 are sharp. Page 3 is a dark scan of the totals block. The model returns vendor, invoice number, date, and five line items with page 1 and page 2 cites, and it leaves tax and invoice total empty because page 3 is unreadable. AP requests a clear PDF from the vendor, keys tax and total from the resend, and only then releases the draft to match. The wrong path is the model summing the five lines, writing a total, and the invoice appearing ready while the real footer still cannot be read.

Cite what the page shows. Leave what it does not. Let AP type the rest.