What it produces
A keyed, verified sales order and an acknowledgement that says exactly what you agreed to.
Workflows
Customer PO to Sales Order
the conversion of a customer's purchase order into a sales order after checking its prices, parts, dates, and terms against the quote
The job in one minute
Who owns it
Customer service, with inside sales, credit, planning and the contract owner stepping in on their decisions.
How often
Every day, as POs arrive.
Why it hurts
POs show up in at least four shapes: a PDF attachment, an EDI order that failed mapping, a file behind a customer portal login, or a PO pasted into an email. Every customer has its own part numbers. Prices come from quotes that expired last quarter. Requested dates sit inside your lead time. And the terms are printed on page three.
That last one matters. Under standard contract rules for goods, your acknowledgement can accept the customer's terms even if nobody read them. Send it in a hurry and you may have agreed to a penalty clause nobody priced.
Systems it touches
The agent signs into customer portals through the order desk's existing browser session, works the EDI error queue, and records the order number back on the CRM opportunity. Clean EDI orders stay with your translator. Product →
- ERP
- Outlook order mailbox
- Customer procurement portals (SAP Business Network
- Coupa)
- EDI translator
- CRM
- Excel
- SharePoint or OneDrive
- Teams
12 steps · 3 actions · 8 decisions · 1 human reviews
The workflow, step by step
Action Decision Human review Select a step in the flowchart to jump to it.
Agent
01Collect POs from the order mailbox02Duplicate or change? Same customer and PO number already on an order…03Customer part plus revision must map to exactly one internal item in…04PO price must equal the price list or the quote valid on the PO date05Quantity must meet the item's minimum and order multiple06A requested date earlier than today plus quoted lead time is flagged…08A ship-to address not on the customer record stops before anything is…09The model lists every clause on payment11Key the sales order12Send the acknowledgement by ERP output
Customer service
Inside sales
Planner
Contract owner
-
Action · Portal
Collect POs from the order mailbox, customer portals and the EDI error queue, and read the header and every line: customer part, revision, quantity, price, requested date.
-
Decision · Agent
Duplicate or change? Same customer and PO number already on an order stops. A higher revision goes to change handling, not a new order.
-
Decision · Agent
Customer part plus revision must map to exactly one internal item in the cross-reference table.
-
Decision · Agent
PO price must equal the price list or the quote valid on the PO date. Any difference, up or down, is a price exception.
-
Decision · Agent
Quantity must meet the item's minimum and order multiple.
-
Decision · Agent
A requested date earlier than today plus quoted lead time is flagged "date at risk."
-
Decision · Agent
Open receivables plus open orders plus this order must sit inside the credit limit, with nothing too far past due.
-
Decision · Agent
A ship-to address not on the customer record stops before anything is keyed.
-
Decision · Agent
The model lists every clause on payment, delivery, penalties, warranty and cancellation; a rule compares each with your accepted-terms table.
-
Human review · Planner
Customer service decides price exceptions, the contract owner decides terms, credit decides holds and the planner commits any date inside lead time.
-
Action · Agent
Key the sales order, attach the PO, save, then reopen it and compare every field with the PO. Anything short of an exact match fails the step.
-
Action · ERP
Send the acknowledgement by ERP output, email or EDI, stating each exception in plain words, and log what was sent.
✓ Done
See it done in the Gallery
Rules vs judgment
The agent's ERP login cannot release credit holds, and every change to a cross-reference or price row is versioned so nobody can force a match.
-
Exact rule
- Duplicates, revisions, price, quantity, credit and date math
-
Model reads
- PDFs, email bodies and portal pages; part descriptions with no part number (a table must confirm); term clauses buried on page three
-
Person decides
- Accepting a non-standard term (contract owner); promising a date inside lead time (planner); price differences and credit release
When it stops
- Revised PO. Compared line by line with the original; differences go to review.
- Unknown or ambiguous customer part. Customer service identifies the item; the new table row needs approval.
- Price differs or quote expired. Inside sales confirms, refuses or requotes.
- Date inside lead time. The planner commits or proposes another date.
- Clause outside accepted terms. The agent drafts an objection; the contract owner edits and sends it.
- Same PO resent with a silently changed PDF. Routed to review as a possible hidden change.
What you end up with
- Clean orders keyed and verified without rekeying.
- Acknowledgements on approved templates that never promise more than you agreed.
- For every order: the PO file, the rows it was checked against, the credit figures at the moment of the check, who accepted each clause and a copy of what you sent. When a customer disputes terms a year later, you have the record.
Questions
Will the agent accept a customer's terms and conditions?
No. It finds the clauses, compares them with terms you already accept and stops on everything else. A named person accepts or objects.
How are PO changes handled?
As their own path. The agent lists what moved and routes it, and never overwrites an order already released to production without review.
Should we push customers to EDI instead?
Where they will trade EDI, yes. The agent still works the EDI error queue and the customers who never will.
Can it add new customer part numbers?
It proposes the row with its evidence. A person approves, and the table records who added it.
Explore related ERP and process automation
No prompts. No babysitting. No Integrations.