Order capture with AI: from the emailed order to a checked ERP record

One customer order, two prices and an open decision

The inside sales team of a fictional technical wholesaler receives an email. Customer K-210 orders, under its reference B-1042 twelve cartons of item DR-08. Each carton contains 50 sealing rings. The email and the order sheet state EUR 0.80 net per piece and 23 October 2026 as the requested delivery date.

However, the stored price is EUR 0.85 per piece. The order is therefore readable and can be processed arithmetically, but is not yet approved for creation. An AI workflow must master precisely this distinction.

The automation captures an incoming customer order and prepares a sales order from it. The requested delivery date initially remains a request. Whether goods are available and which date can be promised is an additional subject-matter decision. The example is limited to capturing the line item; shipping costs, taxes and other terms are not included in the goods value shown.

Anyone looking first for a suitable area of application will find the upstream process selection in the guide to AI automation in mid-sized businesses . Here we follow one concrete customer order, including its exceptions.

What task does the AI take on in the process?

In the sample case, the AI is to interpret the linguistic and document-related details: Which number is the customer reference? Does the price refer to a carton or to a piece? Where is the requested delivery date? The answer is stored as a structured proposal, together with its respective source location.

A check that is determined arithmetically or by subject matter then belongs in traceable rules. Twelve times 50 gives 600. Whether the customer may order this item, which prices apply and who can confirm a variance is decided on the basis of approved company data and responsibilities.

This division of labour keeps the process verifiable. A well-formatted result can be wrong in substance. Even a high confidence score from document recognition does not replace checking a business-critical detail. Microsoft describes confidence scores as an aid to assessment and recommends including human review appropriately in the process. For your own process, check thresholds should be tested on representative documents. That is our application to the sample case; a universally valid percentage threshold cannot be derived from the source. [1]

An example: if the model recognises 12 pieces although the order sheet says 12 cartons, the output can be technically valid. Only checking the original unit, pack size and base quantity reveals the error. That is why, in the data model, we keep both 12 cartons and the derived value 600 pieces.

The price variance stays visible until someone resolves it

In the main case, the workflow calculates two values: 600 pieces at EUR 0.80 give a proposed goods value of EUR 480 net. At the stored price it would be EUR 510. The difference is EUR 30. The customer's statement that the price was agreed is initially a detail from the order.

Our case rule provides that a person responsible for sales decides the variance. They must be able to verify the agreed price on the basis of a valid quotation or another admissible basis. A comment such as “AI is sure” is not sufficient for this. The decision is stored with its justification and a reference to the checked version of the order.

For the rest of the teaching case, we assume that the responsible person confirms the price of EUR 0.80. This constructed decision explains the following sequence. It does not prove an actually existing quotation, a real approval or a product function.

Exception handling needs a visible outcome: a requested detail supplied, a confirmed correction, a reasoned rejection or a record that remains open. A message in the technical log is not enough for inside sales if it leaves a customer order sitting unprocessed. The work list should show the reason, the responsible person and the next step.

A fixed rule on source priority can make sense, for example where a particular order format has been agreed by contract. It must be defined by subject matter. For our sample case the following expressly applies: if the email and the attachment contradict each other, the order is clarified. The AI must not resolve the conflict silently.

An ERP timeout must not create a second order

After the price approval, the order is prepared in terms of subject matter. Now the system handover has to work, even if a response does not arrive. A typical error arises when the ERP has already created an order but the calling application does not receive the confirmation. A second creation attempt could then produce a further order.

Two identifiers are needed for this case. The business order reference links customer K-210 and order B-1042. It helps to detect repeated receipts or changes to the same customer order. A technical request identifier by contrast designates exactly one approved transfer operation. When this operation is repeated, it remains unchanged.

Whether the target system supports such an identifier has to be checked on its specific interface. The principle of idempotent interfaces is that a repeated request does not trigger the same intended effect again. For this, AWS explains, among other things, request identifiers assigned by the caller and the distinction between a retry and a new intention. [2]

