ClearSummit

Worked example · Orders

Purchase orders, read by software. Approved by a person.

One order from the inbox to the order system: candidate fields, fixed checks, a person's decision, and the cases where it goes wrong.

The situation

“We type every order twice.”

Orders get retyped between our sales and warehouse systems. Unusual orders still need a person.

Try it with four sample orders

A representative purchase order with invented customers and products. It is not your data, and nothing in it is sent anywhere.

Interactive example · synthetic data · extraction simulated

From the inbox to the order system

Nothing here reads a real document or calls a model. The proposed fields are written into the example, so you can see what each step is responsible for.

  1. Document(current)
  2. AI candidate
  3. Rules
  4. Your review
  5. Order system
Choose a sample document
Step 1 · Emailed PDForders@bluebird-kitchen.exampleSubject: PO BKS-4471
BLUEBIRD KITCHEN SUPPLY
Purchase order   BKS-4471
Deliver by       2026-11-18

Item     Description               Qty   Unit
CUP-12   12 oz paper cups (50)      24   6.40
LID-12   Lids for 12 oz cups (50)   24   3.10
NAP-200  Napkins, pack of 200       10   4.75

Thank you, Purchasing

Step 2 · AI candidate

Propose the fields

In a live workflow a model would read this emailed pdf and propose the customer, PO number, date and line items, flagging anything it could not read. Here the proposal is pre-written for the example.

Order system (sample)

What the duplicate check compares against. Reset restores the starting orders.

  • SO-10482 Northgate Cafe Group PO NG-2207Already in the system · 380.00

What each step does, and who owns it

  1. 01 · Software proposes

    Candidate fields

    The customer, PO number, requested delivery date, and each line's SKU, quantity and unit price, with anything unreadable marked. A candidate is never treated as the truth. In this example the candidates are written in advance and no model runs.

  2. 02 · Fixed rules decide

    Checks

    The same rules every time, run only on values that read clearly or that a person has confirmed.

    • The customer is on file, by name or a known alias.
    • The PO number is well formed.
    • The requested delivery date is a real calendar date.
    • Every SKU is in the catalog.
    • Every quantity is a whole number above zero and within that item's limit.
    • Every unit price matches the price sheet.
    • The order is not already in the order system: same account, and the same PO number or the same lines.

  3. 03 · A person approves

    Review

    The reviewer approves, corrects or sends the order back. Approval stays off while any field needs a person or any check fails, and a suggested fix is applied only when the reviewer chooses it.

  4. 04 · Your system receives

    Order record

    Approval writes one sales order: account, PO, date, catalog descriptions, line totals and an order total computed from the approved lines, plus who approved it and every correction. A rejection writes nothing.

When it goes wrong

Unknown SKU
The Riverside Bake House order lists CUP-21, which is not in the catalog. The check fails, names the closest match, CUP-12, and holds the price check until the SKU is real. The reviewer decides whether CUP-12 is what the customer meant.
Duplicate
The customer re-sent PO NG-2207, already in the order system as SO-10482. Approval stays off, and changing the PO number does not get it through, because the lines are compared too. The reviewer rejects it as a duplicate.
Unreadable
On the faxed order one quantity is smudged, so the field stays blank and marked until a person types what the scan says. The date's last digit is smudged too; its candidate is a guess, and the date check waits until a person confirms or corrects it.
Price differs from the sheet
Change a unit price on the clean order and the price check fails, offering the price sheet's figure as the fix.

What stays with your team

Substitutions, unusual orders and conflicting stock counts stay with your team.

Before a first move like this: Confirm the source of truth, access to both systems, and which orders need review.

What this is not

  • Not a new warehouse system. The pattern sits in front of the order system you already run.
  • It does not act on its own. Nothing reaches the order system without a person's approval.
  • Not a model reading your documents. The candidate fields are written into the example, and nothing you type leaves this page.
  • Not a statement about your systems, your volumes, or what it would save.

Where it sits in Leveraged Velocity

You may not need a new warehouse system to stop retyping orders.

  1. Automate

    Copy the order. Keep the judgment.

    Agreed order details move into your warehouse system. Unusual orders go to a person.

  2. Build

    One order. A connected operation.

    Build an order workspace that connects stock, partial shipments and exception handling.

  3. Guided

    Understand. Deliver. Keep improving.

    Review the order journey with your team, including sales, stock and dispatch. Agree a priority, design and deliver the change, then monitor delays and exceptions to decide what comes next.

What Automate covers Terms, ownership and data handling

Systems an order flow like this can connect to

Documented integration surfaces, checked against each vendor's public API documentation. Not completed projects, partnerships, or a promise of access to every feature.

The integration side of this work predates the AI step. For systems we built before AI was part of the workflow, see our automation work.

Start with your own order flow

See the orders first move on the overview, or describe the workflow that keeps landing on someone's desk.
See the orders first move Describe your workflowTalk to the team