How to automate order entry from email and PDF

TL;DR: You can convert emailed orders and PDF attachments into draft sales orders by combining document OCR and classification, data extraction, master data matching, business-rule checks, and a human approval step. This guide walks through each stage and shows where staff still need to intervene.

Why automate order entry

You type orders from emails and PDFs into the ERP. It takes time. Mistakes happen when staff read messy PDFs or copy long product descriptions.

Automation does the repetitive work: read the email and attachment, extract the lines, match customer and product codes, and prepare a draft order for review. The human role moves from data entry to exception handling and approval.

Adoption is not universal. For context, approximately one in six businesses, 16%, are currently implementing at least one of the AI applications asked about in the Office for National Statistics survey. See the ONS report for details: Understanding AI uptake and sentiment among people and businesses in the UK - Office for National Statistics.

High level workflow

1. Capture email and attachments.

2. Classify document type and run OCR.

3. Extract order fields.

4. Normalise data and match against master records.

5. Run business rules and price checks.

6. Create a draft sales order in the ERP.

7. Human reviews exceptions and approves the draft.

Each step is simple to describe and needs specific tools and rules to work reliably in practice. The rest of this article walks the flow in detail.

1. Capture: get the email and attachments into the system

Start at the inbox. Use a dedicated order email address or a monitored shared mailbox. That keeps noise out of other mail.

Automated capture usually has three parts. Polling the mailbox or using webhook delivery. Saving attachments and the email body. Recording metadata such as sender address, subject, time stamp and message-id.

Practical tips:

• Use a single address for orders where possible. It reduces classification errors.

• If customers send orders from many addresses, capture the sender and any reference numbers in metadata.

• Save original files. You will need them for dispute handling.

2. Document classification and OCR

Next, decide what the attachment is. Is it a purchase order, an order confirmation, or an invoice used as an order? This drives the extraction rules.

Tools such as Google Document AI provide page and layout OCR, key/value detection and document splitting so you get text plus structure: Présentation de Document AI | Document AI | Google Cloud Documentation.

If you have a small set of order formats, build a custom document-processing model and train it. Microsoft notes you can start with as few as five example documents to train a custom document-processing model with AI Builder: Document processing model overview - AI Builder | Microsoft Learn.

If the attachment looks like an invoice, a prebuilt invoice model can already extract common invoice fields such as invoice ID, invoice date, amounts and customer name. That can help when suppliers use invoices as order confirmations: Invoice processing prebuilt AI model | Microsoft Learn.

What to extract in this step:

• Line items with quantities and unit descriptions.

• Header fields: buyer name, address, purchase order number, requested delivery date.

• References such as supplier order number or customer order reference.

Practical points:

• PDFs vary a lot. Scans need decent resolution. Automated quality checks can flag unreadable pages.

• Some multi-page PDFs contain more than one document. Use document splitting to separate them before extraction.

3. Normalise extracted data

Raw text needs cleaning. Normalisation turns free text into structured values.

Common normalisation tasks:

• Trim whitespace and line breaks.

• Normalise date formats.

• Split quantity and unit from combined fields like "10 boxes".

• Convert currency symbols and decimal separators to a standard numeric format.

Keep the normaliser conservative. If a value is ambiguous after normalisation, flag it for human review instead of guessing.

4. Match customers and delivery addresses

The system must find the correct customer account in your ERP. Use multiple matching signals in order of trust:

• Exact match on customer code or account number if provided.

• Exact or fuzzy match on company name plus postcode.

• Match using email domain where applicable.

• Match by previously seen sender address or past orders.

Keep a clear fallback policy. If matches are low confidence, route the order to an exceptions queue for a person to pick the right account.

Why multi-signal matching matters. PDFs rarely contain the exact account code your ERP expects. Matching by name and address reduces false positives. If you also use GTIN, EAN or supplier item codes you can cross-check product matches. GS1 documents describe the role of standards such as GTIN in machine-to-machine exchanges: GS1 Electronic Data Interchange (EDI) - Standards | GS1.

5. Match products and SKUs

This is the trickiest part for distributors and wholesalers. Customers describe products in many ways. You need to map those descriptions to your internal SKU or GTIN.

Common matching methods:

• Exact SKU or part number lookup. Many orders include a supplier SKU or internal code.

• GTIN/UPC match when the customer includes a barcode value.

• Fuzzy text match on descriptions: tokenise the line, remove stop words, then compare with your catalogue descriptions.

• Use manufacturer and catalogue IDs if present.

Practical policy to reduce errors:

• If the match confidence is high, auto-fill SKU and unit price.

• If confidence is medium, include both the extracted text and the suggested SKU on the draft order for quick human review.

• If confidence is low, flag the line for manual resolution and do not auto-commit to the ERP.

Store the match confidence and the signals that produced it. That helps operators decide quickly why a match was made.

6. Apply price lists, discounts and rules

Automated orders must obey commercial rules. The system must check prices and terms before creating a draft.

Checks to run automatically:

• Match the price against the customer-specific price list or the standard price.

• Validate minimum order quantities or pack sizes.

• Apply contract discounts and promotional pricing.

• Check delivery lead times and stock availability if you plan to show expected ship dates.

If any rule fails, flag the line or the whole order. Keep the reason visible on the draft order.

7. Build the draft sales order and route for review

Once extraction, matching and pricing run, create a draft sales order in the ERP or a staging area.

