Invoice Data Extraction: OCR vs AI, With a Sample PDF Test

Invoice data extraction converts an invoice into structured fields such as supplier, invoice number, dates, tax, total, and line items. OCR reads text from an image. An invoice-specific AI model adds field interpretation; a usable digital PDF may already contain text that needs no OCR.

The practical question is where your present process loses correctness. Is the page unreadable, is the right text mapped to the wrong field, or is a correctly extracted value inconsistent with your business records?

We ran a small local demonstration to make those differences visible. It shows why a wrong invoice total can survive perfectly readable text—and why buying a different OCR engine would not fix that particular mistake.

What we actually tested

On October 20, 2026, we created two synthetic invoice cases in one clean layout. Each was saved as a PDF with selectable text and as an image-only PDF. These are fictional documents, with no client or supplier data.

Both cases have a $1,000 subtotal, $80 illustrative tax, and a $1,080 invoice total. The second records a $300 payment, leaving $780 due.

Download the inputs: unpaid text PDF or image PDF, and part-paid text PDF or image PDF.

We used pypdf 6.10.0 to read native text from all four PDFs. We rendered the two original pages at 200 dpi and ran Tesseract 5.5.1 on those two images using English, OEM 1, and PSM 6. The image-only PDFs contain those same page images. These are two OCR runs, not four independent supplier tests.

The reproduction script, full results, and raw unpaid OCR text and part-paid OCR text are available without a form.

Scope: this is a mechanism demonstration, not an accuracy benchmark. We did not test a prebuilt invoice service, an LLM, poor scans, handwriting, multiple layouts, or an accounting-system integration. The simple mapping rules below were written for the displayed labels.

Reading the page worked

Native extraction returned 493 characters from each text PDF and zero from each image-only PDF. That is expected for this construction: the latter files contain an image, without a searchable text layer.

Tesseract’s output contained the invoice number, invoice total, and amount due correctly on both page images. Label-aware rules recovered those three target fields.

This fits the distinction described in pypdf’s text-extraction documentation: reading embedded text is different from recognizing characters in an image. For a clean digital invoice, try the existing text before adding an image-reading step. Check the result, since selectable text can still have missing content or an unhelpful reading order.

Selecting the field still went wrong

We also ran a deliberately simple baseline rule: take the last monetary value as the invoice total. It passed on the unpaid invoice and failed on the part-paid invoice.

The part-paid OCR text contains:

Invoice Total: USD 1,080.00
Payment Received: USD 300.00
Amount Due: USD 780.00

Nothing in that failure requires an unreadable character. The extraction application selected a real number and assigned it the wrong meaning. The unpaid sample hid the defect because two different fields happened to have the same value.

This baseline is intentionally naive; it is not a claim about how commercial parsers work. Its value is diagnostic. A demonstration using only unpaid invoices cannot expose this particular confusion. Include examples where plausible fields differ.

Define the required record before comparing tools

For this part-paid sample, the relevant result is:

{
  "invoice_number": "INV-1043",
  "currency": "USD",
  "invoice_total": "1080.00",
  "payment_received": "300.00",
  "amount_due": "780.00"
}

Keeping total and amount due separate is not a custom invention. Microsoft’s published invoice field schema defines distinct InvoiceTotal and AmountDue fields. Its existence documents intended output; it does not prove that a model will extract them correctly on your documents.

Ask the accounting-system owner which destination field represents the original charge and how existing payments are recorded. Importing a $780 total instead of $1,080 changes the source transaction. Importing $1,080 and separately recording a payment that already exists can create a different error.

That reconciliation requires business-system evidence. A PDF alone cannot establish whether the stated $300 payment is already reflected in your ledger.

For consequential values, retain the source label and location alongside the normalized value. A reviewer should be able to distinguish “the page says 780” from “780 belongs in this field.”

Choose the extraction method by the unresolved problem

Use structured input when it already supplies the record

If a trusted portal, electronic invoice feed, or supported export provides the needed fields, start there. Validate the schema and identifiers, then map the data into the destination.

There is little reason to print structured data into a PDF and infer it again. The structured feed must still be complete and trustworthy; its file format alone does not establish that.

Use native text or OCR with rules for stable inputs

