Monday, 8:04 a.m. Maria in accounting opens Outlook and watches the unread count climb to 214. Two hundred and fourteen emails; roughly two hundred carry the same payload: a PDF named something like INV_0034821_final_v2.pdf, from vendors who treat file naming as a creative act. This is the raw material of LLM document processing for invoices and PDF extraction: a pile of structured data wearing a costume.

Her job, technically, is accounts payable. Her job, actually, is opening each PDF, finding the vendor name, the invoice number, the date, the line items, and the total, which hides in a different corner of the page for every single vendor, then retyping it all into the ERP. Three to four minutes per invoice. At two hundred invoices a week, that is most of a human week spent moving numbers from one screen to another, badly disguised as accounting.

LLM document processing for invoices works when you treat the model as a very fast reader, not a source of truth: extract into a strict schema, validate every fieldlike a suspicious auditor, and route only the low-confidence weirdos to a human. On clean, native PDFs you can reach ninety-plus percent straight-through processing within a few weeks of tuning. On phone photos of invoices taken from a truck dashboard, you will not, so plan for that ainstead of discovering it in week six.

The PDF pile is a data problem

Look at what Maria actually retypes: vendor, invoice number, invoice date, due date, a handful of line items, subtotal, tax, total. Maybe twelve fields. Every invoice on earth answers the same twelve questions; the only thing that changes is where on the page the answers live and what they're labeled. One vendor writes Amount due, another writes Balance, a third puts the total in a shaded box in the top-left for reasons known only to their 2004 web designer.

Say you're a mid-size distributor running 250 inbound invoices a week. At three minutes each, that's twelve hours of pure retyping, plus the error-chasing tax: the transposed digit that mismatches a PO, the credit memo filed as an invoice, the duplicate that almost got paid twice. Industry rule-of-thumb numbers put manual invoice handling at a few dollars per document once you count the chasing. The work isn't skilled. It's just relentless.

The pre-LLM options were both grim. OCR-plus-templates meant building a template per vendor layout and rebuilding it every time a vendor redesigned their invoice, which vendors do with unsettling enthusiasm. Outsourcing to a data-entry shop meant paying humans elsewhere to do the same retyping, slightly cheaper, with a two-day lag. Both treated the symptom. Nobody questioned why digital documents needed a human photocopier in the middle.

How LLM document processing actually works

Strip away the marketing and the pipeline is almost disappointingly simple. The PDF gets turned into something the model can see, extracted text for native PDFs or page images for scans, and the model gets a prompt that says, roughly: here is a document, here is a JSON schema, fill it in. Out comes structured JSON. Vendor, invoice number, line items as an array, totals as numbers. No templates, no coordinates, no per-vendor configuration.

Calling this "OCR with extra steps" misses the point. OCR answers one question: what characters are on this page? The model answers a harder one, which of these numbers is the invoice total. It reads labels, layout, and context the way a person does. When an invoice shows subtotal, shipping, tax, and total, a template grabs whatever sits at a fixed coordinate. The model grabs the one labeled Total, even if the vendor moved it to a new corner last Tuesday.

That label-reading is also why vendor quirks mostly stop mattering. A new layout used to mean a new template and a ticket. Now it usually means nothing at all; the model just reads it. The quirks that remain are semantic, not visual: the vendor who puts the PO number in the "ship to" field, or lists prices per hundred units. Those you handle in validation, which is where the next section lives.

The pattern that works: extract, validate, review

Every LLM document processing system that survives contact with a real inbox ends up with the same three layers, whether the team planned it or learned it the hard way.

The validation layer is the part demos skip and the part that makes the system trustworthy. It is also mostly ordinary engineering, the same guardrail thinking that separates production agents from impressive demos, as anyone who's read about what AI agents need to survive production will recognize. Models propose; code disposes.

Accuracy numbers you can actually expect

Here are the ranges I'd budget against, drawn from projects across a few industries. Treat them as planning numbers, not promises:

Two traps hide in these numbers. First, demo accuracy versus your-vendors accuracy: demo folders are native PDFs from three polite vendors, while your inbox is sixty vendors, half of them scanning, one still faxing. Run the pilot on your ugliest real folder or the numbers lie. Second, field-level versus document-level: 98% per-field accuracy across twelve fields means roughly one document in five still contains an error somewhere. That's not an argument against the system; it's an argument for the validation layer, which catches most of that twenty percent with arithmetic.

If your documents arrive messy at the source, the same cleanup-first logic applies as in any retrieval pipeline over company data: garbage in, confident garbage out.

Where it breaks

The failure modes are consistent enough to list on one hand. Handwriting is the worst, because models guess, and a guessed PO number is worse than a missing one. Phone photos fail on glare and perspective more than on resolution. Scans of scans of faxes, the pale gray kind where the page number has dissolved, defeat everyone occasionally. And multipart carbon forms, beloved by the trucking industry, are their own circle of purgatory.

Every fix here is boring, and every one works. Ask vendors for native PDFs; you'd be surprised how many will flip a setting in their invoicing software if you just request it. Add an intake rule that flags low-quality scans and sends a polite auto-reply asking for a resend. Route handwriting to a human from day one instead of letting the model practice on it. None of this is glamorous. It moves accuracy more than any model upgrade.

Build vs buy, and what it costs

Buy when your volume is a few hundred documents a month, your invoices are standard, and nobody on your team wants to own a pipeline. Off-the-shelf document AI tools run roughly ten cents to a dollar per page and handle the common case fine. Build when your documents are industry-weird, freight or construction or field services, when extraction must validate against your systems (does this PO exist in the TMS?), or when volume makes per-page pricing sting.

On raw cost, LLM extraction runs about one to five cents per page depending on the model and how much of the page you send. A clerk fully loaded at $28 an hour, doing fifteen invoices an hour, costs you close to two dollars per invoice plus the error-chasing. The build is typically a week or two of focused engineering for the first version, schema plus extraction plus validation plus a review queue, which lands squarely in first-data-pipeline territory for an FDE engagement. The honest math: under a few thousand pages a month, buy. Past that, or past a certain weirdness threshold, build.

Start with one vendor's invoices and your ugliest folder. Measure for two weeks. The pile will tell you everything the demo wouldn't.