POs, shipment splits, and finance in separate files, and the real answer spread across half the operations team — until one system tracked every unit from factory to warehouse.
Meet PO Manager
PO Manager is an internal system for purchase orders, the shipment splits underneath them, and the money attached to both. A business buying by season splits each PO across destinations and ships from factory into warehouses in the UK, EU, and US. Shopify shows what is in stock; the question everyone actually asks is what is still on the water.
The challenge
Nobody held the whole picture
Two sources held overlapping truth and never spoke: PO sheets and stock split sheets, with splits spread across several more files. Predicting PO cashflow meant cross-referencing all of them by hand. And a question as simple as “when does more of this land in the US” turned into a round of messages — the buyer who placed the PO, whoever built the splits, whoever last heard from the freight forwarder, the warehouse that knew what had actually been received, finance for whether an invoice was coming. Everyone held a piece. Nobody held the picture. Because no one owned the updates, shipment attributes went stale — the same attributes that decide when significant supplier payments go out.
Not “tidy up the trackers.” Connect POs, splits, and finance into one system that reconciles itself — so the Shopify balance is a number the business can trust.
The solution
The order of the data was the design. A PO lands as a CSV at child-SKU level with cost price, then locks — that is the version everything else reconciles against. Splits go on next: where those units are actually going. After that it is movement — status changes, shipment merges, and a terminal received state. Matching runs against the locked PO, so a split either reconciles or shows as a gap nobody has to go looking for. The original tracker carried around 25 attributes per shipment; I kept the ten that drive duty, timing, and payment, and left the medium-priority ones as API candidates rather than ten more fields to forget. The ETA spreadsheet came in last, as a factory-to-warehouse timeline per parent SKU.
CSV ingestion for POs and splits, automatic PO-to-shipment matching, ETA calculation from ex-factory date and shipping method — shipping line and arrival port left as API candidates.
What made the difference
PO Dashboard
Seasons against shipment splits with a units or revenue toggle, and payment terms — Deposit, EXF, EXF+60 — laid out by month, so $3.33m of the $8.63m buy showing as undefined is visible rather than assumed.
Workspace
Season by season with PO count, value, units, and allocation — then drill to Total Buy, Received, Outstanding, and Allocated % on one screen.
Product lookup
One search across parent SKU, child SKU, model, colorway, season, and destination — instead of a VLOOKUP per tab, per season.
Shipment ETA timeline
Factory, departure, warehouse arrival per parent SKU — the spreadsheet that calculated ex-factory plus transit by hand, built in.
Warning banners
Bad data surfaces the day it appears — a zero-quantity placeholder colorway sitting in a live PO with cost attached, instead of three months later.
The results
Anyone in the business could say why the Shopify balance sat below the PO placed — without a round of messages to assemble it.
The PO locks. The splits reconcile against it. The answer takes seconds, and it comes from the system instead of five people’s memories.