Entering sales orders from emailed purchase orders with AI

How the bot works

Eight steps. Six of them are ordinary code and cost almost nothing to run; the model is only asked the questions that actually need judgment.

1. It picks up the order. A mailbox your customers already send to, a shared inbox, an EDI drop, or a folder on SFTP — whichever route they already use. Customers don't have to change how they order, which is the whole point.

2. It reads the document, whatever shape it is. A clean PDF, a photo of a fax, a spreadsheet with the columns in a new order this month, or three lines typed into the email body. Out of it come the header fields and every line, each with a confidence value and a pointer back to where on the page it came from.

3. It identifies the customer and the ship-to. Account, contact, bill-to and ship-to, matched against your customer record rather than trusted from the letterhead. A PO number already used by a different customer is reported as a question, not silently treated as a duplicate.

4. It matches every line to your catalog. This is the part that actually decides whether the thing works. Their free-text description, their own part number, a number from a competitor's catalog, or a phrase they have used for nine years — matched against your SKUs and the aliases you have taught it, with a confidence and the reason. An alias it has been taught is a match. Anything else is an exception, not a best guess.

5. It checks price, quantity and terms. Against that customer's contract, price list, tier, minimums and unit of measure — not against list. A price in your favor is still a discrepancy: it is reported, not pocketed, because the alternative is a credit note and an awkward call later.

6. It runs the checks the order desk does from memory. The same PO number already entered. A unit-of-measure mismatch, where they wrote “each” and you sell it by the box of ten. A quantity below their line minimum. A discontinued part with a successor. An account on credit hold. A requested date already in the past on a resent PO. These are deterministic checks: no model judgment, no false confidence.

7. It drafts the order and decides who sees it. A clean order is drafted and queued for release. Anything held goes to the order desk with the question already asked — which of two valves, whose price is right, is this the same PO as Tuesday's — and the evidence attached. Nobody has to re-read the PDF to find out why.

8. It writes the audit row. One record per order: what arrived and from where, what it read, what it matched and how confidently, which lines were held and under which rule, the price variances, the model and prompt version, who released it, and the timestamps.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your catalog

Your SKUs, and every alias a customer has ever used for them — their part numbers, their descriptions, the phrases your desk already translates in its head. Taught once, then reused.

Your price lists

Contract pricing, tiers, customer-specific rates, promotional dates and what to do when the PO disagrees with any of them.

Your units and minimums

How each item is sold, the conversions between their unit and yours, line and order minimums, and pack rounding.

Your tolerances

How close a price has to be to pass, how far a date can slip, and the confidence below which a line is always held.

Your exception rules

Which conditions hold a line, which hold the whole order, which go back to the customer, and who sees each one.

Auto-release

Off by default. On per customer, per product group, under an order value you choose — entirely your call, and reversible with one flag.

Your channels

Where the exception lands: email, Slack, Microsoft Teams, or a queue inside the system your desk already works in.

Your systems

Which system is the system of record, and whether we write a draft order by API, into a staging queue, or as a file your ERP already imports.

The words it uses

The tone and length of the question back to the customer, and the versioned prompts behind it — yours to read, yours to tune.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every line says what it matched, how confident it was and which rule held it — never a bare “needs review”. The held line carries the page of the PO it came from and the price list it was checked against, so the desk can agree or disagree with the reasoning instead of starting again.

Versioned prompts you can tune yourself

The prompts behind the matching are yours to read and yours to tune. A change is a reviewable diff, replayed against orders you have already entered so you can see what it would have done differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Automation handles the lines that match cleanly against a taught alias. An ambiguous part, a price variance, a credit hold or anything over your value ceiling goes to the order desk, never through it. That boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per order: what arrived, what it read, what it matched, what was held and under which rule, who released it and when — plus token usage and cost for that order.

It can be configured to run in any business. The catalog and the rules are yours: your SKUs and aliases, your price lists, your tolerances, your system of record. The order-desk wiring on this page is one configuration of it, not the limit of it.

Works with your tools

This runs on top of the stack you already pay for. We're not replacing your ERP.

• NetSuite
• Microsoft Dynamics 365
• SAP Business One
• Sage
• Epicor
• QuickBooks Online or Desktop
• Acumatica
• A shared orders mailbox or SFTP drop
• EDI 850 alongside email
• Email, Slack or Microsoft Teams

Works well for

• Wholesale distributors — Customers email POs using their own part numbers, and every line has to find your catalog before it ships.
• Food and beverage distributors — Standing orders arrive by email all morning, and the desk is the bottleneck before the trucks load.
• Building materials suppliers — Contractors send takeoffs and POs as scans, and the same item is named differently on every one.
• Manufacturers — A PO lands as a PDF with revisions, and the quantity, unit of measure and ship date all have to be checked.

How a rollout works

Nothing goes live on day one. Shadow mode comes first, and it is where your own numbers come from.

1. 01Discovery

   The quote call, then a working session. We read a few months of real POs, the orders your desk entered from them, your catalog and alias list, your price lists, and what access your ERP allows. You get the matching design, the exception classes and a written scope.

