We don't have client logos. We have measurements.
Every vendor in this space says data goes missing between systems. Almost nobody shows the number, because the pair of files needed to prove it — one side and the other side, same period, same company — is exactly what nobody publishes. We went looking for the exceptions and measured them with the same script we run for clients.
Two lines by email · no obligation · answered by the person who would do the work
A real retailer's order book: 0.64% simply gone
50,231 mature orders from a real online retailer, published as an open research dataset. Both sides visible: what was ordered, and what was actually shipped.
of orders lost to what the pattern shows to be connection failures rather than stockouts
in the clearest hour — 22 September 2015, 10:00 to 11:00 — 43 orders came in and 42 never shipped
different products in that hour. Stock doesn't run out on 42 products in the same sixty minutes
That last detail is the whole argument. A stockout hits one product. A broad spike across dozens of unrelated products in one hour is a system that stopped talking to another system — and nothing in the retailer's stack raised a hand.
0.64% is a floor, not an estimate: the method only detects group failures. Single orders lost one at a time don't form a detectable spike, so they aren't counted. Source: Mendeley Data, “E-Commerce Dataset” — open it and run the numbers yourself.
One company, one warehouse, two files that disagree about a shoe size
An export from a real footwear manufacturer's WMS — January to October 2023, pulled by SQL straight out of the warehouse system. 122,370 order lines on one side, 215,192 picking records on the other.
The order file writes half sizes as 35, 45, 105. The warehouse file writes the same sizes as 3.5, 4.5, 10.5. Same company, same building, two internal systems — and the field doesn't match on 34% of order lines.
Run a reconciliation on those two files as they are, and it reports 27.3% "ordered but not picked" and 23.9% "picked but not ordered". Both sides broken at once is the classic signature of a wrong join key, and it's exactly the kind of result that gets presented in a meeting as a catastrophe.
After normalising the SKU convention, the picture inverts into something believable:
| After normalisation | Pairs | Share |
|---|---|---|
| Ordered, never picked | 5,148 | 4.58% |
| Picked, never ordered | 13 | 0.01% |
| In both, quantity differs | 96 | 0.09% |
The asymmetry is the proof the key is now right: a warehouse doesn't pick things nobody ordered. Units ordered 228,175 against 215,192 picked — a 5.69% gap. Source: Mendeley Data, “Order Picking Dataset from a Warehouse of a Footwear Manufacturing Company”.
This is why the free check refuses to print a number below a 90% key match. A broken join looks exactly like a catastrophic leak, and the difference between the two is the difference between a process fix and a panic.
A multinational with three-way match in SAP — still 4% invoiced twice
The BPI Challenge 2019 event log: a real purchase-to-pay process at a large multinational, with proper three-way matching configured in SAP. The kind of setup nobody in our market has.
of items received with no invoice recorded against them — €137.6M of goods
of items invoiced more than once, across €327.8M of invoice value
of line items in dispute one way or the other, inside a controlled enterprise process
The point isn't that the multinational is careless. It's the opposite: this is what the failure rate looks like with automated three-way matching, audit trails and a finance team. A 60-person brand approving a 3PL invoice as one number in their inbox is not operating at a lower error rate than that.
Source: 4TU.ResearchData, BPI Challenge 2019.
Two more, for the shape rather than the number
A Brazilian marketplace export with orders plus the handover to the carrier — useful because it shows the same gap appearing at a second seam, and because it contradicts a convenient story: bigger sellers there were cleaner, not messier.
A supply-chain dataset with order status against actual shipment — the file that taught us to treat "status says delivered" as an opinion rather than a fact, and to reconcile against the event rather than the field.
Each dataset changed the script
SKU normalisation exists because of the footwear file. The 90% key-match refusal exists because of what happened before normalisation. Excluding recent, cancelled and returned orders from the "missing" bucket exists because the first dataset otherwise reported 8.84% and most of it was cancellations.
That's the reason this page is titled evidence rather than case studies: the data didn't just produce marketing numbers, it produced the refusals.
What we are not allowed to say from this
The same discipline that makes the numbers usable makes most of the obvious sales lines unavailable. So, in writing, the things we won't claim:
- “You have 0.64%.” Different company, different country, 2015. It's a floor observed elsewhere, not a forecast of your number.
- “8.84% of orders go missing.” That was the raw figure before cancellations were excluded. The honest number after exclusions is the smaller one.
- “This is Shopify and 3PL data.” No such public pair exists. These are analogous seams in comparable systems, and that's all.
- “Smaller sellers leak more.” Convenient for us, and the marketplace data points the other way.
What we do say: nobody knows your number, because nobody measures it. Fifteen minutes on your own export settles it — and if it turns out to be small, we'll say so and you'll have spent nothing. Run the check →
Where to go from here
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