We taught Claude to read purchase orders, and still made a human sign off

A purchase order would land in a shared Gmail inbox as a PDF. Someone on the operations team would open it, read the order off the page, and retype it into the ERP, line by line, colour by colour, size by size. A few minutes per order, several times a day, every working day. Boring, mechanical, and exactly the kind of work that quietly burns a person out and invites typos into the system of record.

The apparel maker who came to us didn't want "AI." They wanted those minutes back, and they wanted the orders in their ERP to be correct. Those two goals pull in opposite directions, and the whole design is really about holding them both at once.

The problem behind the problem

Reading a PDF sounds easy until you look at an apparel purchase order. It isn't a flat list of items. One line of the order is a colour/size matrix: a grid where "Style 4471, Navy" crosses "S / M / L / XL" with a quantity in each cell, and the next colour starts a new grid below it. A human reads that grid in a second. A naive text extraction flattens it into mush.

So the real task was never "turn a PDF into text." It was: turn a visual grid into structured order lines that an ERP will accept, with the quantities landing under the right size, every time.

And the destination had its own opinions. The orders had to end up in Indigo8, an apparel ERP, in exactly the shape its import expects: the right SKU codes, the right units, the business rules applied. Getting data out of the PDF was half the job. Getting it into a form the ERP would swallow without complaint was the other half.

The approach

We built a straight, observable pipeline: inbox on the left, ERP on the right, one clear seam between each stage.

A watcher picks up new PDFs from a labelled Gmail folder and drops a job on a queue. The raw PDF and its metadata get written to storage first, with a unique ID, before anything else touches them, so every order has an audit trail from the moment it arrives. Claude does the extraction, returning a strict JSON schema rather than free text. A validate-and-map step applies the business rules and reshapes the JSON into Indigo8's import format. Then it stops, and waits for a person.

That pause is the most important box in the diagram.

Why a human is on the gate (on purpose)

The obvious version of this product reads the PDF and pushes the order straight into the ERP. We could have built that in week four. We chose not to, and that's the decision I'd defend hardest.

The ERP is the system of record. A wrong quantity in there isn't a cosmetic bug It's a wrong order, a wrong cut, wrong fabric bought. The cost of a mistake is asymmetric: automating the reading saves minutes, but a bad auto-pushed order can cost days. So in phase 1, every extracted order surfaces in a small review dashboard. A person sees the original PDF next to the extracted grid, approves or corrects, and only then does it move. Low-confidence or failed extractions get routed to a separate queue instead of silently guessing.

The AI's job is to do the typing. The human's job is to be accountable. We didn't want to blur that line until the numbers earned it.

The plan was never to keep a human there forever. It was to measure: run the pilot, watch the weekly extraction-accuracy report, and let auto-push to the ERP turn on in phase 2 only once the corrections trended to near zero. Trust is something you earn with a track record, not something you assume on day one.

What was actually hard

Three things, none of them the part people assume.

The colour/size matrix. Plain extraction kept collapsing the grids. The fix was to stop asking for "the line items" and start asking for the structure explicitly: a schema with colours, sizes, and a quantity per cell, with the model forced to fill it. Show the model the shape you want and it stops improvising. The grid was the difference between a demo and something operations would actually trust.

The mapping, not the reading. Once the JSON was clean, the messy work was translating it into exactly what Indigo8 expects: matching SKUs, applying unit and business rules, handling the orders that don't fit the happy path. This is the unglamorous middle that no demo shows and every real integration lives in.

The boring inbox. Watching a Gmail inbox reliably is fiddlier than it looks: OAuth that doesn't silently expire, deciding between push and poll, not processing the same email twice, retrying without duplicating an order. We leaned on a queue and a dead-letter path so a transient failure becomes a retry, not a lost PO.

Wrapped around all of it: structured logging, alerts on any failed extraction or validation, and a full per-PO audit trail: raw PDF plus extracted data, kept under one ID. When something looks wrong, you can pull up exactly what arrived and exactly what the model made of it.

Where it landed

Phase 1 is live and running through human review. The minutes of manual retyping per order are gone; what's left for a person is a quick glance and an approve (seconds, not minutes), and the orders going into the ERP are checked, not hoped for. The weekly accuracy report is doing its real job: building the evidence base that decides when auto-push is safe to switch on.

The lesson we'd hand anyone automating data entry into a system of record: automate the work, not the accountability, at least not until the data tells you you've earned it. The model was the easy, exciting part. The audit trail, the mapping, and the human gate were what made it safe to run.

---

We design and build document-automation and ERP-integration pipelines like this end-to-end. If you've got a PDF inbox feeding a system someone retypes by hand, get in touch.