Your storefront says it sold. Your warehouse never heard of it.
The orders that cost you aren’t the ones that fail loudly — those get retried. It’s the silent ones: payment cleared, fulfilment never heard of it, and nothing says so until the customer asks.
Three months of orders against shipments, causes grouped. $1,200 — $600 for the first three.
Two lines by email · no obligation · answered by the person who would do the work
Webhooks fail quietly, and then stop existing
This isn’t a theory about sloppy operators. Shopify documents the behaviour: a failing webhook is retried eight times over about four hours, and after eight consecutive failures the subscription is deleted — after which orders simply stop arriving downstream, with no error on your side. Their documentation →
Their own documentation recommends polling the Orders API to find orders your system missed — the platform telling you in writing that a separate reconciliation is required. Most brands have never read that page.
The same shape appears without webhooks: a marketplace order that failed validation, a connector run that timed out mid-batch, a return scanned into the warehouse whose posting job silently errored.
Three that come up most
Paid, never fulfilled
Payment cleared, the webhook didn't. The order sits as paid/unfulfilled in a view nobody opens until a customer emails.
SKU drift
TWL-BLU-SET in the store, TWL_BLUE_SET at the warehouse. The connector never matches them, and you get oversells on one side and dead stock on the other.
Returns that never post back
The warehouse received it. The store system doesn't know. The refund goes out and the unit stays invisible.
One hour, 43 orders, 42 of them lost
There is one public dataset where both sides of this seam are visible at once — a retailer's orders and what the warehouse actually shipped. We measured it instead of guessing.
of orders vanished between the two systems
orders in the worst hour, across 42 different products — stock doesn't run out on 42 products in the same hour
a month at that rate for a brand doing $5M at an $80 average order value: refunds, reships, and stock already paid for
The honest caveat: that's one dataset, and yours will be different. It's a starting point for the question, not an estimate of your number. Most brands have never measured their own, which is exactly why it isn't in anyone's reporting. How we measured it →
Two exports you already have
Export orders and shipments
Orders from Shopify, Amazon Seller Central or your ERP; shipments from the 3PL portal, ShipStation, ShipHero or the WMS. Same date range, standard exports, no integration or access required.
They get lined up by order number
Where order numbers don't match formats across the two systems — a prefix here, a suffix there — we normalise and report the match rate. Below 90% we say the files can't be trusted together instead of printing a number.
You get every paid order with no shipment against it
With the value attached, grouped by likely cause: never arrived, arrived and failed validation, shipped but never posted back, cancelled upstream only.
You can run this yourself right now, free. The browser version does the same matching on your own file, on your own machine, with nothing uploaded and no account. Run the check →
See the orders you were paid for and never shipped
Not a mock-up: this is the output of the same script we run on client exports, pointed at the sample files that ship with it. Note what it does with a result above 5% — it argues with itself before it argues with you.
The file is what you would actually receive: one row per problem order, with the value, the age and what to do about it. Take it to your operations meeting and see whether the columns are the ones you would ask for.
What lands in your inbox
The version that runs every morning
A one-off check tells you what the last quarter cost. It doesn't stop the next one, because the failure mode is continuous: every integration in your stack breaks on a renamed column — connectors, middleware, custom scripts, all of it. That isn't the interesting question.
The question is how long it stays broken before anyone notices. In an error queue nobody owns, that's until month-end. With a daily check it's a morning, because looking is the job rather than a side effect of it.
You get the exceptions before you're at your desk, with the value attached, and we keep the check working when your 3PL changes their export format — which they will.
Published
- Every paid order with no shipment, with value
- Returns received and never posted back
- Causes grouped, not just a list
- Exceptions in your inbox before the day starts
- Format changes handled, not billed as a project
- Month to month, no lock-in
The ones that come up
Our 3PL portal shows all of that.
It shows what they shipped. It cannot show an order that never reached them — that order isn't in their system at all. Same with a connector: it reports what it processed, not what it silently dropped. That gap is the whole reason the check needs two files instead of one.
We use Celigo / Zapier / a native integration. Doesn't it flag errors?
Yes, and that genuinely helps. Detection isn't resolution: the errors land in a queue, and at most brands of this size nobody is assigned to read it daily. The integration also can't see gaps between tools it doesn't touch. We're not replacing it — we're reading the queue and the space around it.
Isn't your script just as fragile as the connector?
Honestly, yes — it breaks on a renamed column like everything else. The difference isn't robustness, it's attention: watching and repairing it is the job we're paid for, not an afterthought between other work.
Can you do this for Amazon and other marketplaces?
Yes. Marketplace settlement files have the same shape of problem, plus their own flavours — reimbursements that never arrive, units lost inbound. The matching logic is the same; the file formats differ.
The neighbouring seams
Two lines by email. No form, no calendar link.
Which two systems, roughly what size, what you have already tried. You get a straight answer the same working day — including “this is not something we would help with”, when that is the honest one.
Two lines by email · no obligation · answered by the person who would do the work