2. 02Shadow mode

   The bot runs over historic POs only. Nothing is drafted into your ERP. Nothing is released. Nobody's day changes. It produces a proposed order per PO and we compare it, line by line, against what your desk actually entered. Every disagreement is either an alias to teach or a rule to fix — and this is where your own accuracy numbers come from, on your own orders.

3. 03Assisted mode

   Live POs. The bot reads, matches and drafts; your desk reviews and releases every order. The queue gets faster to work. The control doesn't change.

4. 04Limited auto-release

   Optional. Named customers and product groups only, under an order value you choose, with a sampled human review, every hard stop in force, and the kill switch. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No percentage of orders automated, no accuracy figure, no minutes-per-order saved. We haven't run this on your POs. Shadow mode is where those numbers come from, and they'll be yours.
• No customer claims on this page. No names, no case studies, no logos.
• Catalog matching is the hard part, and we won't pretend otherwise. A customer's nine-year-old phrase for a part is learned, not inferred. Early on it will ask more often than it will later, and the aliases it learns are yours to keep.
• It doesn't replace your ERP or your order desk. It works on top of them, and it is designed to make the desk's queue shorter rather than to make the desk unnecessary.
• Fully autonomous order entry isn't on offer. The design assumes a person owns the release. That's deliberate, and it's why the boundary is written down.

Questions people ask

Can AI enter sales orders from emailed purchase orders?

Yes - and the honest version is that it reads, matches and drafts, and a person releases. An AI agent can take a PO in whatever shape it arrives, pull out the header and every line, identify the customer and the ship-to, match each line against your catalog, check price and quantity against that customer's contract, and draft the sales order. What it will not do is release an order it had to guess at. A line it cannot match to exactly one SKU goes to the order desk with both candidates named.

Will it put orders into our ERP without anyone looking?

Not unless you explicitly turn that on, and not for anything that tripped a hard stop. We build it draft-only: the bot writes a draft and a person releases it. If you later switch on limited auto-release, it is for named customers and product groups, under an order value you choose, with a sampled human review and every hard stop still in force. An unmatched line, a price variance, a credit hold, a new ship-to or a low-confidence read can never be auto-released in any configuration.

How does it match a customer's part description to our SKU?

By your catalog and the aliases you teach it, not by guessing. It compares their free-text description, their own part number and any competitor number against your SKUs, attributes and the alias list, and returns a confidence with the reason it matched. An alias you have confirmed is a match. A description that fits two SKUs is an exception, and it names both rather than picking one - shipping the wrong part costs far more than asking. Every answer your desk gives is saved as an alias, so the same phrase from the same customer does not ask twice.

What happens when the PO is a photo of a fax, or handwritten?

It is read if it can be read, and escalated if it cannot. Every extracted field carries a confidence and a pointer back to where on the page it came from, so a low-confidence quantity on a smudged line is reported as exactly that rather than entered. A document the bot cannot read at all goes to the desk as it arrived, with the fields it did manage to get. A blurry PO is an escalation, not a guess.

Can it catch a duplicate PO we already entered?

Yes, and that is one of the cheapest, most reliable parts. Duplicate detection runs across every order from that customer, not just the one in front of it, so the resent PO that arrives three days later under a slightly different number is caught on customer, PO number, date proximity, line content and total. The same PO number arriving from a different customer is treated as a question rather than a duplicate, because that is usually two buyers using the same numbering. Both are deterministic checks: no model judgment, no false confidence.

Does it work with NetSuite, Dynamics, QuickBooks or our own ERP?

Yes - by API, by a staging queue, or by producing the import file your ERP already takes, alongside SAP Business One, Sage, Epicor and Acumatica. If your system of record is not one of those, the question is only whether it offers an API, an import or a staging table; most do, and a read-only export is all shadow mode needs. Naming a system means we can read or write it, not that we are partnered with it.

What happens if the price on the PO doesn't match our price list?

The line is held and the variance is reported, in both directions. If they have put a price lower than their contract, that is raised. If they have put a price higher than their contract, that is raised too - a price in your favor is still a discrepancy, and quietly accepting it buys a credit note and an awkward call later. Your tolerance decides how close counts as agreeing, and who sees the ones that don't.

Is there an audit trail for every order it touches?

Yes, and it is designed for the person who has to work out why a customer got the wrong thing. One immutable row per order records the source message and attachment, every header field read with its confidence, every line with the SKU it matched and the alias or rule that matched it, every hold with its reason, the price variances, the model and prompt version that produced the result, the person who released it and UTC timestamps. The intent is that someone who was not there can reconstruct any single order from that one row.

How long does it take to get running?

The first milestone is shadow mode, and it needs three things: a few months of real POs as they arrived, the orders your desk entered from them, and read access or a scheduled export from your ERP for the catalog and price lists. We will not quote you a timeline before we know which systems are involved and what access they allow - you get a real one in your quote, once Ozzie's call has gathered the details.