Sales order automation that keeps a person on the approve button
Sales order automation creates the sales order in your ERP from what the customer sent, so nobody retypes it. The hard part is not reading the PO. It is turning the customer's words into your customer account, your part numbers and your prices, then letting a person approve the result.
What a sales order needs that a PO does not give you
A customer PO is written in the customer's terms. A sales order has to be written in yours. Every field below is a small translation job, and each one is where manual keying spends its time.
| Sales order field | Where it comes from |
|---|---|
| Customer account | The company name on the PO, the sender's email domain, or the ship-to address, matched to an account in your ERP. Large customers often have several accounts by site. |
| Your item code | Mapped from the customer's part number using their past orders and a part-number table. The description is a fallback, never the only evidence. |
| Price | Your price levels or contract pricing for that account. The PO price is compared with it, not copied into the order. |
| Unit of measure | Converted where the customer orders in boxes and you sell in each, or the other way round. |
| Delivery address | Matched to the customer's saved addresses, so a new site is noticed instead of keyed as a typo. |
| Customer reference | The PO number, carried into the order so invoices quote it and the customer's accounts team can match them. |
Matching customer part numbers to your SKUs
Every buyer has their own codes. A mine's stores system calls an item one thing, a builder calls it another, and neither matches your product list. People on the order desk carry this mapping in their heads, which is why a new starter is slow and why a holiday leaves gaps.
The agent builds the mapping from evidence you already have. Your past sales orders, keyed from the same customers' POs, show which of your items each of their codes became. A part-number table holds the links explicitly. When a customer code is new, or matches more than one of your items, the line is flagged rather than guessed.
When a person picks the right item, the table records it. The next order from that customer with the same code comes through matched. Over a few weeks, the share of lines that need a look drops as the table fills in.
Price and stock checks before the draft
Before a draft is written, each line is priced from your ERP for that customer's account. If the price on the PO differs, the line is flagged with both figures. It is never silently changed. Sometimes the PO is out of date, sometimes your price list is, and sometimes there is a quoted price nobody entered. A person knows which; the agent does not pretend to.
Stock is checked the same way. Where the quantity on hand will not cover the line, the draft shows the shortfall so the person approving can decide whether to split, backorder or substitute. Allocation and credit holds stay with your ERP's own rules.
The approval step
Every draft lands in a review screen with the original PO beside it. Lines the agent is sure of are plain. Lines it is unsure of are highlighted, with the reason written next to them: a new part number, a price that disagrees, a quantity it had to read from a smudged scan.
A clean order takes one click to approve. A flagged one takes a fix and a click. Either way, a person decides, and the order is only real in the ERP after that.
Later, once you have seen months of results, you can choose to let orders from named customers go straight through when nothing on them is flagged. That is your decision, made on your own numbers, and it is off by default.
Confirming the order to the customer
Many buyers want an acknowledgement before they will expect delivery. After approval, the agent can send one from your orders address with your sales order number, the lines as accepted and any backordered items. It goes out only after a person approves the order, and only if you switch it on.
For the reading step on its own, try the PO reader. For the full flow from inbox to approval, see AI order processing. To compare this with webstores, EDI and OCR, see order entry automation. ERP specifics: MYOB order entry and Unleashed order entry.
Sales order automation questions
How is sales order automation different from order entry automation?
Order entry automation is the wider goal: orders reach the ERP without retyping, by any route. Sales order automation is the step that builds the sales order record itself: the right customer account, your item codes, your prices and units, and the delivery address, ready for a person to approve.
How are customer part numbers matched to ours?
From two sources: the sales orders your team already keyed from that customer's past POs, and a part-number table that links their codes to your SKUs. When a code is new, the line is flagged. Once someone picks the right item, the table records it for next time.
What if the PO price is different from our price list?
The line is flagged and both prices are shown. The agent never changes a price on its own in either direction. A person decides whether to honour the PO price, correct it, or call the customer.
What happens when stock is short?
The draft shows the shortfall against that line so the person approving can split the line, backorder the balance or offer a substitute, in whatever way your ERP and your customer prefer. The agent does not allocate stock itself.
Can approved orders be confirmed to the customer automatically?
Yes, if you want that. Once a person approves an order, the agent can send the customer an acknowledgement with your sales order number. It is off unless you turn it on, and it never goes out before approval.
See it on your own orders
A free shadow test runs a month of your emailed orders through the agent. Read-only, about a week.