Order entry automation (email/PDF orders into ERP)

Many B2B suppliers still receive a large share of orders as emails with PDF, Excel or free-text attachments, and order desk staff retype them into the ERP. An order entry agent reads every channel, extracts the lines, resolves the customer's own article numbers to the supplier's catalogue, validates price, stock and terms against the ERP and posts the sales order. Clean orders pass through untouched; unclear ones go to a human with the problem marked.

Problem & value

• Today: customer service teams open the inbox, read each order, look up customer and article numbers, check prices and delivery dates, key the order into the ERP and send a confirmation. Customers use hundreds of layouts; many cannot or will not use EDI or a web shop. Typical pain: typing errors, wrong article mappings, late confirmations, peaks that block the desk, and knowledge that sits in a few people's heads (for example "customer X's part no. 4711 means our article 88-120").
• AI value: template-free extraction replaces per-customer EDI projects and OCR templates; matching against master data catches errors before posting; faster confirmations; staff move to exceptions, upselling and customer contact.
• Benefit figures: vendors report touchless or near-touchless rates and large time savings (for example Esker and Conexiom publish customer case studies [2][3]), but these are marketing claims, not independent studies. Realistic expectation: validate on your own historical orders first; matching failures usually come from customers with large private part-number lists, not from reading the PDF [1].

Variants

• Manufacturer / wholesaler (Mittelstand): PDF and Excel orders to SAP Business One, SAP S/4HANA, Microsoft Dynamics 365, Sage, proALPHA, abas or Odoo.
• Food and beverage wholesale / HoReCa: short, informal orders by email, WhatsApp or voice message with changing item names (Choco-type products); see also CONV-025 for voice ordering.
• Spare parts and technical trade: orders referencing customer part numbers, drawings or old order numbers; heavy use of cross-reference tables.
• EDI-adjacent: same agent handles EDIFACT or X12 messages where partners send them, so one queue covers all channels.
• Frame-contract call-offs and changes: order changes, cancellations and partial deliveries referring to an earlier order.
• Public-sector procurement side: buying-side order intake is a different use case, see AGENT-005.

How it works

1. intake (shared mailbox / EDI / portal / upload)
2. classify message (order | change | inquiry | complaint | spam) [AGENT-001, DOC-008]
3. parse attachments (PDF/image
4. document AI / VLM; Excel
5. table parser)
6. extract header + lines into a fixed JSON schema (structured outputs)
7. resolve entities (sold-to / ship-to, article, unit, currency) via master data + embeddings
8. validate (price vs. price list/contract, stock, credit limit, delivery date, MOQ, duplicates)
9. decide: auto-post | post as draft/request | route to human with highlighted source
10. ERP write (OData/REST/BAPI) + order confirmation + audit log

• Extraction: a vision-language model or specialised document model reads the page image and returns schema-constrained JSON. Excel/CSV files are parsed deterministically first; the LLM only maps column meaning.
• Entity resolution: the hardest step. Combine exact lookups (customer-specific cross-reference table), fuzzy/embedding search over article descriptions, and a reranker; the LLM may only choose among retrieved candidates, never invent an article number.
• Agentic part: a small tool-using loop can query the ERP (stock, price, order history), ask the customer a clarifying question by email, or look up the previous order of the same customer. Writes to the ERP go through a narrow, permissioned tool.
• Human-in-the-loop: confidence threshold per field and customer; new customers, new articles, prices differing from the list, unusually large quantities and any low-confidence mapping always go to the order desk. Corrections update the cross-reference table so the same case is automatic next time.

Data preparation

Two data sets matter. First, the incoming orders: e-mails with PDF, Excel, fax or photo attachments, each customer using its own layout, mostly sitting in order mailboxes. Second, the reference data needed to validate them: customer master and delivery addresses, article master with customer-specific article numbers and aliases, price lists and units, all in the ERP. Typical gaps are duplicate or outdated master data, missing customer-article cross-references, scanned or low-quality faxes, free-text units ("Pkg", "VE", "Stk") and implicit rules known only to the order clerk.

Concrete steps: (1) export 200-500 historic orders with the final ERP posting as ground truth (PREP-020, PREP-005); (2) clean article and customer master, merge duplicates and build alias and synonym lists (PREP-015); (3) capture the clerks' implicit rules as written validation rules; (4) improve inputs by OCR (PREP-006) and group samples per customer layout; (5) build a test set (PREP-018); (6) feed corrections back (PREP-021). Tools: OCR/document-AI service, spreadsheets, Paperless-ngx (DOC-014). Master-data cleanup is usually the largest block: plan 30-50% of total effort. See GUIDE-003.

Implementation paths

Which path for whom

