AI order entry: orders from email and PDF automatically into your ERP or TMS. What it delivers and where it goes wrong

What is AI order entry, and what is it not?

AI order entry is software that reads an order the way an order handler does: from the body of an email, from a PDF or from a scan of an order form. The system identifies the customer, the items, the quantities, the units and the requested delivery date, and places them in your system as an order or draft order. The difference from traditional text recognition is that AI can also determine which field means what when the layout varies.

There are two things it is not. It is not EDI: an EDI message is already structured and does not need AI. And reading is not yet checking. A system that reads '40 box' does not thereby know whether the customer meant 40 units. That check against your own customer and item data is the real work, and it is also where most problems arise.

EDI or email: which orders qualify?

Start with a count per channel. Orders via EDI are already structured. GS1 Belgium & Luxembourg describes EDI as 'the way to exchange commercial, logistical and financial data between trading partners in an automatic way' (translated). According to GS1 Netherlands, the item code forms 'the basis for exchanging electronic messages via GS1 EDI' (translated). If you already have EDI with your large customers, you do not need to run those orders through an AI system.

AI order entry is meant for the rest: the smaller customer who orders in the body of an email, the customer who emails a PDF from their own purchasing system, the shipper who sends a transport order as an attachment. For those orders, the question is not whether you can insist on EDI, but whether the retyping can be done faster and more reliably.

Meanwhile, Microsoft is building EDI into Business Central itself. Update 29.0, the start of 2026 release wave 2, lists 'Exchange EDI documents' as a public preview. It is an extension of the E-Documents framework, with Peppol BIS 3 as the format and support for exchanging orders. A preview is not yet generally available. We would not build a production process on it until it is.

Three routes: ERP agent, document AI or your own flow

Broadly, there are three ways to get orders from email and PDF into your system. The examples are from Microsoft, because Microsoft documents the details publicly. We mention them to show how the routes work, not as a recommendation. Ask your own ERP or TMS vendor what it offers in each of the three routes.

• ERP agent. An agent in your ERP reads a mailbox and creates a quote or order itself. Example: the Sales Order Agent in Microsoft Dynamics 365 Business Central. Advantage: it works directly with your own customers, items, inventory and prices. Disadvantage: you work within the limits the vendor has built.
• Document AI as an add-on. A separate service extracts data from PDFs and scans and passes the fields to your ERP or TMS through an integration. Examples: Azure Document Intelligence or the document processing model in AI Builder. Advantage: it works alongside any system with an import option, including a TMS. Disadvantage: you set up the check against your master data yourself.
• Your own flow. A Power Automate flow is triggered by a new email, has a prompt or document model extract the order lines and creates an order through a connector. Advantage: you decide every step. Disadvantage: you own the logic, the error handling and the maintenance yourself.

Route 1: what the Sales Order Agent in Business Central does

According to Microsoft's documentation, the agent monitors a designated Microsoft 365 mailbox, looks up the customer, checks inventory and creates a quote or order. It reads the email body and, if enabled, attachments in PDF, PNG or JPG. A PDF may be up to 50 pages long. If information is missing, the agent itself emails the customer to obtain it. It first submits all outgoing messages to a designated employee for review.

Three design choices matter for order entry. The agent always creates a quote first, even if the customer asks for an order. Microsoft calls a quote a safe intermediate document, because it has no effect on planning, reservations, availability or the cash flow forecast. The agent does not post any documents itself. And it does not adjust prices and discounts: Business Central calculates those itself, and the agent refers a request for a different price to an employee.

Recent additions. The overview of update 29.0, dated 29 September 2026, lists as generally available, among other things, a single task pane for the tasks of all agents, simpler management of agent permissions, reviewing what an agent has filled in directly on the page, and better matching with purchase orders in the Payables Agent. It had already become possible on 8 July 2026 to run multiple Sales Order Agents per company, with better item recognition and a filter that stops messages outside the order scope. Existing customers can schedule update 29.0 within an update period that ends in February 2027.

