Automating order processing: how it works

With automated order processing, software takes the order from the mailbox, reads the data from the attachment, checks it against the ERP (the business system for customers, orders and stock, among other things) and creates the order. Only orders with an exception still go to an employee, with the reason attached. What this delivers depends mainly on the format of the orders and on the number of exceptions that an employee has to assess. A fixed Excel list is much simpler than a scanned PDF, and an order that is not correct stays manual work.

The example in this article

How it works now, and how it can work

The work does not disappear completely. It shifts from typing to reviewing: orders with an exception go to a review queue, the list of cases that an employee reviews.

Order processing, manual and automated
Step	Now	Automated	Who
1. Receive	The employee sees a new email in orders@	The software sees the email and recognises whether it is an order	Software
2. Read	The employee opens the PDF or the Excel file	The software reads the customer, lines, quantities, prices and date	Software; doubtful cases go to an employee
3. Check	Look up the customer, go through the items and prices	The software compares everything with the ERP	Software
4. Process	Type the order into the ERP	The software creates the order through an integration, an import or a robot (software that operates the screens like an employee)	Software
5. Exceptions	Call or email the customer	The order goes to the review queue with the reason	Employee
6. Confirm	The employee sends the confirmation	The ERP sends the confirmation, as it does now	Software
7. Record	Spread across the mailbox and the ERP	A log per order and a daily overview	Software; checked by an employee

Step 1: the order comes in

Start with one entry point. A shared mailbox such as orders@ works well, provided customers send their orders only there. The automation does not see orders that reach a salesperson personally. Have the salesperson forward them, and keep in mind that the sender is then no longer the customer. If large customers put their orders in their own supplier portal, that is a second entry point. It needs its own route, for example an export from the portal or a software robot that collects the orders.

The first question for the software is: is this an order? Fixed rules usually work well here. The sender belongs to a known customer, there is a PDF or Excel attachment, and the subject or the attachment mentions an order number. Questions, complaints and delivery queries go to a separate folder. The software does not answer them.

Allow for these cases:

One email with three orders as separate attachments, or one order split across two emails.
A correction ("replaces our order 4512 of yesterday"). It must not become a second order.
Logos from the email signature, which also come through as attachments.
An attachment in a zip file, or a PDF with a password.

Access to the mailbox: one mailbox, not all of them

In Microsoft 365, software usually reads a mailbox through Microsoft Graph, Microsoft's programming interface, also for a shared mailbox. This uses modern authentication (OAuth 2.0). A username and password alone no longer work in Exchange Online for reading email.