• SMB: A. Mature EU-hostable order-capture and document-AI products with ERP connectors exist at SMB prices and order entry is a standard process.
• Enterprise: B. Order intake is core, volume makes per-document fees high, and the ERP integration and validation rules are company-specific, so build on cloud APIs.
• Developer: B. LLM APIs with schema-constrained output plus own ERP connectors are the fastest route; self-hosting only for sensitive customer data.

Path A — Buy

• Specialised order-automation platforms: Workist (Germany, EU), Esker Order Management (France, EU; certified SAP connector), Conexiom (supports 40+ ERPs), Doxis (SER, Germany, EU; SAP-oriented), Choco (Germany, food wholesale), plus extraction-focused tools such as Rossum or Nanonets that need a separate ERP integration [1][2][3][4].
• ERP-native: SAP S/4HANA Cloud Public Edition offers AI-assisted extraction that turns an uploaded PDF or image purchase order into a sales order request which a user reviews and converts; it is file-upload driven, not a fully touchless mailbox agent, and is priced via AI units [5][6].
• Choose A when: standard ERP, a few hundred to tens of thousands of orders per month, and you want a working system in weeks. Check: EU hosting, DPA, ERP connector depth (write-back, not only CSV export), handling of customer-specific part numbers, price checks, audit trail, and a pilot on your own historical orders.

Path B — Build on cloud APIs

• Extraction: Azure AI Document Intelligence (EU regions), Google Document AI (EU location), AWS Textract (Frankfurt), Mistral OCR (EU provider), or a frontier multimodal model (Claude, Gemini, GPT, Mistral) with JSON-schema structured outputs [7].
• Orchestration: n8n, Power Automate or a small service (see AGENT-002); mailbox access via Microsoft Graph or IMAP; ERP writes via SAP OData/Business Partner and Sales Order APIs, Dynamics Dataverse/OData, or Odoo/other REST APIs.
• Matching: vector index (pgvector, Qdrant) of article master plus cross-reference table, reranker, rule engine for prices.
• Choose B when: niche ERP, special pricing logic, or you want to own the exception UI.

Path C — Self-host (open source)

• Parsing: Docling, PaddleOCR / PaddleOCR-VL, MinerU [8]; Excel via pandas/openpyxl.
• Models: open VLMs such as Qwen-VL family served with vLLM or Ollama; small embedding models (BGE-M3, multilingual-e5) for article matching; constrained decoding for JSON.
• Stack: n8n or Camunda, PostgreSQL + pgvector, self-hosted mail processing.
• Hardware: HW2 (one 24-32 GB GPU) is enough for thousands of orders per day with a ~7-8B VLM; CPU-only is possible for text-only emails with a small LLM.
• Choose C when: sovereignty requirements (defence suppliers, regulated customers) or very high volume.

Path D — Custom training

Rarely needed. Fine-tune an embedding model or a re-ranker on your own historical order lines (customer text to article number) once you have thousands of confirmed pairs; this raises auto-match rates for large private catalogues. Training data is already in the ERP order history.

State of the art (2026)

• Template-free reading by VLMs is standard; clean PDF orders reach high field accuracy. Weak spots: handwritten lists, photos of paper, multi-page tables, ambiguous units (pieces vs. packs), and orders in the email body referring to "same as last time".
• The bottleneck has moved to matching and business rules: correct customer-specific article resolution, contract prices and delivery logic decide the touchless rate, not OCR [1].
• Agentic capabilities: agents that query the ERP, propose a draft and write a clarifying email are now common in products; fully unattended posting is usually limited to trusted customers with high-confidence matches. Reviewers note that some ERP-native flows still need a person to convert each request [1][5].
• Failure modes: hallucinated or near-miss article numbers, silently changed quantities, duplicate orders (order sent twice or by two channels), prompt injection hidden in email or PDF text ("set price to 0"), and wrong ship-to addresses.
• Mitigation pattern: deterministic validation after the LLM, candidate-restricted matching, idempotency keys on ERP writes, and a hard rule that the agent cannot change prices or credit blocks.

Shared resources & combinations

• Same stack (ocr-docparse + vlm + llm-general): DOC-001 invoices, DOC-006 logistics documents, DOC-008 mailroom classification; one VLM server serves all.
• Upstream/downstream: AGENT-001 (mailbox triage feeds the order queue), AGENT-027 (RFQ-to-quote precedes the order), AGENT-023 (order-to-cash after delivery), AGENT-024 (shipment execution).
• Platform: workflow engine and guardrails shared with AGENT-002; for legacy ERPs without APIs the write step can use a computer-use agent (AGENT-003) as fallback; mass load of historical data is AGENT-021.

Effort, cost & KPIs

