What counts as a sale in the reorder report, and what does not
How Restock Ops turns Shopify orders into a sales velocity: which orders and line items count, refunds and cancellations, POS, locations, and the limits.
Every reorder suggestion in Restock Ops starts from one number: how many units of an item you sell per day. Multiply it by the supplier's lead time plus the days of cover you want, compare the result with what you have and what is on order, and the gap is the suggestion. The arithmetic is simple and has been written up before, in low-stock alerts versus the reorder report. What has not been written up is where that first number comes from, and it is the part merchants question most, usually in the form 'why does it say I sold 14 when I know I sold 20?'
This post is the answer. It walks through exactly which Shopify orders the report reads, which line items inside them count, how refunds, cancellations, exchanges, POS and multiple locations are treated, and the two limits that can make a velocity look lower than reality. None of it is hidden; the report prints the formula at the top. But the formula says 'units sold in the last 30 days ÷ 30', and this is what 'units sold' means.
The window, and which date it uses
The window is the Sales velocity window in Settings, 30 days by default, and the report reads orders whose created date falls inside it. Created, not paid, not fulfilled. A pre-order placed on the first of the month counts on the first even if it ships on the twentieth; an order paid late counts on the day it was placed. This matches how most people think about demand, since the shopper decided to buy on the created date, but it means a fulfilment backlog does not lower your velocity and a burst of pre-orders raises it immediately.
Changing the window changes every velocity at once. A shorter window reacts faster and swings more; a longer one is steadier and slower to notice a trend. Seasonal stores tend to shorten it going into a peak and lengthen it coming out, which ordering for the holiday season goes into, including the per-item manual rate for when no window length fits.
Which orders are read
The report asks Shopify for orders in the window with any status, open, closed or archived, and explicitly excludes cancelled ones. A cancelled order contributes nothing, however many units it held and whether or not it was restocked. That is the right call for ordering, since a cancelled order is demand that evaporated, but it also means a wave of fraud orders you cancelled a week later never shows up as velocity, which is exactly what you want.
Beyond cancellation there is no filter. Orders from your online store, from POS, from a draft order you completed by hand, from a wholesale channel or a marketplace that pushes orders into Shopify all count equally, because Restock Ops has no way to know which of those channels your stock serves and does not try to guess. A draft order that is still a draft is not an order yet and does not count; the moment it is completed it becomes one and does. Test orders placed through Shopify's test gateway are real orders in Shopify's eyes and count too, so cancel them when you are done.
| Situation | Counts? | Why |
|---|---|---|
| Open, paid, unfulfilled order | Yes | Created in the window; fulfilment state is irrelevant. |
| Closed or archived order | Yes | Orders are read with any status. |
| Cancelled order | No | Excluded from the query entirely, restocked or not. |
| Refunded line item | No, or partly | The line's current quantity is used, which is reduced by refunds. |
| Item removed by an order edit | No | Removal lowers the current quantity to zero. |
| Item added by an order edit | Yes | It becomes a line item on the order with its own quantity. |
| POS order | Yes | No channel filter; all orders count shop-wide. |
| Completed draft order | Yes | It is an order once completed; an uncompleted draft is not. |
| Pre-order placed in the window, ships later | Yes | The created date is what matters. |
| Line whose variant was since deleted | No | There is no inventory item to attribute the units to. |
Which units inside an order are counted
Within each order the report looks at the line items and, for each, takes its current quantity rather than the quantity originally ordered. Shopify keeps both on every line: the quantity at the time of purchase and the quantity after any refunds or order edits. A shopper who bought three and returned one has a line with an original quantity of three and a current quantity of two, and the report counts two. A shopper who bought an item that you later removed from the order entirely has a line with a current quantity of zero, and it counts nothing. Shopify documents both fields on the line item in its Admin API.
Exchanges follow from that. A return handled as a refund plus a new line on the same order lowers the old line and adds a new one, so the item the shopper kept counts once and the item they sent back counts zero. A return handled by cancelling and re-creating the order counts the new order and nothing from the cancelled one. Either way the velocity reflects what left your shelves for good, which is what you reorder against.
Units are attributed to inventory items through the variant on each line. That is a deliberate choice: a variant can be renamed, repriced or moved between products and its inventory item stays the same, so the velocity follows the stock rather than the label. The one case that falls through is a line whose variant has since been deleted; with no variant there is no inventory item, and those units are dropped. If you delete and recreate variants as a way of 'resetting' a product, you also reset its sales history as far as the report can see.
One velocity for all locations
The reorder report is built for one location at a time: on hand and incoming are read for the location you pick at the top. Velocity is not. Units sold are counted across the whole shop, whichever location fulfilled them or would have, and the same velocity is used for every location you switch to.
This is not an oversight. Shopify records a location on an order only once something is fulfilled from it, and an unfulfilled order, which is most of the orders in a recent window, has no reliable location at all. Online orders routed by Shopify's fulfilment rules can be assigned to one location and shipped from another. Rather than attribute units to locations with a guess that would be wrong often enough to be dangerous, the report uses the shop-wide figure and leaves the split to you. For a single-location store there is no difference. For a store with a warehouse and two shops, the practical approach is to run the report for the location that actually holds and ships the bulk of each item, and to treat the suggestion for the others as a transfer question rather than a purchase one.
If one location sells at a very different rate from the whole, the per-item Sales per day override is the tool: set the rate you observe for that location and the report marks the row as running on a manual rate rather than on orders, so you can see at a glance which items are on history and which are on your number.
Two limits that make velocity look low
The first is a page cap. The report reads orders in pages of 250 and stops after 20 pages, so a window containing more than 5,000 orders is cut off and the report says so in a banner: 'Only the first 5,000 orders of the window were read; velocities may be low.' The fix is in the banner too: shorten the window in Settings until it holds fewer than 5,000 orders. A store doing 300 orders a day has about 16 days before hitting the cap; a 14-day window is honest for that store, and a 30-day window would silently undercount. The cap exists so that opening the report never becomes a minutes-long crawl through your entire order history.
The second is permission. Units sold come from orders, and orders are protected customer data in Shopify's terms. Restock Ops requests only the fields it needs, quantities and variant identifiers, never names, addresses or emails, which is also why labels, receipts and purchase orders in the app carry no customer information. Even so, Shopify requires the app to be approved for protected data access, and until that approval is in place the orders query is refused. When that happens the report does not fail; it shows a Sales data unavailable banner explaining that Shopify has not granted order access yet, velocities appear as a dash, and only items with a manual Sales per day rate get a cover-based suggestion. Reorder points, which need no velocity, keep working. Shopify describes the approval process in its protected customer data documentation.
What the velocity does once it exists
The rest is arithmetic, and it is worth seeing once with the velocity's quirks in mind. An item that sold 42 units in a 30-day window has a velocity of 1.4 per day. With a supplier lead time of 10 days and cover of 14, the target position is 1.4 × 24 = 33.6, rounded up to 34. If you hold 12 on hand with 10 on order, your position is 22 and the report suggests 12, rounded up to the supplier's MOQ or case size if either is set, as described in lead times, MOQ and reorder planning. Days of cover is position divided by velocity: 22 ÷ 1.4, about 16 days.
An item that sold nothing in the window has a velocity of zero. It gets no days-of-cover figure and no cover-based suggestion, because the report will not propose an order for something with no demand. The only thing that can trigger a suggestion for it is a reorder point you set by hand: when the position falls to or below that point, the report suggests enough to get back above it. That is the right behaviour for slow items and new items alike, and it is one more reason to give new products a manual rate for their first month, before they have history to stand on.
If a velocity still looks wrong after all of this, the quickest check is Shopify's own order list filtered to the window with cancelled orders excluded, counting the item's current quantities by hand for a few orders. The report is doing the same sum, with the same exclusions, and seeing them side by side usually locates the refund or the cancelled order that explains the gap. Restock Ops shows its working so that you can.
FAQ
Does the reorder report count cancelled orders?
No. The report reads orders of any status except cancelled, so a cancelled order contributes no units regardless of whether its stock was restocked. Refunded items on orders that were not cancelled are handled separately: the line's current quantity, which refunds reduce, is what counts.
Why is my velocity lower than the sales I can see in Shopify?
The usual causes are refunds and order edits, which lower a line's current quantity; cancelled orders, which are excluded; and the 5,000-order page cap, which the report flags with a banner. Shopify's sales reports also record a return on the date it was processed rather than against the original order, so the two figures legitimately differ.
Does the reorder report separate sales by location?
No. On hand and incoming are read for the location you choose, but units sold are counted across the whole shop because Shopify does not reliably record which location an unfulfilled order belongs to. Use the per-item Sales per day override when a location's rate differs materially from the shop's.
Do POS sales count toward velocity?
Yes. Every order in Shopify counts, whether it came from the online store, POS, a completed draft order or another sales channel. There is no channel filter, so the velocity reflects total demand on your stock.
What happens if the app cannot read orders?
Orders are protected customer data and need Shopify's approval. Until then the report shows sales data as unavailable, velocities as unknown, and suggests orders only for items with a manual Sales per day rate or a reorder point. Nothing else in the app depends on orders.
Try it on your store. Restock Ops adds purchase orders with partial receiving, supplier notes, cost history, barcode labels, scanner stocktakes and a reorder report on top of Shopify inventory. From $19/month, 14-day free trial.