Why Inventory Turnover Is Not in Your Dashboard
The formula is two lines and the denominator is not in any file your store exports. What average inventory actually requires, why a current stock level is not it, and the questions worth asking instead.
Inventory turnover is a standard retail metric, it appears on every list of e-commerce KPIs, and most stores cannot calculate it from the data they have. Not because the tool is limited. Because half of the formula describes something a sales export does not contain.
This is the boundary, stated plainly, and the things worth measuring instead.
The formula, and where it breaks
Inventory turnover = cost of goods sold / average inventory at cost Days of inventory = 365 / turnover
The numerator is fine. Cost of goods sold is quantity sold multiplied by unit cost, summed over the period, and both halves of that are obtainable — order lines carry quantity, and a variant cost list carries the rest, as covered in gross margin by SKU.
The denominator is the problem, and it is a structural one rather than a data-quality one.
Balances and events are different kinds of thing
An order export is a record of events: on this date, this happened. Every figure you can build from it is a sum of events over a window, which is why sales, discounts, refunds and cost of goods all work.
Average inventory is a balance: at any moment, this much stock was sitting there. Balances are not derivable from event records unless you have every event that ever moved them — every purchase order, every receipt, every adjustment, every write-off, every count correction, going back to a known starting quantity. Sales alone are a fraction of that list.
This is the same shape as the capacity problem in professional services, where utilization needs hours that were available and a timesheet only records hours that were logged. Different industry, identical failure: the denominator is a property of the world, not of the transaction file.
A current stock level is not an average
The tempting shortcut is the stock-on-hand figure your inventory system shows today. It is one observation of a balance, taken now, and turnover needs the balance across the whole period.
For a store with flat inventory that is a reasonable approximation. For a store that received a container in October, or ran down stock into a sale, or is seasonal in any way, it is not:
Stock taken 12 Oct, week before delivery 41,000 Stock taken 26 Oct, week after delivery 198,000 Cost of goods sold, twelve months 890,000 Turnover on the first 21.7× Turnover on the second 4.5×
Same business, same year, same formula, and a figure that differs by a factor of five depending on which Tuesday somebody ran the export. A number that unstable is not a measurement.
The request always arrives the same way: someone read that turnover is the metric that matters in retail, and they are not wrong. What follows is the awkward part, because the honest answer is that the data was never kept, and the person asking has usually already seen a turnover figure somewhere — produced by exactly the current-stock substitution above.
What I have learned to do is separate the two conversations. The first is what we can answer today, which is more than people expect. The second is what to start recording so that in a year the answer is yes. A monthly stock-at-cost snapshot is a five-minute export and a folder. It is the cheapest analytics investment a store can make, and it is only ever made by people who have already been told no once.
What your export can actually answer
Four questions, all answerable from order lines plus a cost list, none of which require a balance:
- Units and revenue per SKU over a period. The base of every range decision.
- Gross margin per SKU. Which products earn their place, once cost is joined.
- Revenue concentration. What share of revenue the top twenty SKUs carry. Usually more actionable than turnover and never asked for.
- Sell-through against a known starting quantity. If you know what you bought, units sold over units bought is a real, honest ratio for that buy.
And one more, if you have a current stock level and are willing to state the assumption: days of cover, current units divided by recent daily sales rate. It assumes the recent rate continues, which is exactly as true as it sounds, but it uses today stock level for something today stock level can legitimately support — a forward projection rather than a historical average.
How to make turnover available next year
Export stock on hand at cost, per SKU, once a month, and keep the files. That is the whole requirement. Twelve of those and average inventory becomes a real calculation instead of a guess.
Most inventory systems will do this on a schedule. The reason almost no store has the history is that nobody asks for it until the day they want turnover, and by then the previous year cannot be recreated — a balance that was not recorded is gone.
What we will and will not compute
Quiriz for e-commerce computes net sales, gross profit and contribution margin from the store, refund and ad exports, broken down by product category or channel.
Inventory turnover is not on that list, and asking for it returns a decline with the reason rather than a number. That is deliberate. Every calculation the product could offer for turnover would require substituting a current stock level for an average, and a metric that changes by a factor of five depending on the export date is worse than no metric, because it will be believed.
If you have kept monthly stock snapshots, that changes — the data exists, it can be uploaded, and the calculation becomes real. Without them, the honest answer is the one above.
Ask the questions your export can actually answer
Upload your order lines and a cost list, and ask for margin and revenue by product in plain English. Free to start.
Try Quiriz free →