AI order entry for manufacturers: customer orders from emails and PDFs into the ERP

What AI order entry does in the sales office

AI order entry takes the purchase orders that customers send by email, as PDF attachments or as part lists, extracts the order header and every line, checks them against your article master and price agreements, and passes a clean record to the ERP. A person in the sales office still decides every case the system is unsure about. The language model that does the reading is small: a 14-billion-parameter model on one 32 GB GPU handles the order volume of a typical manufacturer many times over, so the task usually runs on a shared company AI server next to other work.

We wrote this for the head of sales administration, the managing director or the person who runs order processing at a manufacturer or wholesaler, and for whoever looks after the ERP. The first half describes the process in business terms. The hardware sits in one section with one table, and the notes for the IT team come at the end.

The problem is familiar. Orders arrive in many formats: a PDF exported from the customer's ERP, a scanned form, a table pasted into an email, or a short message saying "same as last time, but 200 pieces". Experienced staff retype them into the ERP, and in busy weeks that typing becomes the bottleneck of the whole sales process. Customers who send electronic orders through EDI are not the issue; this article is about the rest.

How a purchase order gets from the inbox into the ERP automatically

The Mittelstand-Digital Zentrum Chemnitz, a publicly funded advisory centre, has published a case study of a control-cabinet and cable-harness builder with about 150 regular customers whose orders arrive mostly by email, as orders, part lists or PDF attachments. Its ERP has no open interface. The centre describes a seven-stage pipeline from the email inbox to the order in the ERP, with AI extraction and article matching in the middle, and a middleware layer that checks the mandatory fields and writes the result to the ERP. The ERP itself stays unchanged.

A pipeline of that kind has these steps:

1. Intake. A dedicated mailbox, such as orders@, receives the email. The system stores the original email and its attachments before anything else happens.
2. Reading. A PDF exported from the customer's system carries a text layer that a standard PDF library reads on the processor. Scans, photos and faxes go through a document model first, as our guide to vision-language models for document AI explains.
3. Extraction. The language model fills a fixed schema: customer, order number, order date, delivery address, requested date and, for each line, the customer's part number, description, quantity, unit and price.
4. Matching. The customer's part numbers are translated into your article numbers.
5. Checks. Rules compare quantities, units, prices and dates with your data.
6. Decision. The traffic light sends the order to the ERP, to a person, or back to manual entry.
7. Booking and log. The middleware writes the order through one interface and records what was read, what was changed and who approved it.

The language model appears in steps 3 and 4 only. Everything else is ordinary software that your ERP partner or IT team already knows how to build.

Green, yellow, red: who checks which order

The Chemnitz case states the rule in one sentence: green orders go into the system automatically, yellow ones go to a visual check, and red ones are entered manually. Corrections made by staff flow back into a learning loop. Every order run is logged in an auditable way.

Traffic-light rule as described in the Mittelstand-Digital Zentrum Chemnitz case study on AI-supported order entry (read 25 October 2026); the individual checks and thresholds are our example values, which each company sets for itself.

Fixed rules decide the colour. The model reports what it read; deterministic checks against the ERP data decide whether that is plausible. A company starts with most orders in yellow, reviews the corrections for a while and moves customers to green one by one once their orders arrive clean. A customer whose orders always come from the same ERP export reaches green quickly; a customer who writes free text may stay yellow for good.

Customer part numbers and your article numbers

Matching is where order entry differs from invoice reading. Customers order with their own part numbers and descriptions, and those rarely match your article master. Most ERPs keep a cross-reference table of customer part numbers per customer; where it exists, matching is a simple lookup and needs no AI. The model helps with the lines that are missing from that table: it compares the customer's description, drawing number or dimensions with your article texts and proposes the most likely article, which a person confirms once and which then goes into the cross-reference table.

Margins, price agreements and customer-specific prices are exactly the data a company does not want in an external tool. The Chemnitz case gives that as the reason why an AI costing tool was rejected there: margins and hourly rates do not belong in a generic cloud model, and sensitive costing data does not leave the company. With the model on your own server, the checks run against the price agreements in your ERP without copying them anywhere else. Our article on trade secrets, NDAs and AI tools covers the business side of that decision.

We set up order entry on a company AI server with RTX PRO 4500 or RTX PRO 6000 Server Edition cards; send us your orders per day, the share of scanned orders and your ERP, and our team proposes the pipeline and the server.

Which model is enough to extract orders from PDFs and emails

Reading an order and filling a schema does not need the largest models. Two open models of about 14 billion parameters show the range:

Hugging Face model cards and file lists of Qwen/Qwen3-14B-FP8 and mistralai/Ministral-3-14B-Instruct-2512, read 25 October 2026; the Ministral repository holds the same weights twice (consolidated and sharded files), 15.7 GB each.

The language list matters for a company with customers across Europe. The Ministral 3 card lists English, French, Spanish, German, Italian, Portuguese, Dutch, Chinese, Japanese, Korean and Arabic, and no Polish or Czech; the Qwen3 card states support for more than 100 languages and dialects. The Ministral card also names native function calling and JSON output and accepts images, so it can read a clean scan directly. Qwen3 runs with a thinking mode that the card lets you switch off with enable_thinking=False, which is the right setting for extraction. A test set of real orders from your own customers decides between them; our comparison of open LLMs for European languages has more candidates.

The serving engine vLLM accepts a JSON schema with each request, and its documentation states that with this option "the output will follow the JSON schema". That makes every answer a record the middleware can parse. It does not make the values correct: a well-formed record can still hold a wrong quantity, which is why the checks in the traffic light exist.