A new email is likewise not automatically a new order. The customer might forward the order, so that the technical message identifier and file hash change. The business reference stays the same. If, on the other hand, the customer changes twelve cartons to 14, a change version arises. This must be compared with the previous version and approved again. A separate technical operation is created for a later change transfer.

The journal links receipt, captured data, check decisions, approved version and ERP confirmation. The status “confirmed in the ERP” is set only when a reliable confirmation with the corresponding record identifier is available. A successful sending of the request alone is not sufficient for this.

Document content does not grant write permissions

Emails and attachments come from outside. Besides order data, they can also contain text that prompts a language model to take other actions, such as skipping a price check. Such embedded instructions must not change the prescribed process rules. OWASP describes this problem as indirect prompt injection, when manipulated content reaches the model context via documents or other external sources. [3]

For the process described, we recommend a technically enforced separation: the extraction produces data proposals. A separate component checks fields and rules. A service authorised only for this purpose transfers the approved version to the ERP. Which action is permitted is decided by the application and its permission check. A corresponding wording in the prompt does not replace these boundaries.

Human approval must likewise be tied to something concrete: to the data state, the action and the target system. If quantity, price or recipient are changed after the approval, the old consent must not automatically cover the new version. A fresh decision then becomes part of the process.

In real operation, further tasks arise: receiving attachments securely, defining permitted file types, protecting credentials, limiting log access, and clarifying retention and data disclosure to suit the use. For the tests described here, customers and addresses are entirely synthetic. No statement follows from this about which real data a particular installation may transmit to a model provider.

Fourteen test cases before the first live order

A demonstration with an easily legible order sheet shows only a small part of the picture. Acceptance must also include cases that remain open or are meant to be deliberately stopped. For our sample case, 14 tests have therefore been prepared. They describe inputs, expected behaviour and required evidence. Their actual result fields remain empty.

The full materials add, among other things, contradictory quantities, an unknown item, an unauthorised approval, a changed order and missing mandatory details. For every test that is run, the application version actually used, model configuration, data basis and reviewing person are recorded. These details make later errors traceable.

For the comparison, the business unit needs its own reference set. It should contain different customer formats, scan qualities, item descriptions, pack units and genuine types of exception. Expected results defined in advance help to recognise whether a supposedly better model produces new errors elsewhere. A small sample case that has been passed does not on its own prove reliable processing of the entire order intake.

After changes to the model, extraction schema, master data matching or rulebook, the affected cases are run again. What also counts here is whether impermissible transfers reliably fail to happen and whether open records end up with the right person.

Calculating freed-up processing time and saved expenditure separately

Economic viability depends on the entire process. Fast capture can be eaten up again by laborious corrections. Our worked calculation therefore takes into account a basic check on every order and additional work for exceptions.

On these assumptions, the new process needs an average of 2 + 0.25 × 6 = 3.5 minutes per order. Compared with eight minutes, that is 4.5 minutes less. At 800 orders, this gives a notionally freed-up capacity of 60 hours per month. The six exception minutes are added to the basic check.

If an hour is valued at EUR 40, the capacity corresponds to a model value of EUR 2,400 per month. After assumed ongoing costs of EUR 600, EUR 1,800 remain. With one-off costs of EUR 18,000, it would take, in calculation terms, ten months until these costs were covered by the benefit applied. That holds only if the freed-up capacity can actually be used accordingly or translated into avoidable expenditure.

At a 50 per cent exception share, the average processing time rises to five minutes. 40 hours are still freed up. With the valuation rate unchanged, EUR 1,000 of monthly capacity value remains after ongoing costs; the notional coverage of the one-off cost would be 18 months. This sensitivity is a planning aid. It does not replace measurement.

Before any expansion, comparable orders with and without support should therefore be evaluated: processing time including checking, necessary rework, records that remained open and impermissible multiple creations. For the effort estimate, interface work, master data maintenance, operation and renewed acceptance tests also belong on the list.

Start with a limited customer format

A sensible initial scope can be described in terms of subject matter: a group of known customers, clearly assignable items, defined units and a specific route into the ERP. Within this framework, proposals are generated first and compared with the previous processing. The transfer can then be added under the agreed approval rules.

