Invoice scanning and OCR software: what it reads well, what it misses, and when to add AI

Invoice scanning software turns a paper or PDF invoice into data your accounting system can use. OCR, short for optical character recognition, is the first layer: it converts the image into text. Turning that text into fields such as supplier, invoice number, line items and total takes another layer, which is where template tools and AI extraction differ.

This guide compares the three approaches on the documents that cause trouble, then gives you a field-level accuracy test to run on your own invoices before you pay for anything.

#What OCR does, and what it leaves to you

Plain OCR reads pixels and returns characters, usually with the position of each word. Tesseract, the open-source engine, works this way. Its documentation describes a line-recognition engine and outputs such as plain text, hOCR and TSV, and says nothing about invoice fields (see the Tesseract project page (opens in a new tab)). If you use it, mapping "which number is the total" is your job.

That gap is why packaged tools exist. Some add templates, so you mark where the total sits for each supplier. Others use trained models that find fields without a template. Amazon Textract's invoice operation is one example. AWS documents it as extracting fields from "almost any invoice or receipt without the need for any templates", and it returns a confidence score with each detected value (AWS documentation (opens in a new tab)).

Before you buy anything, note that many PDFs aren't scans at all. A PDF exported from a supplier's billing system carries a text layer, so the characters are already there and OCR isn't needed. Check for the text layer first. Reading it directly is faster and has no recognition errors.

#OCR, templates and AI extraction compared

If twenty suppliers send you 80% of your volume and their layouts never change, templates are cheap and predictable. If you receive invoices from hundreds of suppliers, templates become a maintenance job with no end. That's the point to add AI.

#How each approach handles ugly documents

Clean invoices are easy. These cases separate the tools, and each should be in your test set.

Skewed or rotated scans. A page photographed at an angle stretches the table columns. Most modern tools deskew first, but check how they cope with a 15-degree tilt and a shadow across the page.

Multi-page invoices. Line items continue on page two, with the total on page three. A tool that reads page by page may report page one's subtotal as the invoice total.

Several totals. Invoices often show subtotal, tax, shipping, a previous balance and an amount due, and picking the right one takes layout and context. Template tools get it right for known layouts. Models usually pick well, but a wrong pick looks as confident as a right one, so validate the arithmetic after extraction.

Handwritten notes and stamps. An approver's initials, a "PAID" stamp across the total or a handwritten PO number in the margin confuse every tool. Handwriting recognition is weaker than print recognition. Plan for these to land in a review queue.

Two invoices in one file. Some suppliers scan a month's invoices into one PDF. Split them before extraction, or the second invoice's lines attach to the first.

Mixed languages and scripts. If you receive invoices in Arabic and English, or with right-to-left tables, test those layouts specifically. A tool that handles English well may stumble here.

Credit notes and statements. A credit note has negative amounts and a different meaning. A supplier statement lists many invoices and isn't an invoice at all. Classify the document type before extracting.

#The accuracy test to run before go-live

Vendor accuracy claims come from their own test sets. Your invoices are the test that matters. This is the check we'd run, and you can run it yourself.

1. Collect 300 or more recent invoices from your real inbox, not a cleaned sample. Include bad scans, credit notes, multi-page invoices and your top 20 suppliers in proportion to volume.
2. Have someone in AP label the correct values for each field you'll post: supplier, invoice number, invoice date, due date, currency, subtotal, tax, total, PO number and line items.
3. Run each tool or model on the same set, with the same files.
4. Score each field separately. For every field, count how many were exactly right, right after normalization (for example, "1,250.00" against "1250"), wrong, or missing.
5. Split the scores by source: native PDF, clean scan, poor scan, photo. A single average hides the weak spot.
6. Check the confidence scores. Of the values the tool was 95% sure about, how many were right? If it is wrong on a fifth of them, its scores can't be used to skip review.
7. Count silent errors: wrong values with high confidence that no rule caught. These are the ones that reach your ERP.
8. Set the pass bar before you look at results. For example, "total and invoice number must be right on 99 of every 100 invoices, or below that go to review."

The numbers in step 8 are illustrative. The right bar depends on your risk. An error in an invoice total matters more than an error in a supplier's phone number, so set different bars for different fields.

Key point: Accuracy only means something per field, per source and on your own invoices. A single headline percentage hides the fields that cause payment errors.

#Validation rules that catch what extraction misses

Extraction gives you values. Rules tell you whether to believe them. A short list catches most errors:

• Subtotal plus tax plus shipping equals the total, within a rounding allowance.
• Line totals sum to the subtotal.
• Invoice date isn't in the future, and the due date is after the invoice date.
• The supplier's tax ID or bank account matches the vendor master.
• The PO number exists and is open.
• The invoice number hasn't been seen from this supplier before.

Each rule is plain arithmetic or a lookup. We keep them as rules, not model calls, since you want the same answer every time and a log an auditor can read. Anything that fails goes to an exception queue with the reason attached. Our guide to how to automate invoice processing with AI covers what happens after extraction.

#When to add AI, and when not to

Add AI extraction when:

• You receive invoices from many suppliers with varied layouts.
• You need line items, not just header fields, for PO matching or coding.
• Templates have started to cost more in upkeep than they save.
• Your invoices arrive in several languages.

Stay with OCR plus templates, or take structured data instead, when:

• A few suppliers send most of your volume and never change layout.
• Suppliers can send e-invoices or EDI. Structured data needs no extraction, so ask for it.
• You only need a searchable archive and don't post from the data.

For the wider picture of OCR, intelligent document processing and LLM extraction, see our explainer on intelligent document processing. Our document processing page shows how we build this for finance teams.

#Keep a person in the loop

Even a well-tuned pipeline has a tail of hard documents. Send low-confidence fields and failed validations to a review screen that shows the image beside the extracted values, and log each correction. A good review screen takes seconds per invoice, and the corrections become your next test set.

If you want to know how your own invoices would fare, talk to us. Send a sample and we'll run the field-level test above and show you the results by field and by source.

#Frequently asked questions

#What is invoice scanning software?

It captures invoices from paper, email or PDF, reads them with OCR or AI, and returns structured data such as supplier, invoice number, dates, line items and totals. That data then feeds approval and posting in your accounting system.

#What is the difference between OCR and AI invoice extraction?

OCR converts an image to text. AI extraction goes further and decides which text is the supplier, the invoice number or the total, even on a layout it hasn't seen. OCR is usually a component inside an AI extraction tool.

#How accurate is invoice OCR?

It depends on the scan quality, the layout and the field. Clean native PDFs can be read near-perfectly, while skewed scans, stamps and handwriting reduce accuracy. Don't rely on a vendor's headline figure. Measure per field on a few hundred of your own invoices.

#Do we need OCR if suppliers send PDFs?

Often not. A PDF produced by billing software contains its own text layer that can be read directly. You only need OCR for scanned images and photos, and for PDFs that were flattened into pictures.

#Can invoice scanning software read line items?

Many tools can, though line items are harder than header fields, especially when a table runs across pages or descriptions wrap onto several lines. Test line-item accuracy separately, since it drives PO matching and coding.