Invoices, Receipts, Contracts: Handing Documents to AI

We covered invoice reading and reconciliation specifically for accounting professionals in a separate piece: AI for Accountants. This piece starts somewhere different: not one profession, but any business's operations, procurement, or HR team dealing with a pile of invoices, receipts, contracts, and delivery notes, and the technical architecture (how OCR and LLMs play different roles) behind processing them. It's the second piece in our automation series.

OCR and LLMs actually do different jobs

OCR (character recognition) is a deterministic process: it first does layout analysis, splitting a document into text blocks, tables, and image regions, then recognizes the characters in each region. Simply put: OCR is the eyes, it answers "what characters are in this image", but not "is this number VAT or the total." On well-scanned, clean documents, OCR alone can reach close to 99% accuracy.

An LLM is the contextual layer, the brain: it reads a document as a whole rather than piece by piece, semantically working out which part is the invoice number, which is the supplier name, which is the due date. It handles template variation, irregular layout, and lower-quality scans more gracefully than OCR alone. Common practice in 2026 combines both: OCR extracts header fields (invoice number, date, total) while the LLM parses line items. Newer "vision language model" (VLM) approaches process the image directly, merging both steps into a single pipeline.

A concrete example: picture a supplier invoice with a logo at the top, a table in the middle (product, quantity, unit price, total), and VAT plus a grand total at the bottom. OCR can read every character in that image correctly but has no idea which number is "unit price" and which is "total", it just dumps the characters in sequence. Once an LLM steps in, it reads the table the way a person would: it looks at column headers, works out which number belongs to which column, and turns that into structured data ("product: X, unit price: Y, total: Z"). Thinking of these as two separate steps makes it easier to ask the right question when evaluating a tool: does it just do OCR, or does it also structure the output?

Which tool actually does what?

A few general-purpose (not industry-specific) document processing tools: Klippa handles invoice, receipt, and general document OCR with an SME-friendly interface, starting at a few cents per page. Rossum offers "template-free" capture aimed at enterprise, starting around $300/month. Docsumo offers flexible AI models for invoices and financial statements, starting around $299/month. Nanonets claims 93-96% accuracy out of the box, 98%+ with custom training, starting around $499/month on a credit-based model. Lido is a budget option with 50 free pages, starting around $29/month. Enterprise tools like ABBYY/Kofax come with custom pricing running into the thousands per month for high volume.

Before comparing prices, ask the more important question: does this tool only do OCR, or does it also handle structuring and classification? Some cheap "OCR" tools genuinely just dump text and leave structuring and ERP export to you, meaning you'll need to build an extra automation layer (n8n, Zapier) on top. Miss this distinction in your comparison and you may end up doing far more technical setup than you expected.

Contract analysis is a separate category

Contract analysis sits at a different, riskier difficulty level than invoice reading: it requires legal risk interpretation rather than numeric field extraction. Tools like Ironclad, Juro, Kira (for due diligence), Spellbook (embedded in Word, with 2,300+ contract-type playbooks), Evisort (post-signature contract intelligence), and LegesGPT (a self-service option starting around $19.99/month) flag risks like unlimited liability clauses, auto-renewal traps, and missing provisions, tagging clause by clause (termination, liability cap, indemnification). Gartner projects that by 2027, 50% of organizations will use AI-assisted contract risk analysis. Modern platforms claim under 6% error rates on clause tagging, that's a vendor claim without independent verification, read it with caution.

Human review matters even more here than in invoice reading. An invoice error is usually limited to a single numeric discrepancy; a missed "auto-renewal" clause or an unnoticed "unlimited liability" phrase can turn into a serious legal or financial problem years later. Treat these tools as a pre-filter that flags what a lawyer should look at first, not a replacement for the lawyer.

How accurate is this, really?

Combined with validation rules and human review of low-confidence fields, systems can reach 95-99% accuracy; automation alone, without humans, can't reliably get there. A properly built human-in-the-loop process can lift accuracy from around 80% to 95%+. The critical piece is calibrating your confidence threshold: set it too high (98%) and errors slip through; set it too low (50%) and the review queue floods, pushing people into "rubber stamp" approvals that quietly lower accuracy. The practical approach is a per-field confidence score, only uncertain fields go to a human, the rest passes automatically. In a well-tuned system, teams stop spending most of their time on data entry and instead spend it on the 10-20% of genuinely "contested" cases, a supplier dispute, a missing PO number, a price mismatch.

The LLM's hidden risk: hallucination

Worth being careful about this one. Unlike OCR, LLMs don't fail obviously, they present a wrong output just as confidently as a correct one: misreading "rn" as "m", a shifted decimal point, a fabricated figure. In a financial context that's especially dangerous, because the error doesn't look like an obvious mistake, it looks like correct data. That's why feeding invoices directly to a bare, general-purpose LLM (plain ChatGPT, say) is considered high-risk for professional accounting and finance workflows, purpose-built or hybrid tools (like the ones above) are preferred.

Concrete example: a supplier invoice total of $1,575.00 could get misread by an LLM as $15,750.00 with the decimal point shifted, and the system presents that number with full, unwarranted confidence. An OCR error in the same spot usually shows up as garbled, obviously-wrong characters and gets caught easily; an LLM error shows up as a plausible-looking but wrong number, much harder to spot. For high-value transactions, we'd recommend a cross-check rule, automatically verifying the stated total against the sum of line items, as a safety net.

How does this connect to your ERP?

Common ERPs include SAP, Microsoft Dynamics, and a range of regional/local platforms; integration method varies by system (OData/IDoc/custom API for SAP, service- or file-based transfer for many regional ERPs). The typical flow: structured data from the document-processing system gets pushed into the ERP via a periodic service, missing vendor records get auto-created, documents post as invoice or delivery-note entries, but final approval on the record usually stays human (a "prepared by / approved by" pattern). Most tax authorities also require a mandatory e-invoicing compliance layer built into any serious ERP, worth checking what that looks like in your jurisdiction specifically.

3 common mistakes

The most common mistake: writing extracted data straight into the ERP with no validation or error-handling step, uncertain fields need a manual review path. The second: trying to automate too many document types or processes at once, teams get overwhelmed, training stays incomplete; it's safer to focus on one high-impact scenario first (say, supplier invoices only) and expand gradually. The third: assuming "OCR alone is enough", OCR only converts an image to text, it doesn't classify or organize the data, you need a tool that also handles classification and integration.

Frequently asked questions

Which document type should a small business start with?

Start with your highest-volume, most repetitive document type, usually supplier invoices. Move to riskier, more nuanced categories like contract analysis only after you've run the system reliably on invoices for a while.

Do I need a technical team to set this up?

Usually not for a tool like Klippa or Lido, setup happens through the interface. A custom integration into your specific ERP (writing automatically into SAP or Dynamics, say) benefits from an experienced integrator, it saves time in the long run.

What should you actually do?

• Start with your highest-volume, most repetitive document type, usually supplier invoices.
• Calibrate your confidence threshold carefully, too high hides errors, too low turns your team into rubber stampers.
• Don't feed financial documents to a bare chat assistant, choose a purpose-built or hybrid tool.
• Always add an approval step before extracted data gets written into your ERP.
• Run the system on invoices for a month or two before moving into riskier categories like contract analysis.

Document processing is one of the most mature, fastest-payoff corners of process automation, but the gap between "fully automatic" and "human-assisted automatic" is a genuine trust question here. A properly calibrated system moves your team's time away from data entry and toward the decisions that actually need a human.