Skip to main content

​
The job

Purchase orders arrive by email and ticket in every shape a customer feels like sending: a clean PDF from an ERP, a free-text email that says “same as last time plus 200 of the blue ones”, a phone photo of a signed order form. Someone in order entry reads each one, finds the customer in the ERP, matches every line to an article number, works out the shipping, and types it in. It’s high volume, it’s judgment-heavy in exactly the places that are hard to script, and a mistake ships the wrong goods to the wrong company.

​
What you’ll build

  • Orders land as cases in a reconcile table — from upload, a mailbox, or a ticket webhook.
  • The agent reads the document (including photos and scans), matches the buyer against customer master, matches every line against item master, resolves the shipping method, and fills the output fields.
  • Anything it can’t resolve confidently is flagged with its candidates rather than guessed.
  • Clean cases carry a drafted order confirmation, waiting on approval.

​
Ingredients

Master data shape (invent your own column names to match your system):

​
The starter SOP

Create this as SOP.md in your project’s Files. Change the field names to yours; the structure is the part that matters.

​
Walkthrough

1

Create the storage tables

Create customer_master and item_master as Storage tables and load your CSVs. Give every column a name the agent can read — postal_code, not col_7 — and add descriptions where a name isn’t self-explanatory.
2

Create the reconcile table

Create Order Match as a Reconcile table. In Configure:
  • Operating Procedures: Match incoming purchase orders according to the SOP.
  • Output Fields: order_number, order_date, customer_number, customer_match_status, match_candidates, contact_email, delivery_address, requested_date, shipping_agent_code, line_items (array), flags. Describe each one — the agent reads the descriptions.
  • Data Access: grant customer_master and item_master.
  • AI Model: Balanced.
3

Add the SOP

Paste the starter SOP above into SOP.md in the project’s Files, then ask the agent in chat to review it against your actual master data:
Read SOP.md, then look at customer_master and item_master. Does the SOP reference fields that don’t exist, or miss fields you’d need? List open questions.
It will tell you where your data doesn’t match the template — that’s the fastest way to adapt it.
4

Run your first cases

Upload five or six real orders, deliberately mixed: two clean PDFs, one free-text email, one photo, one with an article the buyer numbers differently. Add a task per order and let them run.
5

Review

Open each finished case with the source document beside the result. Check the reasoning against the document, not the other way around.

​
What good looks like

A fully automated case. A clean PDF from a regular customer:
Matched buyer “Kestrel Instrumente GmbH”, postal code 44227, to customer 30412 on normalized name + postal code — single candidate, no tiebreaker needed. All 6 lines matched on exact article number. No hazard class, total weight 84 kg, no express request → customer default agent SPD-02. Order total 4,180.00 EUR equals the sum of lines. No flags.
Six lines, one query path, nothing ambiguous. This is the case Auto Review will eventually clear without you. A case the agent correctly refuses to resolve. A photo of a signed order form:
Buyer block reads “Meridian Handels”, postal code 8010. Two candidates in customer_master: 40118 (Meridian Handels GmbH, Ostbahnstrasse 14) and 40233 (Meridian Handels GmbH, Ostbahnstrasse 14a). The document carries no VAT ID and no contact email, and the sender domain matches both records. Cannot resolve — customer_match_status: ambiguous, candidates 40118 and 40233. Line 3 “blue housing, 40mm” matched no article number or vendor number. Closest by description: ART-88120 (Housing 40mm, blue), ART-88122 (Housing 40mm, blue, reinforced). Description alone is not sufficient per Step 4 — line_status: unmatched, both listed.
Two flags, both correct, both resolvable by a human in about ten seconds because the candidates are right there. That’s the output you want from a hard case — not a confident guess.

​
Iterating

Fix the procedure, not the case. When a reviewer corrects the same thing twice, change the SOP by chat:
Reviewers keep correcting orders from Kestrel: they use their own item numbers with a “KM/” prefix and we match them by description instead. Add the prefix to the buyer-prefix rule in Step 4.
The agent edits SOP.md, explains the diff, and flags any decision it had to make for you. After a few weeks of reviews, run the improvement loop:
Look at the last month of reviews in Order Match. What are reviewers correcting most often, and what SOP change would fix it?

​
Hardening

Trigger from real intake

Replace manual upload with a mailbox or a Zendesk ticket webhook: ticket in → attachments fetched → case created → ticket updated with the outcome.

Turn on agentic approval

Once your SOP reflects real review feedback, enable Auto Review so full clean matches clear automatically and your team sees only the flagged cases.

Add extraction upstream

At high volume with stable document shapes, an extraction table structures orders first and the reconcile table works rows instead of raw files.

Drive it from the API

Create tasks and poll for results programmatically when the trigger lives in your own system.
Thresholds worth setting explicitly as you harden: the amount above which a case always goes to a human regardless of confidence, the number of unmatched lines that sends the whole order to review, and whether a new customer number ever auto-resolves (it shouldn’t).
All names, article numbers, carrier codes, and values in this cookbook are invented. Replace them with your own master data.