OCR and invoice capture: what it solves, and what agents assume

Invoice capture is the process of converting a supplier invoice – a PDF attached to an email, a scan, a photographed sheet of paper – into structured data an accounts payable system can act on: supplier, invoice number, dates, tax, totals, and line items. OCR (optical character recognition) turns the pixels into characters; layout models and machine learning then locate the fields and decide what each one means. Capture is the front door of AP automation, and everything downstream – matching, coding, approval, payment – runs on whatever it extracts.

This wiki describes source-to-pay for companies where AI agents do the operational work – reading documents, matching invoices, investigating holds – and people keep the judgment calls. Most glossaries explain what OCR stands for and stop there. This page redefines invoice capture for that world: a data source with a measurable error profile, whose output an agent verifies before believing.

Modern invoice capture is genuinely good at what it was built for

Header fields – invoice number, date, supplier name, currency, total due – sit in predictable places on most business documents, and modern systems read them reliably. For repeat suppliers, learned templates make extraction close to deterministic: after a few corrected samples, the system knows where this supplier prints the PO number and the payment terms. ML extraction has pushed further, pulling correct fields from layouts the system has never seen, provided the document is a digitally born PDF with real text underneath. A supplier emailing the same ERP-generated PDF every month flows through capture cleanly, and that channel is where touchless invoice processing – invoices that post and pay with no human involvement – actually happens. In the AP automation stack, capture is the foundation layer, and on clean documents the foundation holds.

The trouble for invoice capture starts below the header

Line items carry the data that three-way matching – the line-by-line comparison of invoice, purchase order, and goods receipt – actually consumes, and line items are where documents get strange. The persistent failure surface looks like this:

• Merged and split lines. Two adjacent rows fuse into one description with two part numbers, or one wrapped description splits into two rows, one of them missing its quantity. The extracted table is plausible at a glance and structurally wrong.
• Tables that span pages. Column headers print once on page one; the rows on page three arrive as orphaned numbers assigned to columns by position, and a shifted layout misassigns them.
• Units and pack strings. "40 CS @ 12 EA/CS" describes 480 units packed in 40 cases. Extraction that keeps the 40 and drops the pack string produces a quantity that is faithful to the page and wrong by a factor of twelve.
• Credit memos read as invoices. A credit memo – a supplier document reducing what you owe – shares its layout with an invoice. Miss the document type and a negative amount posts as a positive one, or the same goods appear billed twice.
• Non-PO service invoices. Non-PO invoices from law firms, consultants, and facilities vendors often carry prose instead of a line grid – "services rendered in connection with the Meridian matter, March" – and capture returns a description string where the match process expects quantities and unit prices.
• Stamps, dock notes, and photographed paper. Receiving stamps and handwritten annotations sit on top of printed text, and a PDF that is a phone photo of a paper invoice adds skew, shadow, and crumple. Recognition confidence drops exactly where the operational information – what actually arrived, in the handwriting of the person who signed for it – is richest.

A capture error books itself as somebody else's exception

A misread field rarely announces itself. It surfaces downstream, wearing the label of whatever check it broke. Take the pack string above and run it forward. A distributor invoices 40 CS @ 12 EA/CS of hydraulic fittings at $2.35 per each, extended amount $1,128.00, against a purchase order written for 480 EA. Capture extracts a quantity of 40. The match compares 40 invoiced against 480 ordered and 480 received, and the invoice goes on hold as a quantity mismatch. The hold carries a supplier-facing label, so it travels the supplier-facing lane: AP asks receiving to confirm the count, receiving re-checks the goods receipt and stands by 480, and the buyer emails the distributor, who replies pointing at the pack string: 480 billed. A week of three people's attention has gone into a number the document stated correctly all along.

Why invoice exceptions happen catalogs the upstream causes of holds – stale price masters, invoices sent before goods ship, missing receipts – and capture belongs on that list, yet it almost never appears in the tally. Its errors are booked under other names: quantity mismatch, price variance, duplicate invoice. Nobody audits capture, because its mistakes surface in someone else's queue with someone else's label attached, and every case resolved under that label quietly confirms the wrong diagnosis. The distributor above takes a defect mark on the vendor scorecard for an invoice they wrote correctly.

An agent treats extracted data as a hypothesis

An AI agent works the same queue under a different assumption: the extraction is a claim about what the document says, and claims get tested. When a hold looks inconsistent, the agent's first move is back to the source document rather than out to the supplier. It re-reads the PDF, checks the internal arithmetic – quantity times unit price should equal the extended amount, and the lines should sum to the total – and compares the line against the purchase order and the supplier's historical pattern – this distributor has billed in cases, pack string included, on eleven of its last twelve invoices. In the fittings case that takes seconds: 40 × $2.35 is $94.00, the extended amount reads $1,128.00, and $1,128.00 ÷ $2.35 is 480 – the PO quantity to the unit. The agent repairs the extraction to 480 EA, reruns the match, posts the invoice, and records the correction so the template improves. Only when the document, the arithmetic, and the history all agree does it treat the variance as real and start investigating people. Capture accuracy stops acting as a ceiling on the touchless rate and becomes a prior the agent maintains: strong for the ERP-generated PDF channel, weak for photographed paper, adjusted supplier by supplier as evidence accumulates.

Cut the exception rate by capture channel

One measurement makes this visible, and most AP teams have never run it: exception rate by capture channel. Blending EDI, supplier-portal, emailed-PDF, and scanned-paper invoices into a single rate hides capture problems inside the average. Split it and the pattern is immediate – when the scanned channel throws several times the portal channel's exceptions for the same suppliers and the same goods, the difference is the reading, because the underlying commerce is identical. Two follow-on cuts sharpen it: exception rate by supplier within a channel, where a template that silently broke shows up as one supplier's sudden spike, and the share of "supplier error" resolutions in which the invoice was ultimately paid exactly as submitted, each one a mislabeled extraction or master-data problem. Teams that run them usually find one channel and a handful of suppliers generating most of the queue, which converts a vague accuracy complaint into a fixable list.

Fragment's agents work invoice exceptions with exactly this posture toward captured data. Before disputing anything with a buyer or a supplier, they re-read the source document inside the company's existing SAP or Ariba environment, repair extractions the evidence contradicts, and escalate only the cases that stay ambiguous after document, PO, and supplier history have been compared. See the source-to-pay workflows Fragment covers or watch an agent work a queue in a demo.