PO Reader case study · Sean Kanamori

The problem

Customer purchase orders arrive as PDFs in dozens of different layouts. Someone had to re-key every line (part numbers, quantities, prices, and dates) into a Sales Order by hand.

It was slow, tedious, and easy to get wrong, and every mistake turned into a phone call with a customer.

Before → after

A sample PDF purchase order from a fictitious aerospace company with seven line items — Before: a customer PDF purchase order

The same purchase order extracted into an editable sales order with seven line items totaling $7,174.00 — After: an editable Sales Order, ready to review

↓ Download the sample PO to try it yourself (a fictitious company, made for this demo)

How it works

The PDF goes to Claude as a native document, so there's no separate OCR step, and Claude returns structured JSON for every line item.

Validation rules then clean it up: dates become MM/DD/YYYY, quantities become whole numbers, and prices are filtered to numeric values.

A person reviews and edits the Sales Order cards before exporting to CSV. The AI does the typing, and a human stays accountable for the order.

Lesson from the lab: Large purchase orders were getting cut off mid-response. The fix was raising the output budget from 4,096 to 16,000 tokens. Now even very long orders come through whole. Test with your biggest real inputs, not your tidiest ones.

A closer look

PO Reader upload screen with a drag-and-drop area for PDF purchase orders — Drop in one PDF or a whole batch. Any PO layout works.

Extracted line items with quantities normalized to whole numbers and extended prices — "250.00" and "1,200" become clean whole-number quantities, and the total matches to the penny.

Results

7 / 7line items extracted from the sample PO, total matched

0OCR templates to maintain

100%of orders reviewed by a human