Microsoft is not consistent about Dutch. The table of availability by country and language lists Dutch (nl-NL and nl-BE) for the Sales Order Agent. The setup guide lists the languages in which the agent is 'validated and supported', and Dutch is not among them. Outside those languages, the agent 'might not function as intended', Microsoft writes. So test with your own Dutch-language orders before you build on it. According to Microsoft, input in mixed languages also produces lower quality, because item recognition then relies partly on literal text matching. One example is an email in German with Dutch item names.

The agent is billed in Copilot Credits. Microsoft counts a standard request as follows: 2 credits for analysing the email, 5 for the inventory check, 5 for creating or updating the quote or order, 2 for the reply email, and 5 per attachment containing order data. In Microsoft's own worked example, 100 requests per month of which half include a PDF order, that comes to 1,650 credits per month. What a credit costs depends on your licensing model: prepaid capacity or pay-as-you-go. Ask your partner for that price in euros. Also note the default maximum of 100 incoming emails per day. The agent does not process emails above that number until the next day.

On data, Microsoft writes that for a Business Central environment within the EU Data Boundary, an Azure OpenAI endpoint within that same boundary is used. Prompts and responses are retained for 20 days for support purposes, and Microsoft states that it does not use them to train AI models. Have your IT partner check which settings apply in your environment.

Route 2: document AI as an add-on to your ERP or TMS

Document AI reads a document and returns structured fields. It is not an order system. It tells you what is on the page. Your integration and your ERP or TMS determine what happens with it.

Azure Document Intelligence has prebuilt models for invoices, receipts and contracts, among others. Microsoft's overview does not include a prebuilt model for purchase orders. For orders, you train your own custom extraction model. Microsoft gives five examples of the same document type as the minimum to get started. In AI Builder this is called a document processing model, with a 'collection' of at least five sample documents per layout. Each customer with its own order form is then a separate collection. The latest version also provides a confidence score per table cell, which lets you set aside doubtful cases.

This route is a good fit when you receive many PDF orders in a fixed layout, or when your ERP or TMS has no AI feature of its own but does have an import or API. The work is in the integration: looking up customer and item codes, converting units, setting aside discrepancies. How extraction works and where it goes wrong with freight documents is described in our article on document extraction for CMR, T1 and eCMR.

Route 3: your own flow with Copilot or ChatGPT and Power Automate

You build the third route yourself, or have it built. A Power Automate flow is triggered by a new email in a shared mailbox. A prompt or a document model extracts the order lines from the email or the attachment. The flow then uses the Business Central connector to create a record in the table you specify. With a different ERP or a TMS, it depends on the integrations your vendor offers.

Here too you pay per use. According to Microsoft, document processing in a flow costs 8 Copilot Credits per page, or AI Builder credits for as long as you have them. A prompt costs credits per thousand tokens, depending on the model. If you use your own model from Microsoft Foundry for the prompt, you pay for the processing through Foundry, according to Microsoft. The flow itself falls under your Power Automate licence.

The advantage is control. You decide which fields are mandatory, when an order goes to a human and what is recorded. The disadvantage is the same: no one else does that for you. An example from the documentation: with a certain attachment setting in Microsoft Defender, the email trigger can fire twice, the first time without the attachment. Without an extra check in the flow, as Microsoft itself recommends, that can produce an empty or duplicate order. A flow that only works as long as its builder is around is a familiar pattern in AI projects that stall after the pilot. So record who the owner is and who adjusts the flow when a customer changes its order form.

A lighter variant is for an order handler to paste the email into ChatGPT or Copilot Chat, have it turned into a table and copy that over. That saves typing, but there is no integration, no record and no fixed check. Only use a business tool approved by your organisation for this, as described in our ground rules for ChatGPT and Copilot in the workplace.

Draft or automatic processing: what may the system do on its own?

