The PO That Arrived as a PDF

Part 2 of 10 – inbound order intake

The lever is accuracy, not speed, and the human-review step is the product.

It is 3:50 on a Tuesday afternoon at Spiese Fluid Power, and Marie has forty minutes to save a shipment.

The order came in as a PDF, attached to an email, from a customer who has bought from Spiese for eleven years and has never once used the web portal. It is on their letterhead, not Spiese's form. Fourteen line items. Three of them reference the customer's own part numbers, not Spiese SKUs. One line just says "same bracket as last time." The quantities are in a column that is almost lined up with the descriptions. There is a handwritten note near the bottom that may or may not be a delivery instruction.

Marie has done this ten thousand times. She will key it in about six and a half minutes, get thirteen of the fourteen lines exactly right, and catch the "same bracket as last time" by remembering the account herself. If she gets it in before the 4:00 cutoff, it ships tonight.

This is the single most automatable thing Spiese does. It is also the one where getting it slightly wrong is most expensive. Both of those are true at once, and the whole design of the solution follows from holding them together.

What it costs today

Spiese takes about 184 orders a business day. Roughly a third of them – 62.5 a day, 15,630 a year – arrive the way Marie's did, as an email with a PDF or an image attached. Someone keys every one by hand.

At six and a half minutes each, that is 1,693 hours a year of inside-sales time spent retyping documents, or about $87,000 in loaded labor. Call it the price of a full-time person who does nothing but transcribe.

Then there are the mistakes. At a keying error rate of 2.5% – one line in forty, which is good for manual entry – Spiese ships about 391 wrong orders a year off these PDFs. Wrong quantity, wrong part, wrong ship-to. Each one costs something to unwind: an expedite, a return, a credit memo, a call from an unhappy customer, sometimes a restock. Put a conservative $185 on the average and that is another $72,000 a year.

So the honest baseline is not the $87,000 everyone sees. It is about $160,000 a year, and nearly half of it – the $72,000 – is the errors, not the typing. That is the part nobody budgets for, because it never shows up on one line.

(Every figure here is on the numbers page. The keying error rate is the number the whole case rests on, so it is worth grounding: published studies put manual data-entry errors in the low single digits – one peer-reviewed study measured 3.2–3.7% per entry – which makes 2.5% for orders that ship wrong a conservative choice. Still, the number that matters is your own, from your credit-memo history; it moves this total more than anything else here.)

Where the boundary sits

This is a systems-of-inference problem in its purest form, and it maps cleanly onto the two machines.

The PDF is ambiguous, messy, human input – exactly what the inference layer is good at. Reading the document, matching "same bracket as last time" to a real SKU, lining up the quantities with the descriptions: that is language work, and a model is very good at it.

But the sales order that comes out the other end has to be arithmetically perfect and auditable – exactly what the system of record is for. The price comes from the ERP's contract pricing, not from whatever number is printed on the customer's PDF. Availability comes from the ERP. The credit check is the ERP's. The order lands in the ERP through the same order-entry logic Marie's keystrokes go through, with the same validation.

The AI reads. The ERP decides. A human approves the exceptions. Nothing about that sentence is negotiable, and the rest of the post is really just consequences of it.

What the AI does – and what it must never do

Does: takes the inbound email and its attachment, and produces a draft sales order. It extracts each line – quantity, unit, the customer's description, the customer's part number. It proposes a Spiese SKU for each line, with a confidence. It flags the "same bracket as last time" line as low-confidence rather than guessing. It hands back a structured draft, every field tagged with where it came from in the original document.

Must never do:

• Never invent a price. The number on the customer's PDF is a data point, not the price. If the customer's price and the ERP's contract price disagree, that is an exception for a human – not a silent override in either direction.

• Never create the order directly in the database. It proposes; the ERP's order-entry service disposes, with all its normal validation.

• Never resolve a part number it isn't sure of. A confident wrong SKU is worse than an admitted "I don't know" – because the confident one ships.

• Never auto-release anything on credit hold, or anything below its confidence threshold. Those route to a person, every time.

That last cluster is the whole game. The failure mode of this workflow is not slowness – it is a plausible, confident, wrong order that no one looked at. The design exists to make that specific outcome impossible.

The plumbing

In most ERPs this is less exotic than it sounds, because most of the pieces already exist.

