A seller on r/shopify described the job exactly: the supplier emails a shipping confirmation for every order, you open it, copy the tracking number, paste it into the order, mark it fulfilled, then do the next one. Some days that is thirty orders and an hour gone. Another described the same work weekly — three hours of copy and paste every Sunday night.
The instinct is to automate it end to end. That is the wrong first move, and the best reply in that thread said why: the useful version only shows the unmatched or stale ones, which turns three hours of checking every order into ten minutes fixing edge cases.
Why reconciliation comes before automation
Full automation writes to your store. That means credentials with write scope, which means a merchant-owned app, which means the developer-application queue. And it means that when the supplier changes their email template — which they will — you get silent wrong fulfilments instead of a visible pile of unmatched rows.
Reconciliation gives you the same hour back with none of that exposure, and it tells you whether the matching is even reliable before you let anything write. If you want the full picture of what write access costs on each platform, we wrote that up separately in the Shopify Admin MCP walkthrough.
The two exports
Your orders. Any export with order number, recipient name or address, line items and current fulfilment status. Shopify, WooCommerce, Etsy and eBay all produce this from the admin with no API access at all.
The supplier's confirmations. Export the mailbox folder those land in — most clients export a folder to .mbox or a set of .eml files. If your supplier sends a CSV or portal export instead, use that; it is cleaner and it will not drift when they redesign their template.
Both go in one local folder. That folder is the whole workspace.
Four tables, and only three of them are a list
Ask for exactly this shape, and do not accept prose instead:
- Matched and consistent — a count only. Do not list them.
- Unmatched confirmations — a tracking number with no order behind it.
- Unmatched orders — orders older than N days with no confirmation at all.
- Ambiguous — anything that matched more than one order.
Match on order number first, and fall back to recipient name plus postcode only when the order number is absent. For tables 2 to 4, require the exact source fields used for the match. And require that a match it is unsure about goes into table 4 rather than being guessed into table 1.
Table 1 being a count rather than a list is the entire design. On a normal day that number is 28, the other three tables are empty, and you are done in ten seconds.
What each table is actually telling you
Table 2, tracking with no order. Usually a supplier shipping against a cancelled order, or a duplicated confirmation. Cheap to check, and it occasionally catches double-shipping before you pay for it twice.
Table 3, order with no tracking. This is the expensive one and the reason to run the whole thing. These become “where is my order” tickets, and on marketplaces they become late-shipment metrics that cost you visibility rather than just goodwill.
Table 4, ambiguous. Almost always two orders to the same household. Worth resolving by hand precisely because a fully automatic system would have picked one and been wrong half the time.
Then, and only then, write back
Once you have run this for a couple of weeks and table 4 is reliably empty, the matching is trustworthy enough to act on. At that point the fulfilment write should still be a graded action rather than a free-for-all: a preview before it fires, and a cap on how many orders a single call may touch, so a bad match cannot quietly fulfil two hundred of them.
If you never get to that stage, the reconciliation alone has already removed the hour. That is the part worth keeping.
Running it in Orkas
Drop the two exports into a project folder and keep them there. Because the project keeps its context across days, tomorrow's run can compare against today's table 3 — and an order that has been sitting without tracking for three days running is a different problem from one that appeared this morning. Only the diff tells you which. Files and keys stay on your machine; model calls go straight to your provider.
The same folder is where the rest of the weekly store work lives, which we walk through in the e-commerce store review use case.
What this does not cover
- It will not parse a supplier email format it has never seen without you checking table 2 the first few times.
- It does not know a package is lost — only that you were never told it shipped.
- Carrier-side tracking status is a separate problem. This reconciles that a number exists against an order that needs one, nothing more.