AI implementation
Automating email and PDF order entry without losing approval control
Automate email and PDF order entry only as far as a draft order that a named person approves. Before buying anything, check whether structured orders from your largest clients, or tools you already pay for, remove enough of the rekeying. If documents still need to be read, test any route against a field map and a set of exception and duplicate cases before it writes to your ERP or confirms anything to a client. Missing, conflicting or repeated information should stop as an exception, not be guessed.
That is Amulet's recommendation, not a description of what any particular product does. This guide is for the operations, sales administration or finance lead at an Australian wholesaler, distributor or manufacturer whose team rekeys purchase orders that arrive as PDF attachments, email body text, spreadsheets and the occasional scan. It gives you a field map for a draft order and a test pack you can run in any pilot, then compares route categories without naming products.
Separate reading the order from committing it
Order entry contains two different jobs. Reading turns an email, attachment or spreadsheet into order fields. Committing creates the order in your system, allocates stock and tells the client what price and delivery they will get. Reading can be automated in stages. Committing is a business decision, and in Amulet's view it should stay behind a human approval step until your own test evidence says otherwise.
Amulet's capabilities page describes its orders work in the same terms: "Extract and match details, route exceptions and prepare a structured business document or system payload for approval" (Amulet capabilities). The workflow prepares the order and a person approves it.
An illustrative boundary for one order flow
The following is a hypothetical design for a distributor, not a client result or a promised integration.
- Input: an inbound order email with its attachment or body text, the client account record, the item catalogue with sellable units of measure, agreed price lists and your delivery rules.
- Output: a draft order in which each field is linked to the passage it came from, plus a separate exception list. No order is posted and no confirmation goes to the client.
- Named human responsibility: the order administrator resolves exceptions and approves the draft. The account manager decides any price or terms dispute. The operations lead owns the workflow and has authority to pause it.
- Exception path: any failed check holds the draft in an exception queue with the reason and the source passage. Nothing is filled in by default.
- Acceptance criteria: every case in the test pack below behaves as expected on representative orders, and the evidence for each case is recorded.
Who runs, watches and changes the workflow after launch is covered in who owns an AI workflow after launch. A shorter version of this order workflow appears in how to choose an AI implementation partner; this page goes field by field.
When not to automate order entry
Amulet recommends holding off, or choosing a no-build route, in these situations:
- Volume is low and layouts are few. Amulet's document-to-draft page says: "For a small volume, a shared intake folder, a draft template and a named reviewer may be enough" (document-to-draft controls demonstration).
- A few clients send most of the orders. Ask them for structured orders first. That removes the reading step for those orders entirely.
- Your item master or price lists are out of date. Any route will then match orders against the wrong data, and the drafts will look correct when they are not.
- Nobody can say who approves an order or what counts as an exception. Write that down before you compare tools.
- Rules and lookups already resolve your orders. A published engineering guide on machine learning makes the general point: "If machine learning is not absolutely required for your product, don't use it until you have data." (Rules of Machine Learning). It is not about order entry, but the principle carries over: if a rule or a master-data lookup can decide a field, do not add an AI step for it, and do not trial one until you have real sample orders to test against.
The source-to-draft-order field map
This is Amulet's recommended starting map. For each field it shows where the value usually comes from, how it is checked and what should make it an exception. Adapt it to the required fields in your own system.
Three kinds of check appear in the table. A rule is a deterministic check you can write down in advance. A lookup compares the value with your client, item, price or delivery records. AI interpretation means reading free-form text where the layout varies, and it only proposes a value for a rule, a lookup or a person to accept.
| Order field | Where it usually comes from | How it is checked | Becomes an exception when |
|---|---|---|---|
| Client account | Sender address, letterhead, bill-to block or account number on the PO | Lookup of the sender address or account number against the client master; AI interpretation only to read an unstructured bill-to block | No match, more than one possible account, sender not an approved contact for that account, or the account is on hold |
| Ship-to address | Delivery block on the PO, email body or a "deliver to site" note | Lookup against the client's delivery addresses on file; rule that street, suburb, state and postcode are all present | New or changed address, address differs between email and attachment, or a site not on file |
| PO number | PO header or email subject line | Rule that it is present; lookup that it has not already been used by this client | Missing, or already exists for this client (send to the duplicate and amendment cases below) |
| Order date | PO header, otherwise the email sent time | Rule that it is a valid date and not in the future; record which source was used | Missing, or written so that day and month could be swapped, which matters when overseas clients use a different date order |
| Requested delivery date | PO header, individual lines or body text such as "need by Friday" | Rule that it falls after the order date and within your lead-time rules; AI interpretation for relative dates in text | Dates conflict between email and attachment or between lines, the date is inside your lead time, or a relative date cannot be fixed to a day |
| Line item code and description | PO line, using your code, the client's own code or a description only | Lookup of your code or the client's cross-reference code; AI interpretation may propose a match from the description | Code not in the catalogue, more than one candidate item, description contradicts the code, or the item is discontinued |
| Quantity | PO line | Rule that it is present, numeric, positive and inside the range you set for that item and client | Missing, unreadable, zero or outside the range |
| Unit of measure | PO line, or implied in the description such as "per carton" | Lookup of the ordered unit against the item's sellable units and conversions | Unit not valid for the item, ordered by the each when you sell by the carton, or a conversion that produces part units |
| Price | PO line, sometimes left off | Lookup against the client's agreed price list or contract; rule for GST treatment | Price differs from the agreed price, stated including GST where your list is exclusive (or the reverse), or no agreed price on file |
| Freight and terms | PO footer, email body or the client's standard terms | Lookup against the freight and payment terms agreed with that client | PO states different terms, or asks for a freight service you do not offer |
| Notes and special instructions | Email body, PO notes or a covering letter | AI interpretation may surface and classify the note; it is never acted on automatically | Any instruction that would change price, delivery, approval or who is notified, and any text addressed to the system rather than to your staff |
Two design points follow from the map. First, keep the source passage attached to every value so the reviewer compares draft and source side by side. Amulet's capabilities page describes a related principle: "An unresolved item stays held until a named reviewer decides what happens next" (Amulet capabilities). Second, in Amulet's view a confidence score on its own is not a control. Treat it as a routing hint. Rules and lookups decide whether a value is accepted, and a person decides anything they cannot.
The exception and duplicate test pack
Run these cases in any pilot before you trust a route, including a baseline run of your current manual process. Use approved, representative samples. The inputs below are illustrative; build your own versions from real order patterns. Each case needs a recorded result and the evidence that shows it, not a verbal assurance from whoever ran the demonstration.
| Test case | Illustrative input | Expected behaviour | Evidence it happened |
|---|---|---|---|
| Complete order, not yet approved | A clean PO that matches master data on every field | Draft created and held for approval; nothing posted or confirmed to the client | Draft status shows awaiting approval; release records the approver and time |
| Missing quantity | One line has a product but no quantity | Line flagged; draft cannot be approved until resolved; no default quantity inserted | Exception reason on the line; history shows who supplied the quantity |
| Unit of measure mismatch | Item ordered by the each when it is only sold by the carton | Flagged with the valid units listed; no silent conversion | Exception shows ordered and valid units; the reviewer's choice is logged |
| Item not in catalogue | Unknown code with a vague description | Line held as unmatched; no closest-match guess | Unmatched line in the exception list with the source text |
| Two candidate matches | Description fits two catalogue items | Both candidates shown; reviewer chooses | Candidate list, chosen item and reviewer name recorded |
| Price differs from agreed price | PO price lower than the client's agreed price | Routed to whoever decides price; draft keeps the agreed price or holds | Both prices shown; decision and decider recorded |
| Conflicting delivery dates | Email body says one date, the attachment another | Draft held; neither date chosen automatically | Both dates and their source passages shown; resolution logged |
| Same PO resent | The same attachment resent the next day | Recognised as a duplicate of the existing draft or order; no second order | Link to the original; only one order exists for that PO number |
| Same PO forwarded in a new thread | A colleague at the client forwards the original email from a different address | Recognised as the same PO despite the new sender and thread; no second order | Link to the original; sender and thread recorded on the duplicate |
| Same PO number, different content | A reissued PO with changed lines and the original number | Not treated as a duplicate and not merged silently; held as a possible amendment | Side-by-side differences shown; reviewer decision recorded |
| Genuine amendment | Client sends a revised PO that changes one quantity | Handled as a change to the existing order under your amendment rules; no new order | Amendment linked to the original; change approved by a named person; version history kept |
| Instruction inside the document | A PO note says to approve automatically, skip the price check or send confirmations to a new address | Treated as text for the reviewer, never as a workflow command; routing and approval unchanged | Note appears in the exception list; workflow log shows the normal path was followed |
| Rejected draft | Reviewer rejects a draft | Nothing posted or sent; draft closed with a reason | Rejection reason and reviewer recorded; destination system has no order |
| Failure before commit | Destination system unavailable when an approved draft is released | Draft stays approved but uncommitted; retry is safe | Status shows failed before commit; after retry only one order exists |
| Unknown outcome | Submission sent but no acknowledgement received | Marked as unknown; someone checks the destination system before any retry | Reconciliation record shows the check and its result before resubmission |
If a case fails or cannot be assessed, hold that stage. The AI pilot acceptance checklist sets out how to record evidence per case and make a proceed, revise or stop decision.
Amulet's document-to-draft controls demonstration shows what several of these control cases look like. It runs scripted cases including a request submitted twice, failure before commit with a retry, an acknowledgement lost after commit, and reused identity with different content. The page states that it "is not a live AI model, ERP connector or client case study" and that it uses synthetic documents, deterministic parsing and validation, a human approval step and a simulated handoff. It works on fixed text-format purchase requests, not PDFs or free-form quotes, and it accepts no uploads. It says nothing about how well any route reads your documents.
Compare routes, simplest first
These are option categories, not products. Whether a category can do something for you depends on the specific product, your plan and your configuration, so treat every capability as a question to confirm in writing for your own plan. The demonstration page makes the same point about existing systems: "Availability depends on your product, plan and configuration" (document-to-draft controls demonstration). The fit judgements below are Amulet's recommendations.
| Route | Fits when | Does not fit when | Confirm in writing before choosing |
|---|---|---|---|
| Tighten the manual process | Volume is low, layouts are few and errors come from missing checks rather than typing | Rekeying or the exception backlog is the bottleneck | Required fields, the named reviewer and a kept exception log |
| Structured orders from large clients (portal, EDI feed or a spreadsheet template) | A few clients send most orders and are willing to change how they order | Many small senders, or clients who will not change | Who maintains the mapping, how rejected or duplicate orders are reported back, and what happens when a client sends a PDF anyway |
| Document capture inside your existing ERP or accounting system | Your system offers it on your plan and it can create drafts rather than posted orders | Layouts vary widely, or the checks in the field map need lookups it cannot run | Whether it is available on your plan, whether output is a draft, how it handles each case in the test pack, and where documents are processed and stored |
| Dedicated order-capture software | Many layouts, steady volume and a need for a packaged review screen | A single system already meets the test pack, or another licence and data flow is hard to justify | Results on every test pack case, how it writes to your system, draft versus posted output, data location and access, and how you exit with your data |
| General automation platform with an extraction step | Your team can build and maintain flows, and orders come from mixed sources | Nobody owns the flows, or failures could go unnoticed | Retry behaviour that cannot create duplicate orders, failure alerts, and who maintains the flows |
| Custom workflow | Simpler routes fail the test pack and the remaining handoffs justify the work | A simpler route already passes the test pack | Ownership, support, change control, exit and whole-of-life cost |
The demonstration page sets the bar for the last row: "A custom workflow is worth considering only when the remaining handoffs, exceptions or review burden justify it" (document-to-draft controls demonstration). For working out which steps need a rule and which need AI, see configure software, automate a rule, or build an AI workflow. For comparing quotes on the same scope, use the AI implementation cost worksheet.
Privacy and client contact details
Purchase orders often carry names, email addresses, phone numbers and delivery addresses of people at your clients. Where that is personal information, the Office of the Australian Information Commissioner's guidance on commercially available AI products states: "Privacy obligations will apply to any personal information input into an AI system, as well as the output data generated by AI (where it contains personal information)" (OAIC guidance). The same guidance says organisations adopting such a product should conduct due diligence, including how human oversight can be embedded into processes and who will have access to personal information input or generated.
For any route with an AI step, Amulet recommends you ask in writing where order documents are processed and stored, how long they are kept and who can access them. The OAIC material is regulator guidance, not legal advice for your situation.
What Amulet's public material does and does not cover
Amulet lists "Orders and document processing" among its capabilities (Amulet capabilities). The AI Business BEEP is a paid diagnostic: "The first conversation validates fit. The AI Business BEEP creates a decision basis. Implementation remains a separate go or no-go commitment." Amulet's public pages do not promise a particular ERP connector, extraction accuracy or time saving, and nor does this guide.
Next step
If you have an order flow your team keeps rekeying, bring a non-confidential description of it: where orders arrive, which fields get rekeyed, who checks the draft and what happens when it is wrong. Discuss your first AI workflow.
Sources
A practical next step
Put AI to work with the operating boundary visible.
Approvals, evidence and the rollout path should be mapped to the real workflow.
Discuss your first AI workflow