Invoice OCR software for scanned invoices, photos and PDFs

Character recognition is not document understanding

Classic OCR converts pixels into a stream of characters with coordinates. Given a clean invoice, it will return every word on the page accurately and tell you nothing about what any of them mean. You get "Total", "1,482.00", "Due", "30/04" and a few hundred other tokens in reading order, which is roughly as useful as a bag of Scrabble tiles.

Invoice OCR has to add a layer of layout understanding on top: grouping tokens into fields, associating labels with values even when the label sits above, to the left, or several centimetres away in a different font, and recognizing that a repeating horizontal structure is a table with rows.

This distinction explains a common failure. A tool reports excellent character accuracy while producing unusable output, because it read every character correctly and assigned half of them to the wrong field. Accuracy at the character level and accuracy at the field level are different measurements, and only the second one affects your ledger.

Scans, photos and native PDFs are three different inputs

A native PDF generated by a billing system already contains a text layer. Nothing needs to be recognized at all. The characters are embedded, and the work is entirely about layout interpretation. These are the easiest documents and, increasingly, the majority.

A scan is an image. Quality depends on the scanner, the original and whoever loaded the feeder. Common problems are skew of a few degrees, speckle from a dirty glass, bleed-through from double-sided printing, and a resolution low enough that decimal points vanish.

A phone photo adds perspective distortion, uneven lighting, shadows from the person holding the phone, and occasionally a thumb. Correcting these before recognition, deskewing, flattening perspective, normalizing contrast, matters more than any single choice made later in the pipeline.

• Skew: pages fed at an angle; rows drift across the table and columns stop aligning.
• Low resolution: under roughly 200 dpi, thin glyphs and decimal separators become unreliable.
• Shadow and glare: phone photos lose whole regions to blown-out highlights.
• Stamps and handwriting: an approval stamp over a total is a genuinely hard case and belongs in a review queue.
• Multi-page documents: a bill that continues onto page three with a table header repeated, or not repeated.

Why template-based systems break

The traditional approach was to define a template per supplier: draw a box around the region where that vendor prints the invoice number, and read whatever falls inside it. On a fixed set of suppliers this works well, and for a while it worked well enough to build an industry on.

It breaks in three predictable ways. A new supplier has no template, so the first invoice from them must be configured by hand before it can be processed. An existing supplier redesigns their invoice, and the boxes silently point at the wrong regions. Which is worse than failing, because it produces confident wrong answers. And a variable-length line-item table pushes everything below it down the page, so a fixed box that worked on a three-line invoice misses on a nine-line one.

Layout-aware models avoid the template step by learning what invoice fields look like in general rather than where one vendor puts them. The practical test during an evaluation is simple: upload an invoice from a supplier the system has never seen and check whether it needs configuring before it produces output.

What confidence means, per field

A single document-level score tells you almost nothing. An invoice where the vendor name is certain and the tax amount is a guess is not "85% confident" in any way you can act on. You need to know which field is the guess.

Per-field confidence is what makes review efficient. If the invoice number, dates and totals are read cleanly and one line-item description is uncertain, a reviewer looks at exactly that description with the source document beside it, fixes it in a few seconds, and moves on. That is a different job from re-checking the whole invoice.

Confidence is also how you set a policy. Many teams route anything below a chosen threshold to review and let the rest pass through, then tune the threshold after watching what actually needed correcting. The right threshold depends on how expensive an error is for you, which is not something software can decide.