The orders arrive in a monitored mailbox. Something has to pull the attachment, hand the document to an extraction model, and get back structured lines – that is the one genuinely new component, and it is a service call, not a rebuild.

Everything after that is the ERP you already own. The proposed SKUs get validated against the item master. Pricing, availability and credit come from the same service programs order entry already calls – exposed as APIs if they aren't already. On the IBM midrange this is unusually cheap: Db2 for i is directly SQL-queryable, and Integrated Web Services turns an existing program into a REST endpoint – both ship with the platform, so there is no middleware to buy. The draft order stages in a review queue. On approval, it goes in through the real order-entry path, so the audit trail, the journal, and every downstream trigger behave exactly as if Marie had typed it.

The model never touches the ERP database directly. It reads a document and returns a suggestion. The system of record does everything that has to be true.

Failure modes and guardrails

Three things will go wrong, and the design has to answer each one before go-live, not after.

The confident wrong answer. The model reads "1,000" as "10,000." Guardrail: every extracted field carries a confidence, low-confidence lines force review, and – this is the important part – the ERP's own edits still fire. A quantity that blows past normal order size for that customer gets caught by a rule, the same rule that would have caught Marie's typo. The model does not get to bypass the checks that already protect you.

The silent miss. The model drops a line entirely, or misses the handwritten delivery note. Guardrail: reconcile the line count and flag any free-text region it didn't map to a field. "There is writing here I didn't use" is a message the reviewer needs to see.

Drift. A big customer changes their PO template and extraction quality quietly falls. Guardrail: log accuracy per customer over time and alert when it slips. Silent degradation is the thing that turns a working system into a liability eighteen months in.

The reviewer – Marie, for now – is not there to rubber-stamp. She is there to be handed the six orders out of a hundred that actually need a human, instead of keying all hundred.

How you'd know it worked

One number, measured before you build anything: inside-sales touch time per PDF order. Today it is six and a half minutes of full keying. The target is that most orders need a fast glance and an approve, and only the genuine exceptions need real work.

Here is the honest version of the math, and it is not the story you would expect.

Suppose 55% of orders come through clean enough to approve at a glance, the exceptions take three minutes each to review, software and API cost $18,000 a year, and – the number that matters most – the residual error rate falls to 1.2%. Then the after-cost is about $71,000 a year, against $160,000 today. An $89,000 saving, about 56%, and roughly two-thirds of a person's time handed back to more useful work.

(All four of those assumptions are unverified. They are the softest numbers in the model, and the honest answer is that we do not yet know them for your shop. That is a pilot's job, not a spreadsheet's.)

But look at what the $71,000 is made of. The review labor is only about $18,000. The software is $18,000. The remaining $35,000 – very nearly half of the entire remaining cost – is residual errors. Orders the system got wrong and shipped anyway.

That is the counterintuitive heart of this post. The lever is not speed. It is accuracy. If extraction is fast but no more accurate than Marie, you have spent $18,000 on software to move the error cost around, not remove it. A version of this that keys orders in two seconds and is wrong 2.5% of the time is worse than Marie, because it is wrong at scale and no one was watching. The entire return depends on the residual error rate being genuinely low – which means the human-review step is not a temporary training wheel you remove later. It is the product.

(The same point, from the other direction: Shashi Bellamkonda notes that the companies pushing AI-written code hardest – Anthropic, Google, Cisco – are strengthening human sign-off as they scale, not removing it.)

Monday morning

You do not need an extraction platform to start. You need to know what you are dealing with.

Pull ninety days of these emails and answer three questions. How many orders really arrive this way – is it a third, or is that just the impression? How many distinct customer formats are behind them, because ten formats is a very different project from two hundred? And what is your actual keying error rate, which you can estimate from credit memos and corrections against orders keyed?

That last number is the one to get before you spend a dollar. It sets the entire baseline, and it decides whether this project pays for itself or just relocates the cost. Everything else in this post is downstream of knowing how often the current process is quietly wrong.

Then run one customer. Pick the highest-volume PDF sender, wire up extraction for their format alone, keep every order under human review, and measure two things for sixty days: how much faster it is, and – far more important – whether it is more accurate than the person it is helping.

If it is, you expand. If it is not, you have learned that for the price of a pilot instead of a platform. That is the whole point of starting with what you have.

Spiese Fluid Power is fictional – a composite built from published industry benchmarks and anonymized operating ratios. Its full operating profile, with sources, is published separately.