Our label-aware rule solved these samples because the required labels were explicit and unchanged. On an established supplier format, a small parser may be adequate.

Use native text for usable text PDFs and OCR where the needed text exists only in the image. Maintain the mapping separately from character recognition. If the supplier changes Invoice Total to Document Value, a parser requiring the old label should report a missing field rather than substitute another amount.

The recommendation changes when the required formats vary enough that maintaining rules and reviewing misses costs more than a better extraction method.

Evaluate a prebuilt invoice model for recurring field variation

A document model is worth testing when similar business fields appear under different labels or layouts, or when line-item structure defeats your current parser.

Microsoft’s Document Intelligence invoice model, for example, combines OCR with invoice-specific extraction and structured output. That provides a candidate mechanism for the mapping gap. We did not run that model in this demonstration, so we cannot report its accuracy against these samples.

Require the model to distinguish invoice total, amount due, previous balances, tax, and line amounts where your workload contains them. More readable JSON is useful only if the fields represent the intended facts.

Add custom extraction for a specific remaining requirement

Custom logic or a language model can be appropriate for an unusual field, a private item taxonomy, or information spread across attachments. Identify the requirement that the native or prebuilt option fails first.

A custom schema should permit a missing or ambiguous value. Forcing every field to contain something can make an unsupported guess look like a completed record.

This is the same native-first implementation decision: configure an adequate existing capability, integrate the missing path, and build for a demonstrated gap.

Evaluate field meaning, not one overall accuracy score

The next evaluation should use invoices you are authorized to process from your real source population. Our four files cannot establish production readiness.

Start with required fields and a manually checked answer set. Include cases where easily confused values differ: invoice and PO numbers, issue and due dates, total and balance due, one line’s amount and the document total.

Then separate three questions:

1. Did the reading layer recover the text? Compare source text with the native or OCR output. A missing minus sign is a reading issue.
2. Did the extractor choose and normalize the right field? Check the proposed invoice total against the correct source field. A perfectly read balance mapped as total is a selection issue.
3. Can the business accept the proposed record? Compare supplier, duplicates, PO, receipts, currency, and relevant amounts with authoritative records. That is validation.

Google Document AI’s evaluation guidance compares predictions with labeled test documents and reports measures such as precision and recall. Apply that discipline to each consequential field and document group, rather than treating all correct-looking values as equivalent.

Also record reviewer corrections and time. A model that proposes more fields but creates more checking work may not improve the completed process. Use the AI automation ROI model to value usable capacity and actual expense changes separately.

Extraction ends before approval and posting

A successful extractor proposes what the invoice says. It does not establish that the supplier is approved, the payment instruction is legitimate, or the invoice should be paid.

In the sample, arithmetic can check that $1,000 plus $80 equals $1,080, and that subtracting the stated $300 leaves $780. Those checks do not prove delivery occurred or that the payment is valid.

For a limited first implementation, an approved draft record can be a useful destination. Preserve the source, the required checks, and the resulting system ID; ensure a retry cannot silently create a second invoice.

The full invoice-processing implementation guide covers matching, approval and recovery, while the human-review guide explains review authority and evidence. Those are separate workflow requirements, so this comparison does not repeat their complete checklists.

Questions to resolve before buying

Is invoice data extraction the same as OCR?

OCR recognizes characters from images. Invoice data extraction selects and structures business fields, using native text, OCR, rules, document models, or a combination. The demonstration shows both native reading and OCR feeding a separate mapping step.

Does this test show that rules are better than AI?

It shows that an explicit label rule handles two controlled invoice cases and that a last-value shortcut fails one. It does not compare AI performance or varied supplier formats. Use the samples to inspect field definitions, then evaluate candidate tools on a representative set.

What should a vendor demonstration prove?

Ask to see the source, proposed field values, correction path, and final destination record. Include a partially paid invoice or another case with competing amounts. Ask how missing values behave and whether existing payments can be reconciled. The vendor should explain which part was actually executed and which output was only illustrated.

Bring one invoice-handling problem

KelenAI’s invoice processing automation service connects document extraction with the systems and decisions needed to complete AP work.

Submit a workflow consultation request describing how invoices arrive, what staff retype, which values cause corrections, and where the approved result needs to go. You can describe the process without sending confidential invoices. We will review the context and follow up.