This form of AI process automation provides concrete decisions for further expansion. If, for example, most queries arise from missing packaging units, the next work step lies in the master data or the order format. A different language model does not automatically solve this problem.

For structured orders from a portal or an existing electronic data interchange (EDI), the existing rule-based import can be sufficient. The benefit of language-based AI lies rather with varying wordings and document layouts whose details can subsequently be checked. The decision should depend on the actual incoming material.

For a pilot, the materials should include: representative orders including exceptions, permitted customer and item data, binding check rules, roles, interface description and expected results defined by subject matter. A separate clarification route for open records belongs in from the start.

How T-NEX can classify such a process

T-NEX describes workflow automation for companies as a combination of inputs, responsibilities, approvals and existing systems. The Document AI supplements the capture and checking of details from documents. For the case described here, both tasks would have to be planned together with the specific ERP interface. [4]

The sample case describes one possible project scope. It does not prove a finished standard connection to a particular ERP or any automation rate already achieved. Before implementation, the company's available interfaces, required fields, roles and rules are checked.

Sample case and working materials

The materials contain the example email, the order sheet, the field mapping, seven decision rules and all 14 acceptance tests. The editable workbook adds a calculation with changeable assumptions. The reading version presents the case even without a spreadsheet.

All prices and costs mentioned in the case are freely chosen calculation values. The tests provided are set to “Not performed”. Your own measured values, check evidence and approvals are entered only in an actual trial.

Questions from implementation

Can the AI create customer orders directly in the ERP?

After the agreed checks, an application can create an order via a suitable interface. Prerequisites are a limited scope of permissions, clear approval rules and a way of handling errors and repeats. In the sample process, a proposal is created first; an open price variance prevents the transfer.

What happens with handwritten or poorly scanned orders?

Such receipts belong in your own test set. Illegible mandatory details remain unresolved and trigger a query. Whether the recognition in use processes these documents sufficiently can be assessed only on the basis of representative examples and the actual field errors.

How do you distinguish a duplicate from an order change?

First, the customer and the business order reference are matched. The relevant contents are then compared with the existing version. An identical repeat is assigned; changed quantities, prices or recipients create a change case that requires checking. Message identifier or file hash alone are not sufficient for this.

From what volume is automation worthwhile?

A fixed number cannot be given without the effort and error profile. Decisive are the time gained after checking and rework, the exception rate, interface effort and ongoing costs. The accompanying calculation makes these assumptions changeable and separates capacity gain from savings that affect cash flow.

Sources and subject-matter classification

Source check status: 16 October 2026. Technical sources support the principles named in each case. The sample process, the decision rules and the calculation assumptions are editorial proposals. Podcast passages are paraphrased; the transfer to the sample case is in each case recognisable as our classification.

1. Microsoft Learn: Dokumentenerkennung, Konfidenzwerte und fachliche Prüfung. Basis for classifying recognition certainty and own check thresholds.
2. Amazon Builders’ Library: Making retries safe with idempotent APIs. Basis for repeatable system calls and unique request identifiers.
3. OWASP Cheat Sheet Series: LLM Prompt Injection Prevention Cheat Sheet. Risks from instructions in external content and limits of model control.
4. T-NEX: Workflow automation and Document AI. Vendor statements on the scope of services; the specific implementation is checked for each project.
5. Der Industrie Podcast des VDMA: Struktur schlägt Hype: Der wahre Erfolgsfaktor für KI im Maschinenbau, 14.04.2026. Passage used with Christoph Haß: 13:47–15:45. Paraphrase based on a transcript of the episode.
6. DigiCast, Mittelstand-Digital Zentrum Handwerk: Folge 47: 1000 Rechnungen mit KI im Griff - Von der Handarbeit zu Automatisierung, 15.10.2025. Passage used with Heiko Süthoff: 20:37–25:35; 31:07–34:27. Paraphrase based on a transcript of the episode.
7. AI FIRST, Felix Schlenther: Agentic AI im ERP: Wie BLP 300 Agenten in Kernprozesse bringt, 14.08.2026. Passage used with Tim Beck: 42:07–46:03. Paraphrase based on a transcript of the episode.