What this covers
- Order entry errors are expensive in a way quoting errors are not: they ship, they invoice, and they get corrected by a person days later.
- Price and quantity tolerances are the central design decision, and they should be explicit numbers the business agreed to.
- A partial post is usually better than an all-or-nothing hold: lines that clear should proceed while one line waits.
- Acknowledging the order back to the customer quickly is often worth as much as the keying time saved.
Order entry has a quality that makes it unusually suited to automation and unusually unforgiving. Every step is mechanical, so there is nothing an agent cannot in principle do. And every mistake propagates: a wrong quantity ships, a wrong price invoices, and the correction happens three days later in a phone call nobody enjoys.
Which means the interesting question is not whether an agent can read a purchase order. It is what the agent does when the purchase order disagrees with your system, because that is the case that actually consumes your team.
The work, honestly described
- 01Receive
Take the order from the shared mailbox, the portal export or the attachment it arrived as. A PDF, a scan, a spreadsheet, or a body of text with the lines typed into the email.
- 02Extract the lines
Pull the header and every line: item, quantity, unit, price, requested date, delivery address, references. Including tables that break across pages and notes that qualify a line.
- 03Verify the customer
Resolve the sender to the account, then check credit status, holds, payment terms and whether the ship-to address is one on file.
- 04Validate the lines
Match each item to the catalog, convert units, and compare the price on the order against what the account is entitled to pay. This is where tolerance rules apply.
- 05Check fulfillment
Confirm the quantities can be supplied against the requested dates, and identify lines that cannot.
- 06Create the transaction
Write the sales order into the system with the correct account, pricing, dates and whatever mandatory attributes your order entry requires, and attach the source document.
- 07Confirm
Acknowledge to the customer what was accepted, at what price and for what date, and state anything that was not.
Tolerances are the whole design
Here is the case that makes or breaks the deployment. The customer's purchase order says $98.40 for a line. Your contract pricing for that account says $100.80. A 2.4% difference. What should happen?
There are three defensible answers and they belong to the business, not the software. Accept the order at your price and state the difference on the acknowledgment. Accept at their price because it is within a tolerance you are willing to absorb. Or stop the line and have a person decide. What is not defensible is silently picking one, which is what an automation without an explicit tolerance rule does.
Once those numbers exist, the behavior is predictable. Lines inside tolerance post. Lines outside it stop with both figures shown and the difference stated. Nothing is silently accepted, and nothing is silently rejected either. Where the agent stops covers how to place those thresholds and when to move them.
Partial posting beats all-or-nothing
A ten-line order with one problem line is the common case, not the edge case. An automation that holds the whole order until someone resolves line seven has converted a five-minute keying task into a queue entry, which is not an improvement.
The better behavior is to post what cleared and hold what did not, as a line-level exception on an otherwise created order. The customer's nine lines are in the system and moving. Line seven is a specific question with both prices on screen. The person's decision takes seconds rather than requiring them to key ten lines.
An exception should stop a line, not a transaction. Most of the time saved by order automation is saved by that one design choice.
There are workflows where this is wrong and the order has to be atomic, typically where downstream allocation or a customer's own system requires it. That is a decision to make deliberately per deployment rather than a default to inherit.
What the customer experiences
There is a second benefit that rarely appears in the business case and often matters more to the sales team than the keying hours.
Today, a purchase order sent at 16:30 is typically acknowledged the following morning, or later. The customer does not know whether the quantities were accepted, whether the dates hold, or whether the price matched, until someone gets to it. That uncertainty generates its own traffic: chase emails, phone calls, and a second copy of the order sent in case the first was missed.
An order acknowledged within minutes, stating exactly what was accepted and flagging the one line that needs discussion, removes that traffic. It is also a visible difference in service quality, which is unusual for a back-office automation.
What to look at before starting
- 01Take fifty orders from the last month. What share arrived as a structured file, a PDF, a scan, or typed into an email body?
- 02Of those, how many had at least one line that disagreed with your system on price, quantity or date?
- 03What does your team currently do in that case, and is the answer the same for everyone?
- 04What are the mandatory fields on a sales order line in your system, and where does each one come from when a customer did not supply it?
- 05How long, on average, between the order arriving and the acknowledgment going out?
Question three is the revealing one. In most operations the answer differs by person, which means the rule exists but is unwritten. Writing it down is half the deployment, and it is the half that a Workflow Review is designed to produce.
The Order Agent sets out what is built before a project starts and what has to be configured against your order entry requirements.