How fast. StorageReview published single-card measurements on 14 October 2026 with vLLM 0.27.1. With Ministral 3 14B in FP8, one RTX PRO 4500 Server Edition delivered 1,107 output tokens per second at 32 parallel requests of 512 tokens in and 512 out, and at 8K tokens in and 1K out it levelled off at about 180 tokens per second; StorageReview writes that "the flattening is KV cache running out, and 32GB sets that limit". A two-page order with ten lines needs well under 8K tokens of input. If the extracted record takes about 600 tokens, an assumption, 180 tokens per second give about 0.3 orders per second, roughly 1,000 orders an hour by our estimate. A sales office with 300 orders a day keeps the card busy for about 17 minutes of that day.

How much memory. By our users-per-card rule, 90 per cent of the memory the driver reports less 3 GiB per card, a 32 GB card holds 25.7 GiB of weights and cache, as our guide to the RTX PRO 4500 Server Edition derives. Qwen3-14B in FP8 takes 15.2 GiB, which leaves 10.5 GiB; with an FP8 cache of 0.625 GiB per 8,192-token conversation, the card serves 16 at the same time. For order entry those are 16 orders being read at once, more than any sales office sends in one moment.

Draft replies to customer emails and delivery-date questions

The same model handles the rest of the sales inbox. It sorts incoming emails into orders, order changes, delivery-date questions, complaints and other mail, and writes a draft reply in the customer's language for a person to check and send. Order confirmations can be drafted from the ERP record once the order is booked.

Delivery-date questions need current data. The model should not guess them from earlier emails; it asks the ERP through a read-only account and a fixed set of queries, such as the open orders of this customer with their confirmed dates, and puts the answer into the draft. Our guide to a text-to-SQL LLM server on-premise explains how to give a model read access to a database without letting it change anything. A person approves every reply before it leaves the company. Customer-facing chat on your website is a different task; our guide to a server for a customer service chatbot covers it.

The hardware: one server for several departments

Order entry alone would leave a GPU idle most of the day. Companies that start with it usually plan the server for two or three office tasks from the start: an internal assistant, search over documents, safety data sheets, supplier certificates or quotes. Our article on the first AI use cases in a manufacturing SME lists typical candidates.

Configurations from our AI servers page and our guide to buying a 4× RTX PRO 4500 Server Edition server; capacities by our users-per-card rule; power by our estimate (cards, two processors, plus 15 per cent for the rest of the server), read from the sibling guides of 24 and 25 October 2026. The MIG instance holds the 16.3 GB checkpoint with a smaller cache; its rate is not published and is set in a test.

Four RTX PRO 4500 Server Edition cards. A 2U server with four single-slot cards of 32 GB each, two processors and at least 256 GB of system memory. Each card runs its own model: order entry on one, the others for document search, an embedding model or a second office task. By our estimate it draws about 1.4 kW at the wall, which fits one 230 V 16 A feed with room to spare. Our guide to buying a 4× RTX PRO 4500 Server Edition server lists the parts.

Two RTX PRO 6000 Server Edition cards. The entry server on our AI servers page: two 96 GB cards, two AMD EPYC processors, 384 GB of DDR5 ECC memory and two NVMe drives. One card runs a larger assistant model for the whole company, the other is split by MIG into four isolated 24 GB instances, one of which reads orders. About 1.8 kW at the wall by our estimate.

Four RTX PRO 6000 Server Edition cards. The inference node for a company that wants a strong assistant for several hundred staff plus document work; order entry takes one MIG instance of it.

These servers are loud and warm under load and belong in a server room or a data centre, as our guide to a GPU server in an office explains. Without a server room, our Private AI/ML service runs the platform on dedicated hardware in a Tier-3 data centre in Lithuania, inside the EU.

Notes for the IT team

1. ERP interface. Let the middleware write orders through one interface your ERP supports: an import file, a staging table or an API. The language model never writes to the ERP; it returns JSON, and the middleware validates and books it. The Chemnitz case built its interface per project with the ERP vendor because the ERP has no open API.
2. Schema and validation. Define one JSON schema for orders and pass it with each request through vLLM's structured outputs (response_format with type json_schema). Validate article numbers, units and prices against the ERP after extraction, whatever the model returns.
3. Read-only access. Delivery-date and order-status queries run through a separate database account with read rights on the needed views only.
4. Audit log. Store the original email, the extracted record, the result of every check, the traffic-light colour, the corrections and the person who approved. The Chemnitz case logs every order run in an auditable way.
5. Mail from outside. Customer emails are untrusted input and can contain text that tries to steer the model. Give the extraction step no tools that change data, as our guide to prompt injection and LLM security explains.
6. Network. vLLM's --api-key protects only paths under /v1, /v2, /inference and /cohere (vLLM 0.32.0 security guide), so keep the engine on an internal network behind an LLM gateway with keys and a query log.
7. Personal data. Orders carry names, email addresses and phone numbers of contact persons. Set retention periods for the stored emails and logs and check whether a data protection impact assessment is needed; your data-protection officer confirms the assessment.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We build the servers to order with RTX PRO 4500 Server Edition or RTX PRO 6000 Server Edition cards, assembled and tested before delivery, delivered within the EU on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. Our Private AI/ML service, with our engineering partner Vixen.UNO, sets up the models, the extraction and the connections to your systems; describe your order inbox and your ERP in a few sentences, and we propose a pilot with your own orders.

FAQ