This is the most important choice, and you make it for each step. Start with drafts: the system prepares a draft order or quote, and an order handler checks it and passes it on. In the framework from our article on what an AI agent may do on its own, that is level 2, preparing.

Business Central shows how configurable this is. With two switches you decide whether the customer first receives the quote for confirmation, and whether the agent converts a quote into an order itself. If confirmation is off and conversion is on, the agent creates an order directly and the customer never sees the quote. As an example, Microsoft describes a second agent for trusted customers with exactly that setting, alongside a shared mailbox where all review steps are switched on. An approval workflow can also require another employee to approve before a quote is released.

Automatic processing only suits orders that meet every rule: known customer, all items recognised, units correct, delivery date achievable, no non-standard price. Everything else is an exception and goes to a human. Only go a step further once you have measured how often corrections were made, and why.

Where does AI order entry go wrong?

Some of the pitfalls are spelled out in Microsoft's documentation. They also apply to other systems, because they arise from the orders themselves.

• Unknown sender. The Business Central agent recognises a customer only by the email address on the contact card, not by name or company name. That is deliberate, to prevent misuse. If a customer emails from a new address, an employee has to link the customer.
• Forwarded emails. If a colleague forwards an order to the mailbox, the agent uses that colleague's address. The customer is then not recognised.
• Long orders. The agent currently supports up to 15 item lines per document. According to Microsoft, more lines can lead to lower quality. Check in your baseline measurement how many lines your orders have.
• Variants and line types. The agent does not fill in a variant code and only works with lines of the type Item, not with, for example, charges or resources.
• New items or customers. The agent does not create items, contacts or customers. If a customer orders something that is not in your system, the order goes to a human.
• Units. 'Ten' can mean units, boxes, cases or pallets. Record for each customer which unit applies when none is stated, and have the system flag discrepancies instead of guessing.
• Changes and cancellations. A second email that amends an order must end up with the right order. At the customer's request, the Business Central agent amends a quote, but not an order that already exists.
• What is not in the email. An agreement made by phone, a fixed delivery day or a customer who always receives a certain quality: the system only knows about these if they are in your master data.

Master data: get item and customer numbers in order first

An AI system cannot match an order any better than your master data allows. Microsoft says so itself: the quality of the product information in Business Central determines how well the agent works, and cryptic abbreviations in item names lower the quality of the result.

The agent first searches on exact codes: your item number, your supplier's item number, the GTIN or a cross-reference. Only then does it search on attributes such as colour, size or material, and finally broadly on text. That points to preparatory work that applies to every route:

• Customer item numbers. Record the numbers your customers use themselves as cross-references on your items. In Business Central this is called an item reference.
• Email addresses. For each customer contact, enter the address they order from. Contacts without an address require manual work on every order.
• Item descriptions. Replace internal abbreviations with descriptions a customer would also use, and fill in attributes and categories.
• Units. Record the sales units and conversions for each item, so that box, case and unit do not get mixed up.
• Addresses. Record fixed delivery addresses, loading and unloading addresses and time windows on the customer record. For transport orders, that is the essential part.

Transport (TMS) or wholesale (ERP): what is different?

In wholesale, an order is a list of items with quantities, units and a delivery date. The price comes from your ERP. The risks lie in the wrong item, the wrong unit and a delivery date that does not fit the inventory or the route. In the fresh produce trade (AGF: potatoes, vegetables and fruit), attributes such as quality class, size and origin also come into play. The system must be able to find those as an item attribute or variant. Note: the Business Central agent does not fill in a variant code.

In transport, an order is a shipment. The system must recognise loading and unloading addresses, time windows, numbers of pallets, weight, references and special requirements, such as a temperature requirement or dangerous goods. That is a different kind of document from a sales order. The Sales Order Agent was not built for that: it only works with sales quotes and sales orders with item lines. For a TMS, the main candidates are therefore document AI with an integration, your own flow or a module from your TMS vendor.