Pay attention to the permissions. According to Microsoft, the application permission Mail.Read gives access to the email in all mailboxes of the organisation, including those of the management. With RBAC for Applications (role-based permissions for applications) in Exchange Online, the administrator limits that to, for example, only orders@. Then also remove the broad permission in Microsoft Entra ID (Microsoft's management of accounts and permissions), otherwise the limit does not work. Never use an employee's account.

Step 2: reading the data

How hard the reading is depends on the format in which the order arrives. This is often the most important factor for the cost and the result.

Order formats and what they mean for reading the data
Format	How the software reads it	Reliability	Watch out for
Excel or CSV with fixed columns	Directly by column name	High	An extra or shifted column, the date format, the decimal separator
PDF from a system	The text is in the file; a template per customer or document recognition	Good	Each customer has its own layout, and it can change without notice
Scan or photo	First text recognition (OCR), then document recognition	Variable	Skewed or blurred scans, handwritten notes
Text in the email itself	Interpreting free text	Low	A fixed order form often pays off more
Portal, web shop or EDI	No reading: the data is already structured	Highest	Needs an integration and the customer's cooperation

EDI (electronic data interchange) is a fixed electronic message format for orders and invoices between companies. OCR (optical character recognition) turns the pixels of a scan into text.

Document recognition and confidence scores

For PDFs and scans from many different customers, you use document recognition: software that finds fields such as the customer number, order lines and delivery date, even when the layout differs. Such services give a confidence score per field. For Azure AI Document Intelligence, Microsoft describes this score as an estimated probability between 0 and 1 that the result is correct. A score of 0.95 means that the outcome is right about 19 times out of 20. At 80 orders per day, one error in every twenty fields is a lot.

So work with a threshold per field. Above the threshold, the field goes through automatically; below it, an employee checks it. Choose a stricter threshold for quantities and prices than for a reference field. Microsoft itself recommends building in this kind of human check. But a score only tells you how sure the software is about the reading. A price that was read perfectly can still be the wrong price. That is why step 3 always follows the reading.

With scans, pay attention to the quality. Microsoft asks for one clear photo or good scan per document, text of about 8 points or larger at 150 dpi, and PDFs without a password. Also watch the notation. A Dutch file can use a comma as the decimal separator and a dot for thousands, so "1.250" may mean 1250 or 1.25. And 03-04 can mean 3 April or 4 March.

Step 3: checking before anything goes into the ERP

The ERP checks whether something is technically allowed: does the customer exist, is the item active? It does not check whether the order matches what the customer meant or what you agreed. For the ERP, an order with an existing item and a wrong price is simply valid. So build in these checks:

Known customer. Look up the customer by the account number or the customer number on the order, not only by name. If a customer appears twice in the ERP, the software cannot choose. Clean up duplicate customers first.
Delivery address. Is the address already on file for the customer? A new delivery address goes to an employee. That prevents errors and makes misuse harder.
Item codes. Customers often use their own item numbers. Translate them with a cross-reference table: a list with the customer's item number and your own item number. Maintain that table in the ERP, not in a separate Excel file. Also check that the item has not been discontinued.
Drawing and revision. Does the order name a drawing number and a revision, for example for customer-specific parts? Then check whether that revision is the current, released revision in your ERP. An order on an older or newer revision goes to an employee.
Quantities and units. Are the packaging unit and the minimum order quantity correct? Ten boxes is not the same as ten pieces.
Prices. Compare the price on the order with the price agreement in the ERP. A small difference within a margin can go through automatically. You set that margin yourself.
Delivery date. Is the requested date not earlier than today plus the normal delivery time? A rush order goes to an employee. If you make the product to order, the delivery time depends on capacity and material. Leave that assessment to the planners.
Duplicate orders. Does the customer's order number already exist in the ERP? If the software stops after the order is created but before the email is marked as processed, a new attempt must not create a second order. So check first, and only then create. Orchestrator, UiPath's management platform for software robots, can for example enforce that each reference occurs only once in a queue (the list of work that the robots process).
Remarks. A sentence such as "please deliver together with the previous order" always goes to an employee. A remark that nobody reads becomes a complaint later.

Check against the current data in the ERP, not against a copy that slowly goes out of date.

Step 4: putting the order into the ERP

There are three routes for creating the order. Which one fits depends on what your ERP offers.

Integration (API). An API is a fixed entry point through which software reads and writes data, without screens. Exact Online, for example, has a REST API for sales orders, in which the customer and the order lines are required. An API is fast and stable, and the ERP reports straight away what is wrong. Someone does have to build and maintain the integration.
Import file. The software creates a CSV or XML file in the structure that the ERP expects. This is often the fastest start. Do read the import report, though, because an error in line 37 is easy to miss.
Software robot. A software robot (RPA, robotic process automation) uses the same screens as an employee. This also works without an API, but it is slower and sensitive to screen changes.

Choose the most stable route that your ERP offers. The trade-off is explained in RPA or API integration: which is the best choice?, and the routes for Excel data in Connecting Excel to ERP. Give the account of the integration or the robot permissions for orders only.

Step 5: the review queue for exceptions

Every automation gets orders that are not correct. Design the route for those orders before you build. With an exception in the content, such as an unknown item or a different price, retrying does not help: a person has to decide. With a technical error, such as an ERP that does not respond, retrying often helps. If it still fails after a few attempts, the administrator gets an alert. UiPath makes the same distinction in its documentation. How you handle and monitor both kinds of error is explained in why RPA projects fail.

In the review queue, the employee sees for each order the original email and attachment, the data that was read and the reason the order stopped. After the correction, they put the order back into the flow, without retyping everything. This way, only the decision stays work for a person, and the rest runs automatically. You can read more about this set-up in human in the loop.

A review queue only works with an owner and fixed times, also during holidays. Look at the most common reasons every week. You can often solve a recurring exception at the source: a new line in the cross-reference table, or a customer who changes their own item numbers.

Step 6: the order confirmation

Let the ERP send the order confirmation, as it does now. Then the layout, the terms and the archive stay the same, and the automation does not need permission to send email. If there is an exception, the employee decides what the customer is told. Also check which address the confirmation goes to: the buyer's address on the order is not always the sender of the email.

Step 7: recording and monitoring

For each order, record when the email arrived, the order number from the customer and in the ERP, the result and who handled any exception. Then you can answer questions from customers and you see which problems keep coming back. A daily overview shows how many orders were processed automatically, how many are in the review queue and which ones failed.

The biggest risk is an automation that stops silently. So set up an alert for when the mailbox has not been read for a while, when the ERP cannot be reached or when many orders fail.

Privacy: which data and for how long

Orders between companies also contain personal data. According to the Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP), data about a company is not personal data, but the name and email address of a buyer are. That also applies to a business email address that only one employee uses. Three rules from the GDPR (the European privacy law; in Dutch: AVG) matter here:

