To automate email orders, connect the inbox to a process that reads the request, identifies the customer and their items, checks quantities, and prepares the order in your management system. AI helps when the information arrives as free text or documents; the catalog and company rules determine what can be recorded.
The starting point can be a draft with review. Whoever checks it should see the original email, the proposed lines, and any open questions in one place. That way they can correct a reference or resolve a mismatch without retyping the whole order.
Define which messages should become orders
A commercial inbox contains orders, price requests, changes, cancellations, and replies about deliveries. Before extracting items, identify what the message is actually asking for. «Do you have these SKUs?» may still be a stock availability query.
AI-powered email classification can help route each case to the right path. Keep the message ID, the sender, and the customer’s order reference, when one exists. If the email was forwarded by a salesperson, also identify which customer it belongs to.
Decide which formats are in scope first. A PDF with a table, a spreadsheet with known columns, and a request written in the body of the email need different handling. Structured sheets can be read with import rules; reserve AI interpretation for the fields that need it.
You also need to distinguish useful documents from logos, signatures, and repeated attachments. Save the source that supports each proposal, including any later messages that change the request.
Reading one line is not enough to know what to ship
The document reader must recover references, descriptions, quantities, and units while keeping their relationships intact. If a table continues on another page, check that its lines were captured in full and that a repeated header did not turn into another product.
There are tools for this part. AI Builder lets you use fields and tables extracted from documents in a Power Automate flow. Its documentation covers values and confidence scores per field or cell; before choosing it, you need to check the formats, the model, and the account requirements.
After reading comes the check against your data:
| Order data | Required check |
|---|---|
| Customer | Correct account and confirmed delivery address. |
| Item | Your catalog SKU and requested variant. |
| Quantity | Number, sales unit, and applicable conversion. |
| Quoted price | Match with the current commercial terms. |
| Requested delivery | Availability and date the team can confirm. |
Keep a customer-specific code mapping table when they use their own codes. An approximate match in the description can help propose candidates; if there are several possible products, it should stay pending review.
Units deserve an explicit rule. For example, Business Central distinguishes base and alternative units of measure, with a conversion quantity for each item. In your integration, use the approved equivalence in the catalog. A «box» does not have to contain the same quantity across all SKUs.
Example: eight boxes and a new address
A distributor receives this fictional message:
Order OC-418: we need eight boxes of CL-7. Delivery to the new warehouse on Friday. I’ve attached the order in PDF.
Let’s assume the validated equivalence for that customer maps CL-7 to your item ENV-025 and that each box contains 25 units. The draft can show 8 boxes, equivalent to 200 units. This is a calculation in the example, not a quantity that should be inferred from the product name.
Now imagine the attached PDF says six boxes. The system should flag the difference between the email and the document, keep both values, and ask which one should prevail. Automatically recording the first value that appears would hide a pending decision.
«New warehouse» also does not let you reuse the usual address as-is. The full address still needs to be confirmed and linked to the correct destination. The same goes for «Friday»: you need a specific date and must check whether it can be met.
A useful review would highlight those three issues: conflicting quantity, address pending, and delivery to be confirmed. The rest of the lines can be prepared while they are resolved, depending on how your company handles incomplete orders.
Make it clear when it is received, recorded, and confirmed
Design statuses the team can recognize:
- Received: the request and its documents have been saved.
- Pending review: lines are prepared and unresolved questions are visible.
- Validated: a person or an approved rule has resolved the required checks.
- Recorded: the management system returns a reference that lets you look up the order.
- Confirmed to the customer: the terms the company accepts have been communicated.
In the pilot, you can stop the flow before final recording. When you connect it to the ERP, check what effects creating or changing that document has: it may trigger other processes depending on the configuration. The scope should state whether it only prepares a draft or also reserves stock or starts picking.
A stock query does not by itself equal a reservation. If confirmation depends on inventory, use the result the management system considers valid at that moment and respect its rules for partial deliveries.
The receipt acknowledgment and the commercial confirmation must say different things. You can inform someone that a request has arrived while it is still pending review, without promising items, prices, or dates yet.
Treat forwards and changes as separate cases
A customer may forward the same PDF to sales and to administration. Link the document to the customer and their order reference, in addition to the message’s technical ID. Two different emails do not necessarily mean two orders.
At the same time, a document with the same reference may contain a change. Detect changes in lines, quantities, or destination and present them against the recorded version. Do not discard a revision just because the number already exists.
If the order is already in progress, a cancellation or an address change requires checking the operational status. The flow should route that decision to the responsible person and keep what was changed and who approved it.
If the connection fails after trying to save, check the result before repeating the operation. The ERP may have created the order even if the response never came back. Keep a stable reference to reconcile the attempt and avoid duplicates.
Check the result with complete orders
The Document Intelligence documentation explains how to interpret extraction confidence and includes human review. That score helps decide what to review; you also need to check that the product, unit, and recipient are correct for your business.
Test documents from the customers who will take part in the pilot. Include multi-page tables, unknown references, boxes with different equivalences, forwarded orders, and changes after recording. Add a connection failure to check how it recovers.
Measure correct orders end to end, corrected lines, detected duplicates, and review time. A good reading result loses value if you later have to look up the address or rebuild the quantities by hand.
To study the initial scope, prepare sample orders, the catalog, customer equivalences, and the name of your management system. At Digency we build custom automations to connect that flow. Tell us how you receive and record orders today and we’ll define which part can be prepared for your team.
Header image: AI-generated illustration.
