Introduction
Now we finally read the ingested fax order PDF with AI. The goal of this stage is to convert an order sheet a person can understand into data the system can handle directly (JSON).
"Reading" sounds simple, but it turns out to be surprisingly deep. This article covers the prompt design for having an LLM (Claude) structure a form, and the validation design for turning the extracted result into something trustworthy.
Why Extract with an LLM
Forms Are More "Varied" Than You'd Think
Fax order sheets differ completely in format from client to client. Some are neat tables, some are handwritten on letter paper, some are existing purchase orders with red-pen additions. Even "item code" alone goes by many names — product code, model number, item No.
Catching all this variation with position-based traditional OCR is hard work. You build a template per client and fix it every time the format changes. What was meant to be automation ends up adding effort, doesn't it?
The Strength of Reading by "Meaning"
An LLM's strength is that it reads by meaning, not layout. Whether it says "model number" or "product code," it understands from context that it refers to the item code.
Define the form's coordinates and read characters at fixed positions. Breaks when the format changes.
Read the whole document, understand its meaning, and judge which fields to extract. Robust against format variation.
That's exactly why a single system can absorb many clients with differing formats.
The Knack of Prompt Design
Fix the Output "Shape"
Let the AI write freely and it returns "quantity: 10" one time and "it's 10 units" the next, which trips up downstream processing. So the prompt clearly specifies the fields to extract and their format, instructing it to return only JSON of a fixed structure.
Define the field names — item code, quantity, client, requested delivery date — and each one's type (string or number) up front. With the output shape fixed, the sheet-writing step can safely assume that shape.
You are an order-processing assistant.
Extract the order line items from the following fax order sheet.
[Fields to extract]
- itemCode: item code (string)
- quantity: quantity (number)
- client: client name (string)
- dueDate: requested delivery date (YYYY-MM-DD, null if unknown)
[Rules]
- Set unreadable fields to null. Do not fill by guessing.
- If there are multiple line items, return an array.
- Output nothing but the specified JSON.
Make It Say "I Don't Know"
The worst thing is letting the AI fill a blank with a "plausible-looking" value. Arbitrarily setting an unreadable quantity to "1" is worse than a misread.
So the prompt strongly instructs "set unreadable fields to null without guessing." Being able to say you don't know when you don't is an indispensable trait for using AI in real work. If it returns null, downstream validation can route it to "needs review."
Align the Granularity of Line Items
It's common for one fax to list several products. We break these into individual line items and return them as an array. Aligning to "one row = one line item" lets each row map straight to a row in the order sheet.
If this breaks down, two products get mixed into one row, or one product splits across two, throwing off quantity totals. Humble as it is, specifying granularity is the foundation of accurate order data.
Making Extracted Results Trustworthy
Layer on Mechanical Validation
Writing the LLM's output as-is is dangerous. We pass the extracted JSON through mechanical checks before finalizing it. Obvious anomalies are caught automatically, before a human even reviews.
Confirm item code and quantity aren't missing
Cross-check the extracted item code against the product master
Confirm quantity is a positive integer and the delivery date is valid
Mark flagged line items and route them to human review
Matching Against the Item Master Pays Off
The most effective check is cross-referencing the extracted item code against the product master. A nonexistent code means a misread, a discontinued item, or a notation mismatch. Either way, it's a sign a human needs to confirm.
Backing up "the code the AI read" with "a code that actually exists" — this one step stops a misread before it turns into a misshipment. Having the master as a reliable ground truth is the safety net for AI adoption.
The AI's Output Is a 'Draft'; Finalize After Validation
An LLM is powerful, but its output is a draft, not a final answer. Only after passing required-field, master-match, and type checks does it become data fit for operations.
Hand It to People in an Easy-to-Confirm Form
Even after validation, a person gives it a final look. Here, being able to view the original PDF and the extracted result side by side makes confirmation far easier. Wonder "is this row really quantity 10?" and you can check the original immediately.
Not leaving it all to the AI, but not reverting everything to manual work either. The AI drafts, the human confirms — this division of labor is, I feel, the realistic way to have both speed and accuracy.
Conclusion
I've explained structured data extraction from forms with LLMs.
- Read by meaning: understanding by context, not layout, makes it robust against format variation
- Fix the shape: return JSON of a fixed structure and forbid filling gaps by guessing
- Back it up with validation: finalize only after required-field, item-master, and type checks
Extraction is the heart of AI adoption, but it only fits into operations with the mechanisms supporting it on either side. The intake foundation is covered in "Designing the Intake Pipeline from Email Inbox," and destination routing plus misread handling in "Per-Client Routing Rules and Misread Recovery." For the overall picture, see "AI-OCR for Fax Orders."