It happens on both sides of the business. A customer sends a purchase order and somebody keys a sales order; a requisition or a supplier confirmation lands and somebody keys a purchase order. The agent watches the mailbox, reads the document — body text or PDF — checks it against your master data, raises the right document in SAP, and replies with an acknowledgement in the same thread. Minutes, not tomorrow morning.
The dashboard is behind a login, because it shows live customer orders. Ask us for credentials.
Please supply against the attached PO. Delivery to our Jamshedpur yard, same terms as last month.
📎 PO-4500198231.pdf · 2 pagesOrder acknowledgement, three lines priced, requested delivery confirmed, with the ship-to ambiguity called out so your customer corrects it before dispatch — not after.
Every PO that arrives by email gets read by a person, keyed into the system by a person, and acknowledged by a person — if there is time before they go home.
Customer service spends its morning transcribing PDFs. The job needs judgment maybe five percent of the time, and it is paid for the other ninety-five.
The customer waits, then chases. The chase is another email your team answers by hand.
A blocked customer, a quantity below the minimum lot, an order that pushes past the credit limit. All catchable, all missed on a busy morning.
The work is identical in shape and the failure modes are identical too. What changes is which master data the lines get matched against, and which document comes out at the end.
The customer emails a purchase order in their own format. Lines are matched to customer, material, ship-to, minimum lot, price and credit limit, and the sales order is raised. The acknowledgement goes back in the same thread, with the order number on it.
An approved requisition or a supplier confirmation lands in the mailbox. Lines are matched to approved supplier, material, price agreement and delivery terms, and the purchase order is raised. The supplier gets the confirmation in thread.
A line that does not match cleanly is never posted. It is held, an internal escalation is raised with the reason, and the sender gets a holding note instead of a wrong number. A guessed order costs more than the typing it saved.
One inbound email runs the same path every time, and the run log records what happened at each stage — including the stages it deliberately skipped.
Reads new mail from the order mailbox and holds its position across restarts.
Allowlisted senders only, auto-replies rejected, and a ledger that makes double-replies impossible.
Reads the order out of prose and PDF attachments into a schema-validated intent.
Order, or not an order. Anything that isn't gets logged and left alone, never answered.
Party, blocks, ship-to, materials, minimum quantities, pricing, credit limit on the sell side and approved supplier and price agreement on the buy side. All deterministic.
Raises the sales order or the purchase order and the payload your system expects. Skipped entirely if a check failed.
Replies in the original thread — acknowledgement, or a holding note plus an internal escalation.
The interesting part of an order agent is not the happy path. It is what happens when the customer's PO is missing a material code, the quantity is under the minimum lot, or the order would break the credit limit. Every check is plain code with a recorded result — no model gets a vote on whether your rules apply. The six cases that prove it are in the acceptance pack below.
No sales order is created. The customer gets a holding reply that names what is missing, and your team gets the escalation.
A durable ledger claims each message before work starts, so a restart mid-flight cannot produce a second acknowledgement.
Every run keeps the extracted intent, each check result, the payload, and the reply. Reconstructing "why did this order go through" takes seconds.
Six cases decide whether an order agent is safe to connect. Run them against a copy of your mailbox and your master data, and read the run log rather than the reply. An agent that books the valid order is easy. What matters is the five it must refuse.
| Case | Synthetic input | Expected decision | ERP write | Reply sent | Person involved |
|---|---|---|---|---|---|
| 01 — Clean order | Allowlisted buyer, PDF PO, two lines, both materials known, quantities above minimum lot, inside credit limit. | All validations pass; the order is raised. | CREATE | Acknowledgement in thread, carrying the order number. | No |
| 02 — Unknown party or material | Same PO, but the ship-to is not in master data and one line has a free-text description with no material code. | Validation fails on party and material; generation is skipped. | NONE | Holding reply naming what is missing. No number is invented. | Yes — escalation to the order desk |
| 03 — Duplicate and retry | The case 01 email is delivered twice, and the agent is restarted mid-run on the second copy. | The ledger claims the message once; the replay is recognised and stopped before generation. | NONE on the second | One reply in total, not two. | No |
| 04 — Unreadable attachment | A scanned PO whose line table is half-legible, with a quantity in the body that contradicts the quantity in the PDF. | Extraction fails the schema, or the conflict is detected; nothing is guessed. | NONE | Holding reply asking for the order in a readable form. | Yes — escalation with both readings attached |
| 05 — ERP failure | A valid order where the ERP call times out, and a second where it returns an error after the write may have landed. | No success is assumed from a missing response. The run is held for reconciliation. | UNCERTAIN — not retried blind | No confirmation. The customer is not told an order exists. | Yes — the desk reconciles before any resend |
| 06 — Approval boundary | A valid order whose value sits above the threshold your rules reserve for human approval. | Every check passes, and the order still stops at the boundary. | HELD until approved | Acknowledgement of receipt only, with no commitment. | Yes — named approver, recorded in the run log |
For every case the run log keeps the same record: what arrived, what was extracted, each check and its result, the payload that was or was not sent, the reply, and who was pulled in. That record is the evidence. A screenshot of a correct acknowledgement proves nothing about case 05.
Acceptance pack — AI order agent, before ERP write access [ ] 01 Clean order valid PO is booked, acknowledgement carries the real order number [ ] 02 Unknown party unmatched customer or material is held, never guessed [ ] 03 Duplicate + retry the same email twice produces exactly one reply and one order [ ] 04 Unreadable input conflicting or illegible quantities fail loudly, nothing is posted [ ] 05 ERP failure a timeout or error never becomes a success confirmation [ ] 06 Approval boundary an order above your threshold waits for a named approver For each case, record and keep: input the message and attachment exactly as received decision which check passed, which failed, and on what rule action the payload sent to the ERP, or the fact that none was result what the ERP returned, including nothing at all person who was escalated to, and what they did Before granting write access, confirm: [ ] the sender allowlist is enforced, not advisory [ ] validations are deterministic code, not a model's judgement [ ] the run log is queryable by message, not only by day [ ] failure is the default when a check cannot be completed [ ] simulated, sandbox and production results are labelled separately
The same six cases apply to any custom AI agent that writes into a system of record — the nouns change, the refusals do not. If you want this run against your own orders, send us five of them.
The reading, the master-data checks and the refusal rules are the same whichever ERP sits behind the mailbox. Only the last step changes: where the order gets written. We have built that step for SAP, Oracle and Microsoft Dynamics. Another ERP gets the same agent, connected through its own API as part of the project.
Customer POs become sales orders and approved requisitions become purchase orders, checked against customer, material, ship-to, price and credit before anything is posted.
The same mailbox, the same checks, the same reply in thread. The order lands in Oracle instead of SAP, and every decision is written to the same run log.
Sales and purchase orders raised in Dynamics, with the fail-closed rule unchanged: a line that does not match cleanly is held and escalated, never guessed.
Both solve part of the problem. Neither answers the email.
OCR turns a PDF into fields, one template per customer layout. It does not check the order against your master data, and a new layout breaks it until someone builds another template.
EDI works when the customer can send structured messages. Most of the orders that still get retyped come from customers who never will, by email, in their own format.
Reads body text or PDF in any layout, validates every line, raises the order in the ERP and replies in the same thread. What it cannot validate, it refuses and escalates.
See the full comparison: manual entry vs. EDI vs. RPA vs. AI agents →
Every run as it happens: what arrived, what was extracted, which checks passed, what was sent. Password-protected, and it fails closed if the password is missing.
Scanned or generated, table or paragraph. The extraction is schema-validated, so a half-read PO fails loudly instead of booking half an order.
Only mail from customers you approved is processed. Newsletters, bounces and auto-replies are turned away at the guard.
Customers, materials, minimum lots, price lists, credit limits. The engine is deterministic and unit-tested against your rule set.
Pilots run against a simulated backend so nothing touches production. The payloads are built to the interface your ERP already exposes, so switching over is a config change, not a rewrite.
A PO that lands at 23:40 is acknowledged at 23:44. Your team reads the summary in the morning instead of the backlog.
Cost follows order volume and how many rule sets and plants sit behind it. We size it with you before anything is signed, and a pilot runs on one mailbox with a small allowlist.
A voice agent takes the order status and spare parts calls, and a copilot answers questions on your SAP data. See the full SAP agent line-up for manufacturers →
A pilot runs on a copy of your mailbox with your master data and your rules. You see what it books, what it holds, and what it escalates — before it ever touches a customer.