Why format variation is the real problem
At many companies looking to automate sales order processing, the first conversation is about volume: how many orders per day, how many per year? That is a logical question, but it is not the hardest one. The hardest question is: how many different customers are sending those orders, and do they all use the same format? The answer is almost always no. Customer A sends a clean PDF with a consistent layout. Customer B sends a Word document that looks slightly different every time. Customer C calls, after which a sales representative sends an email that is treated as an order. And customer D has a purchasing system that outputs an XML file, but that file reaches you as a PDF printout. Building an automation solution around customer A's clean PDF still leaves a manual process for B, C, and D.
What goes wrong when you work with templates?
The classic approach to document processing relies on templates: for each supplier or customer, you define where field X appears on the document. That works reasonably well if you have ten fixed customers who never change their layout. In practice, customers do change their layouts, if only because their own ERP receives an update. When that happens, the template breaks and you are left waiting for someone to configure a new one while orders pile up. Template-based recognition also performs poorly on scanned documents with a skewed scan angle, on photos of paper orders, or on documents where tables are formatted slightly differently than expected. The result: exceptions still land with the employee who was already overloaded.
What practice teaches you about setting up order processing
A recurring pattern at companies tackling order processing: the first few weeks go smoothly, because you start with the most standardised customers. Then the exceptions arrive. The customer who requires their purchase order number to appear on the confirmation. The customer who uses article codes that do not match your own item numbers, requiring a translation step. The customer whose order amounts include VAT while your system expects net figures. Each of these situations is solvable on its own, but failing to map them out in advance means running into them repeatedly. The preparation that pays off: before you start configuring anything, assess your ten largest customers on document format, field names, and numeric conventions. That saves a significant amount of rework later.
When does automating sales order processing actually pay off?
Automation pays off when volume is high enough and the process is stable enough to describe. A practical rule of thumb: if employees spend more than an hour a day re-keying or checking incoming orders, there is room for automation. If volume is lower, or if every order requires the employee to think carefully about what the customer actually means, automating the reading layer adds less value. Also relevant: how often re-keying causes errors, and what those errors cost. A wrong article number or a missed order line that only surfaces at delivery costs more than the time spent on manual entry in the first place. For companies with high order volumes and a mix of customers delivering in varying formats, that is the pain-point list that justifies automation.
What the human continues to do
A well-configured sales order processing system takes over the reading and re-keying work. What remains: the employee approves. That sounds like a limitation, but it is a deliberate choice. Deviations are flagged so they are visible. An order where the requested item does not match a known reference, a price that differs from the agreed price, a delivery address that is new: these are signals that require a human decision, not an algorithm. Recognising this leads to a process where automation removes the routine work and employees focus on the cases that warrant attention. That is more realistic than fully hands-free order processing, and it works better in practice too.