Data minimisation. Do not process more personal data than necessary. Take over only the fields that the order needs, and do not copy complete emails into a log.
Retention period. The GDPR sets no fixed period. You decide it yourself and record the reasons; other laws, such as tax law, can impose a period. Give temporary copies, such as files that were read and logs, a short period.
Data processing agreement. Does a cloud service process the orders for you, for example for document recognition? Then that party is usually a processor, and according to the AP you must conclude a data processing agreement together. Also ask where the data is stored.

What does it deliver? The worked example

The question is not how much time the inside sales team spends on orders now, but how much time is actually freed up.

Worked example (illustrative): time per working day and per year
Item	Calculation	Per working day	Per year (230 working days)
Gross time now	80 orders × 4 minutes	320 minutes	≈ 1,227 hours
Exceptions stay manual work	12 orders (15%) × 4 minutes	− 48 minutes	≈ − 184 hours
Daily check	Reviewing the daily overview and alerts	− 15 minutes	≈ − 58 hours
Time actually freed up	320 − 48 − 15	257 minutes	≈ 985 hours

Assumptions: the figures from the example at the top, 230 working days per year and 15 minutes of checking per day. Replace them with your own figures.

The full 320 minutes never count as a saving: the exceptions remain work, and the automation needs attention every day. An exception also often takes more than 4 minutes, because someone has to find out what is going on. Development, licences and maintenance are costs, not time saved. For those, see what it costs to automate a business process and when automation pays off for a small business.

Alternatives: it does not always need software that reads orders

Sometimes it is better to change the format of the orders than to build software that learns to read every format.

Approaches to order processing compared
Approach	Strong at	Limitations
Manual, with a fixed work instruction	Few orders, much variation, much consultation	Still takes time; typing errors remain possible
A fixed order form (Excel template) for customers	Cheap; simple and reliable to read in	Customers have to cooperate; old versions of the template stay in circulation
Ordering through a web shop, customer portal or EDI	The data arrives structured; no reading needed	Not every customer takes part; building it or a subscription costs money
Software that reads and enters orders, as described above	PDFs and scans from many different customers; with a robot, also ERP packages without an API	Costs per document or a subscription; human checks and maintenance remain necessary

A combination is often best. Large customers order through a portal or a fixed form, the rest comes in through document recognition, and the order goes into the ERP by the most stable route.

Decision framework: where do you start?

Ask these questions internally before you have anything built:

How many orders come in per day, and in what format? Count for one week: Excel, PDF from a system, scan, free text.
How many orders have an exception, and why? For one week, write down the reason for each exception.
What does your ERP offer: an API, an import function or only screens? Is API access included in your licence?
Who will own the review queue, the cross-reference table and the thresholds?
Will a new ERP or a new order portal arrive within a year? Then waiting is often wiser. See when it is better not to automate a process.

The factors that weigh most are the format of the orders, the share of exceptions that need judgement and the entry point of your ERP. A high volume with a fixed format and an ERP with an API is the most favourable situation. Few orders, many scans and many exceptions without a fixed rule is the least favourable.

Outside help makes sense if you need an integration with the ERP, if you want to set up document recognition or if you are unsure which route fits. A short process analysis then shows which steps are suitable, before anything is built. You make a first estimate yourself with the four questions on the services page: four short questions, without a tool or a calculation.

Limitations and drawbacks

Do not count on a hundred per cent. With orders from email, some exceptions remain that need judgement. A plan that allows no time for them paints too rosy a picture.
Maintenance. Cross-reference tables, thresholds and templates need regular attention. If a customer changes their PDF layout, you only notice when their orders end up in the review queue. What maintenance costs is explained in what maintaining a software robot costs.
Blind trust. When everything goes well for months, nobody looks critically any more. Keep up the daily check, even when it gets boring.

Conclusion

Automated order processing works best if you start small: with the customers that order most and use a fixed format. The checks before the ERP and the review queue for exceptions decide whether it is reliable, more than the software that reads the PDF. And the cheapest order to automate is often the order that already arrives structured, because you changed the source.

Automating manual order processing: how it works