PDF Orders by Email: Extract Into an Approval Queue, Not Blind Entry

An order-intake pipeline is not an extraction engine. The extraction engine returns a value and a confidence score per field; the pipeline is what decides what to do with that number. Every order enters as a draft, each field is routed against its own threshold, and only a draft whose fields all cleared becomes a real order.

What an order-intake pipeline does that an extractor does not

An extractor takes a file and returns fields. A pipeline takes an email with an attachment and returns a decision: release, hold for approval, or reject. Those three decisions are the product. Extraction is one stage out of seven.

1. Ingest - the message is stored with its message id, sender address, subject and every attachment. The file is kept exactly as received, unprocessed.
2. Classify - is this an order at all. Supplier invoices, delivery notes and email signatures saved as image attachments are the three classification errors you will actually see.
3. Identify the customer - sender address against the customer record. An unrecognised sender is not an error; it is an item in a different queue.
4. Extract - a value and a confidence score for each field you declared required.
5. Validate against the business - SKU against catalogue, price against agreement, quantity against history.
6. Route - on the weakest field in the draft, never on the document's average confidence.
7. Approve - create the real order and return an order number to the sender.

The common failure is jumping from stage 4 to stage 7. That produces an order that looks perfectly healthy in every report, and nobody knows the quantity says 100 instead of 10 until the truck arrives.

Where does the confidence number actually come from?

From the engine that read the document, and its meaning is narrower than people assume. Amazon Textract's documentation defines Confidence as the percentage confidence the service has in the accuracy of the detected item, and adds that depending on the scenario, detections with low confidence might need visual confirmation by a human. That is a statement about character recognition, not about whether the value makes sense.

That distinction is the whole difference between a pipeline that works and one that produces confidently wrong orders:

• A typed PDF reading Quantity: 100 will be extracted with very high confidence, even when the customer meant 10 and added a zero.
• A skewed scan of the same document will be extracted with low confidence, even when the extracted value is completely correct.
• An empty field does not return low confidence. It returns no field at all, and that is a third state needing its own handling rather than being folded into "weak".

So a confidence threshold is necessary and not sufficient. It filters bad reading. Business validation is what filters bad values.

Routing table: what goes straight through and what stops

The thresholds below are an example configuration to calibrate against your own documents, not authoritative values. The principle is that the more a mistake in a field costs, the higher its threshold and the harder its accompanying check.

Look at the last row. A line total is not a field you extract and trust; it is a field you extract and check with. If 12 times 47.50 is not 570.00, one of those three values is wrong - and that is the cheapest way there is to catch an extraction error without spending a person on it.

How is a wrong extraction caught before it becomes a wrong order?

In three layers, applied in order rather than in parallel:

• Internal consistency inside the document. Line totals against the grand total, the declared line count against the lines counted, one currency throughout. A document that disagrees with itself is rejected rather than queued, because there is nothing in it to approve.
• Agreement with your own business data. SKU against the catalogue, price against the customer's agreement, address against the addresses you already hold. This is where most of the errors that sailed past the confidence threshold get caught.
• Deviation from historical behaviour. A customer who reliably orders 8 to 15 units and today ordered 120 is not necessarily wrong, but is necessarily a queue item. This rule catches exactly the extra-zero error, which is the most expensive mistake in order intake.

What survives all three layers is a small set that genuinely needs an eye on it. That is the goal - not removing the human, but bringing them only what deserves looking at, with the original document open beside it.

What the review screen shows, and why two buttons rather than three

A good queue screen is not a form. It is a comparison between two things: what the system extracted, and what the file says.

• The original file is displayed alongside the form, scrolled to the page and region the suspect field came from.
• Every field shows its confidence, and every field below its threshold is marked. The others need no attention and should not attract any.
• Beside the field sits the context needed to decide: this customer's history on this item, the price list that applies to them, the addresses already on their record.
• Two buttons only: approve as extracted, or correct and approve. There is no third "skip", because skipping creates drafts that sit in the queue forever.
• A draft older than a configured number of hours escalates to someone else. A queue without a clock becomes an archive within a month.

Related: extracting data from PDFs with AI, automating order processing end to end, keeping quote, order and invoice under one identifier.

What the audit trail stores, and why it is what lets you tune

Every intake writes an audit record that is never deleted and never updated - only appended to:

• The original email message id and sender address, exactly as received.
• The original file itself, not a processed or compressed rendition of it.
• The extracted value for each field, together with the confidence returned for it.
• The final approved value, including when it is byte-identical to the extracted one.
• Who approved it, when, and how long the draft sat in the queue before anyone touched it.

The pair "extracted value against approved value" is what calibrates the system. After two hundred orders you can ask a precise question: in which field does the human change what was extracted, and in what confidence band. A field where the reviewer approves unchanged 98% of the time has a threshold set too high and is slowing down healthy work. A field where the reviewer keeps changing values even above the threshold has a threshold set too low, or a missing business check. Without the log, both questions are guesswork, and the thresholds end up set by whoever complained most recently.

Sources

• Amazon Textract - Confidence in detection results
• Amazon Augmented AI - human review initiated by confidence thresholds