What a good draft order includes:

• Original email and attachment links.

• Extracted header fields and line items.

• Match confidence per field and per line.

• Business-rule check results and failed checks.

• A clear set of actions for the reviewer: accept, edit, reject, or request clarification.

Keep the draft editable. Allow the reviewer to correct customer, SKU, quantity, price and delivery details before they post the order.

Where people still need to act

Automation reduces typing. It does not remove judgement. Here are the common tasks left to staff:

• Confirm ambiguous customer or address matches.

• Resolve product mismatches when the description is not specific enough.

• Approve price overrides and non-standard discounts.

• Validate orders that fail credit or stock checks.

• Handle manual exceptions such as rush orders or special packaging.

Design the operator interface for speed. Show the original PDF and the extracted fields side by side. Show match signals and suggested fixes. Make approval one click when confidence is high.

Exception types and how to handle them

Common exceptions and recommended actions.

• Missing PO number. Route to a handler who confirms the purchase order reference.

• Unknown customer. Flag for account team validation.

• Unmatched product line. Provide suggestions and a quick search box so staff can find the SKU.

• Price discrepancy. Show contract price and allow manager approval for overrides.

• Unreadable scan. Ask for a clearer file or a manual key-in.

Automate what you can. Keep the manual path quick for the rest.

Checklist for implementation

Use this checklist to scope a pilot and assign owners.

Design decisions and trade offs

• How aggressive should auto-accept be. Higher automation reduces workload but increases risk of wrong orders. Start conservative.

• Where to store the staging drafts. Staging inside the ERP keeps data governance simple. An external staging area gives more control over recovery.

• Use prebuilt models or custom training. Prebuilt models cut setup time for common document types. Custom models are better for recurring, company-specific formats.

Microsoft offers both prebuilt invoice models and the ability to train a document-processing model with a small set of examples. They note that you can train and publish a model and then use it in flows or apps, and that you only need five documents to get started with custom training: Document processing model overview - AI Builder | Microsoft Learn. For invoices specifically, Microsoft documents the fields a prebuilt invoice model extracts which may help if you get invoices used as orders: Invoice processing prebuilt AI model | Microsoft Learn.

For broader document OCR, classification and key/value extraction functionality, the Document AI platform explains concepts such as OCR, key-value pair detection and form/table handling: Présentation de Document AI | Document AI | Google Cloud Documentation.

If you are also considering replacing manual email orders with EDI for high-volume trading partners, GS1 explains that EDI standards like EANCOM provide a machine-to-machine structure for orders and master data alignment. This is worth considering for customers who can switch to EDI later: GS1 Electronic Data Interchange (EDI) - Standards | GS1.

Pilot plan (4 to 8 weeks typical)

1. Pick 2 to 5 frequent customers with simple orders.

2. Capture the last 50 orders from those customers and use them to build or fine tune the document model.

3. Build rules for customer and product matching and set conservative confidence thresholds.

4. Run the pilot in a read-only mode to compare automated drafts with manual entries.

5. Review exception types, adjust model thresholds and update master data.

6. Switch to a live editable draft mode and let staff approve orders.

A short pilot shows return on effort quickly and exposes the real edge cases.

Metrics to track

• Number of orders fully auto-accepted versus exceptions.

• Time saved per order from capture to approved draft.

• Error rate on SKU and price matches.

• Volume of manual corrections by field type.

These metrics help you tune thresholds and show value to stakeholders.

Example: a hypothetical order flow

Say an order arrives by email as a two‑page PDF. Page one is a purchase order. Page two is a delivery note. The system does the following:

1. Ingest the email and save both pages.

2. Split the PDF into two documents.

3. Classify page one as a purchase order.

4. Run OCR and extract header and line items.

5. Normalise dates and quantities.

6. Match company name to an ERP account with medium confidence.

7. Match two of three lines to SKUs with high confidence, one line is fuzzy.

8. Apply customer price list and flag a price mismatch on the fuzzy line.

9. Create a draft order with links to the original PDF and the confidence signals.

10. Send the draft to the sales office queue showing suggested SKUs and the line to check.

A person reviews the draft, corrects the fuzzy line using the quick search tool, approves the order and the ERP posts it.

Common pitfalls and how to avoid them

• Bad master data. Clean customer and product masters first.

• Over-trusting low-confidence matches. Use thresholds and visible signals.

• Ignoring exception data. Log every manual correction and feed it back to retrain or adjust rules.

• Poor user interface. Operators must see original documents and suggested matches together.

Next steps and what to ask a vendor

Checklist of questions when evaluating tools or partners:

• Can the solution process emails and attachments automatically?

• Does it support custom training and prebuilt models for invoices and purchase orders?

• How does it report match confidence and show match signals to users?

• How are exceptions routed and can the workflow integrate with our ERP?

• What audit trail exists for each order and correction?

If you want to scope a pilot, look for a short trial that integrates with your mailbox and ERP and that can be trained on a handful of your documents.

Final notes

Automating order entry does not remove the need for judgement. It reduces repetitive typing and surfaces exceptions faster. Start small, measure results and expand to more customers and document types as confidence grows.

If you want practical help scoping a pilot or comparing vendors, Khairos can map your current process and propose a pilot with clear steps and success criteria. See our services and pricing pages for details: /services and /pricing.

Book a free intro call