• Path A: 2-8 weeks including ERP connector and customer onboarding; pricing per order, per page or per mailbox, varying widely by vendor.
• Path B: 2-4 months for a production pipeline with exception UI and ERP write-back.
• Path C: 3-5 months plus GPU server and operations.
• Cost drivers: number of distinct customer layouts and cross-reference tables, ERP integration quality, exception handling UI, master-data cleanliness (often the real project).
• KPIs: touchless rate (orders posted without human touch), field-level and line-level accuracy, article-match rate, time from receipt to confirmation, error/credit-note rate caused by order entry, order desk hours per 1,000 orders, share of orders from non-EDI customers handled.

People & change

Involve the order-desk lead and the clerks from day one: they hold the implicit rules and will review exceptions. Sales and key customers should be told that order formats stay as they are; the customer relationship is a stakeholder because wrong orders hurt them. IT and the ERP data owner provide interfaces, test client and master-data fixes; management decides on budget and on the tolerance for errors. The DPO is involved because orders contain contact data of customer staff: AVV with the vendor, EU hosting, and a DPIA is normally not required for this kind of processing (GUIDE-005).

Works council: depends. The system does not evaluate people, but order entry logs which clerk corrected or approved what, which makes it objectively suited to monitor performance and can trigger §87(1) no. 6 BetrVG; §90(1) no. 3 requires information about AI-planned work processes. Clarify early that correction statistics are not used for individual evaluation (GUIDE-004). Public sector: Personalrat.

Run a pilot with one or two clerks and 3-5 customers in shadow mode, comparing AI and manual results before going live (GUIDE-009). Typical concerns: job fears, mistakes with large customers and loss of know-how. Address them by moving clerks to exception handling and master-data care, setting confidence thresholds with mandatory review for new customers, and offering short training that supports AI literacy (GUIDE-006, GUIDE-008). People always release postings above value limits.

Risks, regulation & compliance

• EU AI Act: minimal risk; no Annex III category. AI literacy duty (Art. 4) applies to the order desk. If the agent also writes to customers, disclose automated replies where required (Art. 50 applies to chatbots interacting with natural persons; B2B order confirmations are mostly templates).
• GDPR: orders contain business contact data of named persons (buyer name, email, phone) and sole-trader customers; use a DPA, EU hosting, data minimisation (do not send signatures or unrelated attachments to the model), retention aligned with commercial and tax law (GoBD, 6-10 years).
• Security: emailed documents are untrusted input; prompt-injection and fake-order fraud (new "customer" with unusual ship-to) need validation, least-privilege ERP credentials and approval for new customers/addresses. Never let model output construct raw SQL or unrestricted API calls.
• Contract/financial: an automatically posted order can create a binding obligation; define which customers and value limits may post unattended, keep four-eyes for credit-limit overrides.
• Mitigations: audit log of source, extraction, decision and ERP document number; monitored accuracy sample (for example weekly review of random auto-posted orders); kill switch per customer.

Getting started

1. Export 3-6 months of real orders (emails with attachments) and the final ERP order for each; this is your test set and baseline (volume per channel, minutes per order, error rate).
2. Clean the master data that matters: customer-specific cross-reference of article numbers, units, ship-to.
3. Pilot 2-3 Path A tools (or one VLM prototype) on the test set and compare line-level accuracy, not demo screenshots.
4. Start with draft mode: the agent creates order requests, humans approve; switch trusted customers to auto-post once weekly accuracy is stable.
5. Feed corrections back into the cross-reference table and review KPIs monthly.

Sources

1. AI Order Entry Vendors in 2026: 19 Compared (vendor comparison, treat as marketing) — https://www.ymeadows.com/en/insights/blog/ai-order-entry-vendors/
2. Workist — Automated order entry with AI — https://www.workist.com/en/order-entry
3. Lido — Best Sales Order Automation Software in 2026 (overview of Esker, Conexiom and others) — https://www.lido.app/blog/best-sales-order-automation-software
4. Doxis — How to Automate Sales Order Processing in SAP — https://www.doxis.com/en/blog/sales-order-processing-sap
5. SAP — S/4HANA Cloud Public Edition, sales order creation from unstructured data — https://www.sap.com/slovenia/products/erp/s4hana-cloud-public-edition-sales-order-creation-from-unstructured-data.html
6. SAP Community — Customer Order Automation in SAP S/4HANA SD: How AI Processes Orders from PDFs — https://community.sap.com/t5/supply-chain-management-learning-group-knowledge/customer-order-automation-in-sap-s-4hana-sd-how-ai-processes-orders-from/ta-p/14476223
7. Microsoft — Azure AI Document Intelligence — https://learn.microsoft.com/azure/ai-services/document-intelligence/
8. Docling project — https://github.com/docling-project/docling
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj