Invoice OCR turns the image of a scanned or photographed invoice into text, then decides which text is the vendor, the invoice number, the date and the total. The first step is character recognition; the second is reading the layout. A firm can trust it as far as its checks go: arithmetic, dates and a person reviewing failures.
What invoice OCR does beyond text recognition
Invoice OCR does two jobs. Optical character recognition (OCR) turns pixels into characters, so an image of "1,339.20" becomes the text 1,339.20. Invoice OCR then has to decide that this number is the amount due and not the subtotal, the previous balance or a phone number. Most of the value and errors sit there.
Plain OCR produces a page of text with no meaning attached. The documentation for OCRmyPDF, an open-source tool that adds OCR to PDF files, describes its output as an OCR "layer" added back into the original PDF so the text can be selected, searched and copied, as the OCRmyPDF introduction puts it. That makes a scan searchable. It does not tell anyone which number is the total.
For invoice processing, the text has to become fields. Software reads where each piece of text sits on the page, what label is next to it, and how it relates to the rest:
- A number below or beside "Total", "Amount due" or "Balance due" is a candidate total.
- A date next to "Invoice date" is the invoice date; one next to "Due" or "Payment due" is the due date.
- The largest name and address block near the top is usually the vendor, and a block labelled "Bill to" is the customer.
- Rows inside a grid of columns are line items, not header fields.
The broader difference between plain recognition and software that understands documents is covered in OCR vs intelligent document processing. The same split applies to statements, as the post on bank statement OCR shows for running balances and transaction columns.
Not every invoice needs the first job at all. A PDF produced by a vendor's billing system usually already contains its characters, so no recognition is needed, only the field mapping. How to check which kind of file you have is explained in how to tell whether a PDF invoice has a text layer.
Template-based versus layout-aware invoice OCR
Template-based invoice OCR reads each field from a fixed position set up for one vendor's layout. Layout-aware invoice OCR finds fields by their labels and their place relative to other text, so it can read a vendor it has never seen. Templates are precise until a layout changes. Layout-aware reading copes with variety but needs checks.
A template is a map: on this vendor's invoice, the invoice number is in a box at a certain position near the top right, and the total is in a box near the bottom right. When an invoice from that vendor arrives, the software reads those boxes. For a firm whose client receives hundreds of invoices from one supplier in one fixed format, that works well.
Templates break in predictable ways:
- A new vendor. No template exists, so someone has to build one before the invoice can be read.
- A redesigned invoice. The vendor changes billing systems or adds a logo, and every box moves.
- A longer invoice. More line items push the total further down the page or onto the next page, outside the box.
- A shifted scan. A page fed into the scanner at a slight angle moves every field a little, and the boxes catch the wrong text.
Layout-aware reading looks for the label "Total" or "Amount due" wherever it sits and takes the value next to it. It handles a new vendor on the first invoice. Its weakness is ambiguity: an invoice with a "Total" for the current charges and a "Total" for the account balance gives two candidates, and the software must choose.
An accounting firm sees invoices from many vendors across many clients, often only a few from each. That vendor mix favours layout-aware reading, because building and maintaining a template for every vendor of every client costs more than the reading saves. Whichever method is used, the result needs the same checks.
What affects invoice OCR accuracy on real vendor invoices?
Invoice OCR accuracy on real vendor invoices depends mostly on the input: resolution, skew, fonts, stamps and table borders. A clean PDF from a billing system reads well. A crooked phone photo of a creased, stamped page does not. Any accuracy figure depends on the mix of invoices it was measured on.
The Tesseract project, an open-source OCR engine, lists the main input problems on its page on improving the quality of the output:
- Resolution. The page says Tesseract works best on images of at least 300 dpi. A fax or a small phone photo is often well below that.
- Skew. The page says line segmentation quality drops significantly when a page is too skewed. A photo taken at an angle is skewed.
- Dark borders. Scanned pages often have dark borders, which the page says can be misread as characters.
- Noise. Speckles and uneven brightness from a poor scan or a fax reduce accuracy.
- Tables. The page states that Tesseract has a known problem recognising data in tables without custom layout analysis.
Fonts matter too. Thin, condensed or decorative fonts, very small print in a terms box, and dot-matrix output from older billing systems all produce look-alike misreads: 0 and O, 1 and l, 5 and S, 8 and B, and lost decimal points.
Why accuracy figures do not compare
A single accuracy percentage for invoice OCR says little on its own. It depends on which invoices were tested, whether accuracy was counted per character, per field or per whole invoice, and whether line items were included. A set of clean billing-system PDFs and a set of faxed, stamped pages give very different results from the same software. Without a shared test set, two figures cannot be compared. The practical answer is to test on your own clients' invoices, field by field. How to run that test is part of invoice OCR software requirements for an accounting firm.
What a firm can control is the input and the checks. Ask clients for the PDF the vendor sent rather than a photo of a printout. When a photo is all there is, ask for it taken flat and head-on. Microsoft gives the same advice for Excel's own picture import: its page on inserting data from a picture tells users to avoid images taken at an angle and to review the results and correct them before inserting the data.
Does a firm need an invoice OCR API or an upload tool?
A firm needs an invoice OCR API only if it has developers who will write code to send files and receive data, usually to connect OCR to the firm's own systems. An API (application programming interface) lets one program call another. A firm without developers should use a tool where people upload files and download results.
An API makes sense when:
- The firm has its own software, such as an internal database or client system, that should receive invoice data automatically.
- Volume is large and steady enough that a person uploading files is the bottleneck.
- Someone on staff or on contract can build and maintain the connection, handle errors and watch for changes.
An upload tool makes sense for most firms. Staff or clients send files, the tool reads them, and someone reviews the results and exports a spreadsheet. There is nothing to build and nothing to maintain. The time saved is in reading and sorting, not in moving files between systems.
There is a middle path. Some firms start with uploads and add an API later for one high-volume client. If that is likely, ask whether the same account offers both, and whether the API returns the same fields and checks as the upload tool.
Schema CPA is built around per-client upload links, with API access included on its Practice plan for firms that want to connect it to their own systems. Plans and what each includes are on the pricing section of the homepage.
Invoice OCR edge cases: stamps, handwritten notes and faxed pages
Invoice OCR edge cases are marks and conditions that a clean template never shows: a "PAID" stamp across the total, a handwritten account code, a faxed page with streaks, or a photo with a shadow. Each one causes a specific kind of misread, and each has a quick check that spots it.
Paper invoices collect marks. Clients stamp them "Received" or "Paid", write a check number in the margin, circle the total, or staple a receipt over the corner. All of that lands on the scan.
| Input condition (example) | Reading problem it causes | What to check |
|---|---|---|
| Clean PDF from a billing system | Usually no recognition needed; errors come from mapping the wrong label to a field | Total equals subtotal plus tax and freight; invoice number is the invoice number, not the customer number |
| Phone photo of a printout | Skew, shadow and curved lines cause misread digits and merged columns | Arithmetic on the total; dates in range; look at the image for any field that fails |
| Faxed page | Low resolution and speckle cause 0/8, 1/7 and 5/6 confusion and lost decimal points | Amounts against the vendor's usual range; decimal point position |
| "PAID" or "RECEIVED" stamp | Stamp ink over printed text hides or alters characters, and the stamp date can be taken as the invoice date | Invoice date against the stamp date; total digits under the stamp against the image |
| Handwritten note | Handwriting is read as garbled text, or a handwritten amount is taken as the total | Whether the total came from print or handwriting; ignore margin notes unless they are approved changes |
Two of these deserve extra care. A stamp date taken as the invoice date moves the invoice into the wrong period without any obvious sign. A handwritten figure taken as the total may be a client's note of a partial payment rather than the amount billed. Both pass a quick glance and both fail an arithmetic check against the printed subtotal and tax.
When a page shows several of these conditions at once, ask for a better copy. A vendor can usually resend the original PDF in minutes, which is faster than checking every field of a poor fax.
Receipts bring their own problems, from thermal paper that fades to long, narrow layouts. Those are covered in how receipt OCR differs from invoice OCR. For the difference between a scan and an emailed PDF in more depth, see scanned invoice vs emailed PDF invoice, and for choosing a tool, see how to choose invoice OCR software.