Turn PDFs into data: document processing with AI

Somewhere in your business there's a stack of PDFs that someone types into a system by hand. Vendor invoices keyed into the accounting software. Signed forms transcribed into a database. Contract terms copied into a tracking spreadsheet. It's slow, it's boring, and every keystroke is a chance to turn $1,450 into $1,540. Document processing with AI exists to kill exactly this job, and in the last few years it's gotten good enough that small businesses can afford it.

The job: documents in, rows out

The task has a simple shape. On one side, documents that arrive as PDFs, scans, or photos: invoices, purchase orders, intake forms, delivery tickets, contracts. On the other side, structured data: rows in a database or spreadsheet with fields like vendor name, invoice number, date, line items, total. Extraction software reads the document and fills in the fields.

Modern language models changed this space because they read documents more like a person does. Older systems needed the invoice number to be in the same spot on every page. A model like Claude or GPT can be handed a vendor invoice it has never seen, in a layout it has never seen, and asked "return the vendor, date, line items, and total as structured data," and it will usually get it right. That flexibility is the breakthrough: one pipeline can handle invoices from a hundred different vendors, each with their own format.

Accuracy: the honest numbers

Here's the part vendors gloss over. Extraction is very good and it is not perfect. On clean, digital PDFs with clear fields, well-built pipelines get the large majority of fields right. Accuracy drops on messy inputs: skewed phone photos, faded thermal-paper receipts, handwriting, tables that wrap across pages, documents where two different numbers could plausibly be "the total."

What matters isn't the error rate in the abstract, it's what an error costs you. A wrong date on an archived form is trivial. A wrong amount on an invoice that flows straight into a payment run is not. So the design question is never "how do we get to 100%," because you won't. It's "how do we catch the errors that matter before they cost money."

Human-in-the-loop: how real pipelines stay trustworthy

The answer is a review step, and every production document pipeline we'd put our name on has one. It works like this:

• The system extracts the fields and attaches a confidence signal to each document, based on things like whether the math checks out (do the line items sum to the total?), whether required fields came back empty, and whether values look sane (a date in the future, a total ten times this vendor's usual).
• Documents that pass every check flow straight through. No human touches them.
• Documents that fail a check land in a review queue, where a person sees the original document and the extracted fields side by side, fixes what's wrong, and approves. Correcting a flagged document takes seconds; the human isn't retyping, just verifying.

In a typical setup most documents pass straight through and a modest slice needs eyes. The staff time drops from "someone keys everything" to "someone reviews the flagged ones." That's usually an 80-90% reduction in labor, and, counterintuitively, fewer errors than full manual entry, because bored humans typing all day make mistakes too and nobody double-checks them.

When template-based OCR beats an LLM

LLMs are the flexible option, not automatically the right one. Traditional template-based OCR, where you define once that "the invoice number lives in this zone of the page," still wins in specific situations:

• High volume of one fixed layout. If you process thousands of pages a month of the same form, the same layout every time, a template is faster, cheaper per page, and utterly predictable. There's no reasoning involved, so there's nothing to reason wrong.
• Cost at scale. LLM calls are priced per document processed; heavy volume adds up. Template OCR is often cheaper per page once volume is high and layouts are stable.
• Strict determinism. A template extracts the same field from the same spot every time. An LLM's flexibility means its behavior can shift subtly on edge cases. For regulated workflows where you must explain exactly how a value was captured, deterministic beats clever.

The practical rule: fixed layouts and high volume, use templates. Varied layouts, many vendors, or documents where the information moves around, use an LLM. Plenty of businesses need both, templates for the standard forms and a model for everything else, and there's no prize for purity.

How to know it's done right

A document pipeline is working when the manual keying job is gone rather than shrunk to "we still type the hard ones." When every extracted record links back to the original document, so any number can be traced to its source in one click. When the review queue is small, measured, and actually gets worked daily instead of piling up. And when you spot-audit a sample each month and the error rate on approved records is at or below what manual entry used to produce.

If the pipeline just dumps extracted data into your systems with no confidence checks and no review queue, it will work impressively in the demo and burn you within a quarter.

Got a stack of documents and a person who dreads them? Send us a sample of what you're processing and we'll tell you which approach fits and roughly what it would take to build.