OCR promised this for a decade. AI finally does it.

The promise everyone has heard

Anyone who has run a back office has sat through the demo. Scan the invoice, the packing list, the bill of lading, and the software reads it, matches it and files it. The demo document is always clean, typed, and from a vendor whose template was set up in advance.

Then it meets the receiving dock. Forty vendors, each with its own layout. Slips printed sideways. A PO number written as six digits on one vendor’s form and with a prefix on another’s. Handwritten counts in the margin. Two slips stapled together and scanned as one. A bill of lading mixed into the stack. The OCR system reads characters fine and understands nothing, so every document lands in an exception queue, and the team goes back to typing.

Why OCR never got there

OCR turns pixels into text. It doesn’t know that a column labelled “Qty Shp” on one form and “Shipped” on another are the same thing, that “B17348” means a particular purchase order, or that the third page of a scan is the start of a different document. The classic fix was templates: map each vendor’s layout by hand, then maintain the map every time they redesign the form. That works for your top five vendors and fails for the long tail, which is where most of the work is.

OCR reads the page. What the dock needed was something that understands it.

What changed

Current AI models read a document the way a person does. They recognize a packing slip as a packing slip whatever the layout, find the PO reference wherever the vendor put it, read a table without being told where its columns are, and notice the handwritten “11” next to a printed 12. Called through an API from inside the ERP, that understanding is available exactly where the data needs to go, with no templates to maintain.

That doesn’t make it magic, and it doesn’t remove people from the process. It changes what they spend time on: checking a short list of flagged items instead of keying every line.

What receiving does now

We built this into the purchase order receiving screen. The workflow from the dock’s side:

1. Scan the stack. Every packing list from the day’s deliveries goes through the scanner as one PDF. A hundred slips in one file is fine.
2. Drop it in. The receiver drops the PDF onto a Packing Lists tab.
3. It’s split. The scan is divided into individual documents. Anything that isn’t a packing list — a bill of lading, a cover sheet — is set aside and shown, with a one-click “read this as a packing list” if the call was wrong.
4. Each slip is read. PO number, vendor, slip number, ship date, and every line: our part number, the vendor’s part number, description, quantity shipped, quantity backordered, and any handwritten count.
5. It’s matched. The PO reference is normalized to how the business numbers its POs, and each slip line is matched to an open PO line — by exact part number, by the vendor’s part number, by a close match, or by description — with a badge showing how confident the match is.
6. Quantities are pre-filled. Receive quantity defaults to what the slip says shipped.
7. Everything is reviewable. Page ranges, PO number, line matches and quantities can all be changed before anything posts. Nothing is received until a person says so.
8. Receive, then file. When the receipt is created, each slip’s own pages are saved to the vendor’s folder with a consistent name and attached to that item receipt, and the attachment is confirmed rather than assumed.

The flags are the point

Reading the slip is what everyone demos. What saves money is what the system notices:

• The vendor on the slip isn’t the vendor on the PO.
• A handwritten count differs from the printed shipped quantity.
• A slip would receive more than is left open on the line.
• Pages assigned to two slips, or to none.
• Notes on the slip, such as damage or a substitution.
• The same pages have already been received, or are being received on another screen right now — stopped before it can post twice.
• The same document was already filed through another intake path — linked, not duplicated.

Each of those used to be caught by a sharp-eyed person, sometimes, or by accounts payable a month later when the invoice didn’t match. Now they are on screen before the receipt exists.

What it’s worth

• Receiving time drops from keying every line to reviewing a pre-filled screen.
• Every receipt has its paperwork attached, so the three-way match and any vendor dispute start with the evidence already on the record.
• Discrepancies surface at the dock, where they can still be fixed with the driver or the vendor, instead of at month-end.
• Accounts payable stops chasing paper. The slip is on the receipt, the receipt is on the PO, and the bill matches against both.

Why it works when the brochures didn’t

Two reasons. The models finally understand documents rather than just reading characters. And the integration is built around how the business actually works — its PO numbering, its vendor part numbers, its folders, its review step — instead of asking the business to work the way the software expects. The first is something anyone can buy now. The second is the part that takes someone who knows the receiving dock, the purchasing records and the code.

The earlier version of this, for filing every inbound document to its record, is in filing inbound documents with AI.

Related: filing inbound documents with AI, and blanket purchase orders: which release does this invoice belong to?