Every purchase order a buyer emailed us was retyped by hand, line by line, into the store.
- Client
- An early-stage software company selling order automation to B2B sellers
- Their customers
- Sellers on two hosted ecommerce platforms who take wholesale orders as emailed purchase orders
- Engagement
- The whole product, from the multi-tenant web app to the AI extraction service
The outcome in five lines
| Measure | Before | After | Evidence |
|---|---|---|---|
| How a purchase order reaches the store1 | a person read every line and retyped it into the store | the AI service reads it, rules match it, and a person checks the flagged fields and sends it | Described |
| Ways an order can arrive2 | one, an attachment in someone's inbox | three, the seller's own inbox address, a dashboard upload or an API call | Measured |
| Matching a line to the catalogue3 | a person searched the store for each product | exact SKU first, then a title similarity above 0.8, otherwise a flag for the person | Measured |
| Orders too long for one model call4 | one call for the whole document | past 6,000 characters, split with a 400-character overlap, read in parallel and merged, with lines repeated in the overlap dropped by rule | Measured |
| A scanned purchase order with no text layer5 | nothing to read, so no line items came back | sent to an OCR service and read again | Described |
Three lines carry a counted figure and two describe a change with no number. The small number beside each line says how it is known.
The problem, in the client's terms
Our client wanted to sell one thing to wholesale sellers, never retyping a purchase order again.
B2B buyers rarely order through a storefront. They email a purchase order as an attachment, and every buyer uses a different layout. One sends a PDF exported from their ERP, another a scanned page, another a spreadsheet. Someone at the seller then reads each line and keys the customer, the addresses, the SKUs, the quantities and the prices into the store by hand.
The work is slow, repetitive and easy to get wrong. A mistyped SKU or quantity ships the wrong goods.
The person who does it is usually also answering buyers and packing orders, so a long purchase order waits until someone has an hour free.
The client asked us to build the product that removes that step, as a self-serve service any store owner could sign up for and connect.
- ConstraintNothing the AI reads may reach a store on its own. A person sends every order.
- ConstraintEach seller's catalogue, customers and orders stay separate from every other seller's, in one product.
- ConstraintThe model must not invent a field it cannot read. An unclear field is left empty for the person.
- ConstraintA seller pays the client per processed order, so the plan and its remaining orders are checked before a document is read, and processing stops if that check fails.
The architecture, before and after
Switch between the two. The buyer's email and the seller's store stay as they were. What changes is the middle, where a person stops typing and starts checking.
- What hurt in this state
- Built in this engagement
Three decisions, and the options they rule out
Calling a language model is the easy part. These choices decide what happens when it misreads a line, a long order or a scan. Each one names what it replaced and what it cost.
Where the AI work runs
Turned down
Extraction as background jobs inside the web app
OCR jobs, model calls and parallel chunks run for a long time. Inside the web app they would hold the same workers that answer sellers and sync stores, and a slow order would slow every seller.
Chosen
A separate AI service that takes a file and answers through a webhook
The service knows nothing about sellers, stores or billing, so it can be scaled and changed on its own. The web app keeps every rule about who owns what.
What it cost: Two systems mean a callback between them that can fail. One did fail silently, as the went-wrong section below describes, and it took a root-cause review to find.
What decides which product a line is
Turned down
Asking the model to pick the product from the catalogue
The catalogue would have to travel with every order, and a model's pick cannot be explained when it is wrong. A plausible but wrong product is the most expensive mistake in this job.
Chosen
Plain rules after the model has read the order
Exact SKU first, then a title similarity above 0.8, with customers matched by name and address. Every match can be traced to a rule, and anything that fails its rule is flagged for the person.
What it cost: Rules miss what a person would catch, such as a buyer's own abbreviation for a product, so those lines arrive flagged and the person does more picking.
How each order's steps are run
Turned down
An agent framework that loops until the order looks done
A loop decides its own next step, so a failure can surface anywhere or not at all. This job has a fixed shape, and every failure has to land somewhere a person will see it.
Chosen
A cloud workflow engine, one run per order
Each step is a short function with its own failure handler. A choice step sends short orders to one call and long ones to a parallel map, and any failure goes to a webhook that marks the order failed with its reason.
What it cost: The pipeline is tied to one cloud's workflow service, and keeping one trace per order across parallel runs meant passing the parent trace id into every chunk by hand.
How it was delivered
Our software engineers built both services, the store integrations, billing and the pipeline. The client owns and sells the product.
The web app and the first store
Seller sign-up, a dedicated inbox address for each seller, dashboard upload, and a draft order sent to the first hosted platform.
B2B buyers
The first platform's business buyers and their ship-to addresses synced in, so a ship-to address is checked against the addresses that buyer has on file.
Usage billing
Self-serve plans with a free trial, then billing per processed order, with the quota checked before any document is read.
The pipeline rebuilt on a workflow engine
One workflow run per order, schema-bound extraction, the text-layer reader with an OCR fallback, and chunked extraction for long orders.
Typed chains and tracing
Extraction split into header, line item and validation chains, with every model call traced and its tokens and cost counted.
The second store platform
A connection to a second hosted ecommerce platform, with checked orders sent there as well.
Who did the work
- Atyantik software engineersThe web app, the AI service, email intake, both store integrations, billing, matching and tracing
- Client's teamProduct direction, its pricing and its sellers
Who owns what now
The product runs in production, staging and development environments, each deployed from CI. Failure alerts on the AI callback, a measured before and after time per order, and confidence scores that let clean orders skip review are the next items.
Results
What a seller has to do with a purchase order, before and after.
- The seller's order desk checks the flagged fields next to the original document instead of typing every line.
- Sellers with B2B buyers see a ship-to address checked against the addresses the buyer's company has on file before anything is sent.
- The client's own team can follow any order step by step in its trace, with the tokens and the estimated cost of every model call.
No figure is given for minutes per order before and after, for orders processed, or for the share of orders sent without an edit.
1, an inbox and a person
Before
3, inbox, upload and API
After
Every route lands in the same pipeline and the same review screen, so a seller checks an order the same way however it arrived.
| Option | Routes into the product that end in an order a person can check and send. Before, the only route was a person reading an inbox. |
|---|---|
| Before | 1, an inbox and a person |
| After | 3, inbox, upload and API |
Source: Source note 2
What retyping purchase orders costs you today
We do not publish what an engagement costs. So this works from your side: what your team spends keying purchase orders into the store by hand, the work this product takes off them.
Cost of retyping purchase orders, per year
$7,800
- Hours spent retyping, per year
- 260 h
What went wrong, and what we would do first
Order processing on staging stopped for seven weeks, and nothing said so
A root-cause review found that orders on staging had silently stopped being processed for seven weeks. The causes were serialisation and payload bugs in the callback between the AI service and the web app, and no alert fired. We fixed the callback and every step now ends in a failure webhook that marks the order failed with its reason. Next time an asynchronous pipeline gets failure alerts on the callback from the first day, before the first order runs through it.
Spreadsheet and Word readers did not make it into the final pipeline
Buyers send spreadsheets and Word files as well as PDFs. We prototyped readers for both, but the workflow pipeline was built around PDF and those readers were not carried into it. Next time we would turn every format into plain text before the workflow starts, so a new file type is one reader and not a new pipeline.
Will AI order extraction work for your order desk?
It fits when
- Your buyers send purchase orders as PDF attachments, in layouts you do not control.
- Your store or ERP holds the catalogue, with SKUs on most products, so lines can be matched by rule.
- You want a person to check every order before it is placed, at least until enough reviewed orders exist to trust a confidence score.
Look elsewhere when
- Most of your buyers can send a fixed spreadsheet or use an EDI feed. A plain importer is cheaper and never misreads a column.
- Your products have no SKUs and buyers describe them freely. Fix the catalogue first, because rules can only match what it names.
- You take a handful of purchase orders a month. Typing them is cheaper than running a pipeline.
Check it yourself this week
If most of last week's orders came in several layouts and most lines carried a SKU you sell, extraction plus rules could take the typing. Put your numbers into the calculator above.
- Collect last week's emailed purchase orders.
- Count the PDFs, the different layouts and how many were scanned pages.
- For each order, count the lines whose SKU matches one in your store exactly.
How it is built, by layer
- AI extractionA hosted large language model with schema-bound output, through three typed chains for the order header, the line items and a maths check, at temperature 0
- Document readingA PDF text-layer reader first, and a cloud OCR service for scanned pages
- AI serviceA cloud workflow engine running short serverless functions, one workflow run per order
- Web appA multi-tenant web application on serverless hosting, with a relational database, a cache and job queues
- Email intakeA cloud mail-receiving service that stores each message and notifies the web app through a queue
- Store integrationsTwo hosted ecommerce platforms through their APIs, including business buyers and their ship-to addresses on one of them
- BillingA payment provider, charging the client's sellers per processed order
- ObservabilityAn open-source tracing tool for model calls, with tokens and cost per order, and error tracking
How each figure was measured
- How a purchase order moves from the inbox to the store, before the product and with it, step by step.
- Routes into the product that create an order, counted in the web app.
- The matching rules in the web app, with the similarity threshold a product title must pass.
- The length threshold and overlap set in the AI service, derived from the model call's token budget.
- The text-reading step of the AI service, which falls back to OCR when a PDF gives no text or no line items.
Send us a week of purchase orders, and we will tell you if AI should read them.
Share a few real orders with the prices blanked and tell us where they get typed. A software engineer reads them and replies with an honest answer, including when a plain importer would do.