With refrigerated transport and dangerous goods, do not let any order go through automatically if a field is missing or deviates from the norm. An order without a temperature requirement is not the same as an order without a temperature risk. Record in the work instruction that such an order always goes to the planner.

The measurement differs too. In wholesale you count errors per order line: item, quantity, unit. In transport you count errors per shipment: address, time window, weight, a missing requirement, and what the consequence was, for example a trip that had to be replanned.

What does AI order entry deliver? Start with a baseline measurement

We deliberately do not give a savings percentage. What it delivers depends on how many orders you receive via email and PDF, how long retyping takes now and how many errors already occur. You will only know that after a baseline measurement. For reference: in a survey by software vendor Descartes of 300 senior decision-makers at shippers and logistics service providers in Europe, 75 of them in Belgium and the Netherlands, 41 percent said they use AI to automate data entry and convert unstructured data. That says something about how common it is, not about what it delivers.

For one week, before anything changes, measure the following for each order:

• The channel: EDI, portal, email body, PDF attachment or phone.
• The number of orders per week per channel, and the number of lines per order.
• The minutes per order, from receipt to order in the system. Include the time spent working things out, not just the typing.
• The corrections afterwards: which field was wrong, and who discovered it. The order handler, the warehouse, the driver or the customer.
• The exceptions: orders that could not be entered without consultation, with the reason.
• The time to order confirmation, if your customers pay attention to that.

Doing the sums without embellishment

Multiply the number of orders per week via email and PDF by the minutes per order. That is your current entry time. The gain is never that entire time. Checks and exceptions remain work, and setting up and maintaining master data also takes time. The question is how many minutes per order remain, and whether the number of errors falls or rises.

Set against that the cost per processed order: credits, licences and the hours of whoever manages the system. An error that only comes to light at the customer weighs more heavily than one the order handler spots. So weigh them separately.

A 30-day measurement plan

Thirty days is enough to see whether a route works on your own orders, provided you record in advance what you are comparing.

• Week 0, beforehand: the baseline measurement above. Choose which customers and which channel take part. Start with customers who order a lot by email or PDF and have few exceptions.
• Week 1: get the master data in order for those customers, with email addresses, customer item numbers and units. Write the work instruction: which fields the system fills in, what the order handler checks and when an order goes to a human. Do this in the language of your quality system, whether that is HACCP, FSSC 22000, BRC, IFS or GMP+.
• Weeks 2 and 3: the system only creates drafts. The order handler checks every draft and notes for each correction which field was wrong. Track the minutes per order, including the check.
• Week 4: compare with the baseline measurement. Look at minutes per order, corrections per hundred lines, the share of exceptions and errors that only surfaced in the warehouse or at the customer. Also calculate the cost per processed order.
• Day 30: decide whether you continue with drafts, go a step further for a group of trusted customers, or stop. Record the decision and the reason.

What questions should you ask a vendor?

A demo shows what happens when the order is tidy. For your decision, what counts is what happens when it is not.

• Which channels and formats does the system read: email body, PDF, scan, Excel? With what limits on pages and lines?
• In which languages has it been tested, and specifically in Dutch?
• How does it recognise the customer, and what happens with an unknown sender or a forwarded email?
• Does it create drafts or final orders, and can we configure that per customer?
• Can we see for each order which fields the system filled in?
• What does it cost per processed order, measured on our own orders?
• Where are emails and attachments processed, and how long are they kept?

Where to start

Choose one process, one group of customers and one route. First do the baseline measurement and get the master data for those customers in order. That work is never wasted: every route needs it, even if you switch routes later.

On a Practice Day we work for a day at your own location with the people who enter the orders every day. We set up the baseline measurement, write the work instruction with the exception rules and set up the first step on your own orders. Your team learns it while it is being built. The Practice Day costs from €2,500 per group, excluding VAT.