Thirteen numbers, each with its formula, the data it needs, the trap that makes it lie, and how often to run it — plus the five worth putting on a monthly sheet.
A metric earns nothing by being on a dashboard. It earns its place when a movement in it makes somebody order sooner, buy less, count more often, or use up something already sitting on a shelf. Everything below is arithmetic you do yourself, from records you already keep — purchase invoices, the cost price on an item, the quantity on the shelf, your own order history.
On this page
Four parts, and a metric that fails any of them belongs in a drawer rather than on a review sheet.
The denominator is where most of these quietly go wrong. Turnover can be measured against average inventory or against closing inventory. Shrink can sit over cost of goods sold or over revenue. Sell-through can be a share of what you received or a share of what you had. Each pairing produces a different answer from the same underlying facts, so write the denominator into the definition and leave it alone for the year. If you must change it, restate the previous twelve months on the new basis before you compare anything to anything.
Stockout calculates none of the metrics in this guide and stores none of them. It holds the raw material — current quantity, cost price and retail price on every item, and a stock-movement ledger — and eight analytics charts built from it. Every formula below is yours to run.
These are decision aids with soft inputs: an average daily usage that moves week to week, a carrying rate you estimated, a count taken on a Tuesday. Two significant figures and a trend line beat four decimal places. If a metric has to move three tenths of a point to change what you do, the metric is not the problem — the decision rule behind it is.
Every formula on this page draws on one of six inputs. Knowing which of them the app can hand you, and which you have to go and fetch, saves the first hour of building a review sheet.
| Input | Where you get it |
|---|---|
| Cost of goods sold for the period | Opening count, purchase invoices, closing count — never from the app |
| Inventory value at cost | Item cost price × quantity; the Stock at Cost vs Retail chart reads it for the current moment |
| Units removed over a window | The stock-movement ledger, in bulk only through the read-only API |
| Lines requested and lines filled | Whatever you quote and invoice from |
| Count results and variances | Your own count sheet — the app records no count and no variance |
| Carrying cost percentage | Built once a year from five components, further down this page |
Inventory value at cost is the easiest of the six. Stockout keeps a cost price and a quantity on every item, both set in the item editor — see how item fields and thresholds are set — and the Stock at Cost vs Retail chart puts the current stock value at cost beside its retail value. What it will not give you is a month-end series. It is a current reading, so if you want twelve monthly points to average, somebody writes the figure down on the last day of each month.
Cost of goods sold is the one number that never comes out of the app. Compute it the accounting way, from two counts and a stack of supplier invoices.
COGS = opening inventory at cost + purchases at cost − closing inventory at cost
Inventory value at cost = Σ (item cost price × quantity on hand)
One business runs through every formula on this page: annual COGS of $1,980,000, opening inventory at cost of $310,000, closing inventory of $350,000, revenue of $3,300,000, 600 stocked SKUs, and the same mid-value consumable that carries the reorder-point guide — 18 units a day at $40 a unit.
For the movement rows themselves there is one route. The public API is read-only JSON over HTTPS — GET and HEAD only, 24 collections including the stock-movement ledger — with keys minted by an Owner or Admin at Settings → Developers → API Keys. See the API reference. It reads and never writes, and a key reads the whole organization rather than a single site, so scope the query yourself if you report per location. That is the only bulk route to movements; everything else on this page is typed off invoices, order records and count sheets.
Inventory turnover = COGS ÷ average inventory value at cost
Days of inventory = 365 ÷ turnover · Weeks of inventory = 52 ÷ turnover
GMROI = gross margin dollars ÷ average inventory at cost
Turnover answers how many times you sold and replaced the average dollar sitting on the shelf. It changes exactly one decision — how much cash is parked in stock relative to what you actually move — and it is the parent of half the metrics below.
Convert it to days before you show it to anyone. "Six turns" means nothing on a warehouse floor; "61 days of stock" means something to everyone in the room.
Turnover on its own pushes you toward cheap, fast-moving junk, which is why the GMROI line sits in the same block. A category can turn twelve times on a 6% margin and earn less per inventory dollar than one turning three times at 40%. Run both or you will optimize the wrong half of the catalog.
There is no benchmark to hit here, and a figure borrowed from another business is worse than none, because turns depend on what you sell and how you buy it. Judge two things instead: the direction across four quarters, and the gap between your fastest and slowest categories. Next year's target comes from this year's own number.
Buying hand-to-mouth in small lots raises turns while raising freight and shortages, so read turnover against the stockout rate below and never on its own.
Writing off dead stock in December shrinks closing inventory, which lifts next year's turns without a single extra sale.
Turnover looks backward at the whole business. Cover looks forward at one item: on-hand divided by average daily usage is the number of days the shelf lasts at the current burn rate. The running item — 540 on hand at 18 units a day — has 30.0 days, or 4.3 weeks.
Days of cover = on-hand quantity ÷ average daily usage
Weeks of cover = days of cover ÷ 7
Cover is a triage sort, not a trigger. Sort the catalog ascending and the top of the list is what to look at today; sort descending and the bottom is money you over-bought. It contains no lead time, so it cannot tell you to place an order. A coverage number is not a reorder point — that needs lead time, a review period and a buffer, all worked through in the guide on reorder point and safety stock.
Stockout ships a chart called Weeks Cover, and the names are close enough to be confused, so here is exactly what it is: current stock divided by the units removed in the trailing 7 days, capped at 52 weeks. Three consequences follow, and all three matter.
Pick a cover band per class rather than a single number: enough days to cover lead time plus your review period plus a buffer, and a ceiling above which you stop buying. Write the ceiling down. "Plenty" has no upper limit, and that is how the dead-stock pile further down this page gets fed.
The retail definition is units sold in a period divided by units received in that period. Receive 1,200 and sell 900 in the same month and you are at 75% — a buying metric that asks whether the last order was the right size. A run near 100% usually means you under-bought; a run in the thirties means the order was a mistake you are now storing.
Sell-through % (retail definition) = (units sold ÷ units received) × 100
Sell Through chart = units removed in trailing 7 days ÷ (current stock + those units) × 100
The chart in Stockout carries the same word and computes something else. Its denominator is current stock plus the units removed, not what you received, and it moves as stock moves. On the running item: 126 ÷ (540 + 126) = 126 ÷ 666 = 18.9%. The same denominator caveat as Weeks Cover applies — every negative movement feeds it, so a day of count corrections, a batch of kit builds or a work order pulling materials all raise the figure with nothing sold.
Do not convert one into the other, and name which one you mean whenever you report it, with the formula beside the number. At the item level, a low retail sell-through on a recently received line is an argument for cutting the next order quantity, not for discounting immediately — and check cover first, because 40% sell-through on an item with 90 days of cover and 40% on one with 12 days are different problems with different fixes. The obvious way to game it: stop receiving. A month with no purchases reads beautifully and starves the next one.
Stockout rate (time basis) = SKU-days out of stock ÷ (SKUs stocked × days in period) × 100
Stockout rate (demand basis) = lines that could not be filled ÷ lines requested × 100
Both are defensible and they answer different questions. The time basis measures exposure and needs no order data at all. The demand basis measures what a customer or a job actually felt. Run one. Run both only if you are prepared to explain the gap between them every month.
Capturing SKU-days without a report screen takes one of two routes, because Stockout has no stockout-rate report and no per-item history screen. Either tally the Out tile on the Inventory screen at a fixed time each day — tapping it filters the list to everything out of stock, so on 600 SKUs it is a minute's work, not a count — or reconstruct the zero-quantity days from the movement ledger pulled through the read-only API. Out of Stock alerts help with the first, but only partly: they are edge-triggered, one email at the moment of the crossing, so a filed alert gives you the start timestamp for free. They fire only for the location that device is set to, and not every crossing raises one — kit builds and work-order material use raise no alert, and in the web app only the ± Adjust path does, so an item emptied by an editor edit reaches zero silently. Treat the alerts as a partial feed and the daily tile tally as the record. Recipients are a per-device list that does not sync, so nominate one device as the system of record before you rely on that.
Measuring the rate is a thermometer; changing it is a separate job, worked through in the guide on practices that stop stockouts.
Delist the slow items that keep going out and the rate improves with no operational change whatsoever.
Counting a substitution as a fill hides a real miss. Decide in writing whether a substitute counts, before the month where it matters.
Line fill rate = lines shipped complete ÷ lines ordered × 100
Unit fill rate = units shipped ÷ units ordered × 100
Order fill rate = orders shipped complete ÷ orders × 100
Probability an n-line order is complete ≈ (line fill rate)n
That last line is the insight the metric exists for. Improving line fill by one point moves order fill by about seven and a half points on an eight-line order, which is the argument for fixing the small cheap items nobody bothers to buffer. They are the lines that break otherwise complete orders.
Which version to report depends on who is waiting: order fill if you serve customers who receive one delivery, line fill if you serve internal jobs that can start on a partial. Whichever you pick, keep the denominator fixed. Cancelled backorders quietly dropped out of the denominator is the classic way this figure drifts upward while service gets worse.
Fill rate is not a cycle service level. Fill rate is the share of demand satisfied from stock, measured after the fact; a cycle service level is the probability of not running short during one replenishment cycle. Fill rate is almost always the higher of the two, and quoting one as the other is how a 95% service-level target turns into a promise nobody made.
Set a higher internal target on your A class than on the tail, and set each one from what a miss costs rather than from a round number. If a missed line costs $400 in expedite freight and the buffer that would have prevented it costs $90 a year to carry, aim high; if the miss costs a phone call, do not. Until you have three months of your own trend, publish the figure without a target beside it. And note the easy way to fake it: split a shipment so every line eventually ships "complete" and you turn one unhappy customer into two freight charges and a perfect line fill rate.
This one comes late in the list and first in importance. Turnover, cover, stockout rate, shrink and dead stock are all computed from on-hand quantities, so an inaccurate record makes every other figure on the sheet confidently wrong. It is the only metric whose failure invalidates the others.
Count accuracy % = (lines within tolerance ÷ lines counted) × 100
Dollar accuracy % = (1 − (Σ absolute variance value ÷ total value counted)) × 100
Record accuracy asks whether a quantity can be trusted at a lookup; dollar accuracy asks whether the balance-sheet figure is close, and the two routinely diverge. Tolerance bands, blind counting, the worked line-versus-dollar comparison and what to do with a variance all live in the guide on cycle counting versus a physical count. Measure it there; report it here.
The trend sets your counting frequency. Rising accuracy on a class means you can count it less often. A class stuck flat means the count is not finding the cause, and counting it more often will not help until somebody investigates a variance properly.
None of this lives in the app. Stockout records no count, no variance and no adjustment reason — movement reasons are fixed strings the app writes itself and are never read back for reporting — so count accuracy comes off the sheet you wrote while counting.
Shrink is the value that was on the record and is not on the shelf: theft, damage, mis-picks, miscounts, unrecorded usage. It is the gap between book value and counted value, which means it only exists if you count.
Shrink rate % = ((book value at cost − counted value at cost) ÷ COGS) × 100
Alternative denominator: ÷ revenue for the period × 100 — pick one and keep it
What the split tells you is worth more than the headline. Shrink concentrated in a handful of high-value SKUs is a security and access problem. Shrink spread thinly across hundreds of cheap lines is a process problem, and it is almost always unrecorded consumption — somebody taking what they need and not saying so. Split the variance by class before you propose a fix, because the two fixes have nothing in common.
The app will not do that split for you. Stockout records no adjustment reason and no shrink, damage or miscount category, so the correction that brings a record down to the counted figure is indistinguishable from any other removal. The category has to come off the count sheet, written at the moment somebody noticed.
One arithmetic trap: never net a positive variance against a negative one before calculating shrink. Two $3,000 errors in opposite directions are not a clean shelf, they are two failures that happen to sum to zero. Sum absolute variances for the operational read and keep the net figure for the accounts. Set the investigation threshold off your own first three quarters: whatever rate you settle at, treat a move of more than a quarter of that rate as something that has to be explained in writing.
This is the multiplier that turns every other metric into money. Build it from components rather than borrowing a round number — you will lean on it in a dozen arguments and have to defend each part.
Carrying cost % = capital + storage + insurance and tax + obsolescence + handling, each as a % of average inventory value
Annual carrying cost $ = average inventory value × carrying cost %
Carrying cost per unit-year = unit cost × carrying cost %
| Component | Rate | On $330,000 average inventory |
|---|---|---|
| Cost of capital | 8.0% | $26,400 |
| Storage — space, racking, utilities | 5.0% | $16,500 |
| Insurance and tax | 1.5% | $4,950 |
| Obsolescence and write-off | 4.0% | $13,200 |
| Handling and stock admin | 2.5% | $8,250 |
| Total | 21.0% | $69,300 |
Two components get skipped and both belong in the rate. Obsolescence belongs even if you have never written anything off — that is precisely why the dead-stock pile is growing. Handling belongs because every extra unit gets moved, counted and searched for by somebody who is paid.
The rate is what makes an excess-stock argument arithmetic instead of a hunch, and it sets the bar for a discount. Cost the extra stock as carrying rate × the average quantity you will actually be holding, which for an evenly consumed buy is about half of it: a year's supply at a 21% rate costs roughly 10.5% of its value to hold, so a 5% price break loses. A quarter's extra stock costs about 2.6% to hold, so the same 5% break wins. Compare the discount to the holding cost of the buy in front of you, not to the annual rate. The rate also has an obvious failure mode — it is set by whoever wants the answer. Set it once, write down the five components, and revisit it annually rather than per decision. Use the same rate everywhere once you have built it: the reorder-point guide prices this same $40 unit at an illustrative 25%, and two rates in circulation is how two people reach opposite conclusions about the same shelf.
Dead stock is not a feeling about a shelf. Write a rule with three parts — no outward movement in N days, with N chosen per class — and apply it identically every quarter. Ninety days suits fast-moving consumables, 180 general stock, 365 spares and capital parts.
Dead stock % = (value at cost of SKUs with no outflow in N days ÷ total inventory value at cost) × 100
Annual cost of holding it = dead stock value × carrying cost %
Slow-moving flag = days of cover > target cover days
Slow-moving is the more useful category, because it is still recoverable: anything with movement but more than a target number of days of cover — 180, say — which the cover calculation above already hands you. Sort descending by days of cover and stop reading at the point where the list stops being surprising.
There is an order of preference for what to do with it. Consume it in a kit or on a work order, return it to the supplier, discount it, then write it off. Each step down that list recovers less, and the only genuinely expensive option is leaving it alone for another year at $8,064. Kits and work orders are real routes here rather than paperwork: Make on a kit deducts component stock, and using a material line on a work order deducts stock and logs a movement tagged with the work-order number.
Building the list takes work, because there is no dead-stock report, no aging report, no last-movement column on any list, and no per-item movement screen on any platform. Pull the stock-movement ledger through the read-only API, list the item ids with no negative movement since your cut-off date, and price them against the catalog. On a small catalog a manual pass works too.
"Days since last movement" resets on any movement, so a single unit issued to keep an item off the list re-ages the other 400. Measure against a fixed calendar cut-off rather than a rolling last-movement date.
Deleting an item removes it from analytics entirely, including its past movements, so writing off dead stock by deleting the records changes every historical chart point. Note the value somewhere outside the app first.
Excess units = on-hand − (target cover days × average daily usage), when positive
Excess value = excess units × unit cost · Annual cost = excess value × carrying cost %
Shortage units = reorder point − on-hand, when positive
Two one-line calculations per item, both measured against the same target cover. Take a second item at 820 on hand, same 18 units a day, same 30-day target: 30 × 18 = 540 units of target, so 820 − 540 = 280 units of excess, which is $11,200 at cost and $2,352 a year to carry at 21%.
The rule this section exists for is the summing. Add excess and shortage separately across the catalog and never subtract one from the other. $42,000 of excess sitting beside $9,800 of shortage is not "$32,200 overstocked" — it is two simultaneous problems, one costing carrying charges and one stopping jobs, and the netted figure recommends exactly the wrong action on both.
Rank by excess dollars to find cash to release, rank by shortage dollars to find what to expedite — the two lists usually name the same buyer — and act on both in the same week. Re-run it monthly; the composition turns over considerably faster than the totals do. One honest caveat: both numbers move when the target cover moves, so publish the target alongside the result or the figures are not comparable month to month. The shortage side also depends on a reorder point you worked out yourself — the per-item Low Stock At threshold is the only reorder-ish input Stockout holds, and it holds whatever you typed into it.
| Metric | Formula | The decision it changes | How often |
|---|---|---|---|
| Inventory turnover | COGS ÷ average inventory at cost | How much cash is parked in stock | Quarterly, monthly if inventory is volatile |
| Days of inventory | 365 ÷ turnover | The same, in a unit the floor understands | Quarterly |
| GMROI | gross margin $ ÷ average inventory at cost | Which categories earn their shelf space | Quarterly |
| Days of cover, per item | on-hand ÷ average daily usage | What to look at today; what you over-bought | Weekly |
| Sell-through | units sold ÷ units received | Whether the next order should be smaller | Monthly, per received line |
| Stockout rate | SKU-days out ÷ total SKU-days, or unfilled lines ÷ lines requested | Where to add buffer or tighten the process | Monthly, with the A-class rate beside it |
| Fill rate | lines, units or orders filled ÷ requested | Whether customers and jobs feel the gaps | Monthly |
| Count accuracy | lines within tolerance ÷ lines counted | How often each class needs counting | Weekly tally, monthly published |
| Dollar accuracy | 1 − (Σ absolute variance value ÷ value counted) | Whether the stock figure on the accounts is safe | Monthly |
| Shrink rate | (book value − counted value) ÷ COGS | Security problem or process problem | Quarterly, after a count cycle |
| Carrying cost % | capital + storage + insurance/tax + obsolescence + handling | Every hold-versus-buy argument you will have | Set annually, use constantly |
| Dead stock % | value with no outflow in N days ÷ total inventory value | What to consume, return, discount or write off | Quarterly |
| Excess and shortage $ | on-hand − target cover; reorder point − on-hand | What cash to release and what to expedite | Monthly |
Pick at most five of these for a monthly sheet. On most sheets they are count accuracy, stockout rate, days of cover, excess and shortage, and turnover — keep count accuracy on permanently, because it is what makes the other four believable. Record the definition next to each figure so the sheet survives the person who built it, and report every one of them as a twelve-month trend rather than a single month: each of these moves with whatever you happened to count, ship or receive in a short window, and a single reading tells you about that window rather than about the business.
The same product at two sites is two records with independent quantities, so turnover, cover, stockout rate and dead stock have to be computed per site. A rolled-up figure averages a site drowning in stock against one that keeps running out and recommends nothing useful for either. Everything else about running stock across sites is in the guide on multi-location inventory.
The app pushes the same way, and there is a trap in how it does it. Analytics is scoped to the current location, so the charts in front of you belong to one site. Two people on the same account can be looking at different sites at the same time, so check which site the screen is set to before you write a number down.
It is a read-only aggregate in the Windows and Android apps and it does not exist in the web app, so nothing can be counted, adjusted or scanned from it. Alerts fire only for the location a device is actually set to.
One figure is legitimately organization-wide: the carrying cost percentage, because capital and insurance rates do not change by building. The storage component genuinely might, though, so split that line if one site pays far more per square foot than the other.
The formatting rule that saves the most trouble later: put the site name in the row label of every KPI sheet, keep one sheet per site, and give the consolidated tab only dollar totals. Never average percentages across sites.
Consolidated turnover = Σ COGS across sites ÷ Σ average inventory across sites — never the average of the site ratios
Analytics ships exactly eight charts and there is no ninth: Total Stock Per Day, Weeks Cover, Sell Through, Intake & Outtake, Stock to Capacity, Stock at Cost vs Retail, Work Order Revenue vs Cost, and Work Order Profit. They are listed on the features page. Five of them matter for the arithmetic above.
Trend ranges are 7 Days, 30 Days or 12 Months; Intake & Outtake uses its own Day, Month or Year window; and three charts ask By Category or Per Item before they render.
Then the caveats, which matter more than the chart list if you plan to quote these figures to anyone. Trend lines are reconstructed by unwinding stock movements from today's on-hand total, so they are a back-calculation rather than stored point-in-time snapshots. Deleting an item removes it from analytics entirely, past movements included, so every historical point changes. And analytics reads at most the last 13 months of stock movements. If you need a figure to stay fixed, a month-end inventory value being the obvious one, write it down the day you take it.
Output is worth stating plainly. On the web, "Save PDF" is the browser's own print-to-PDF and needs pop-ups allowed, and emailing a chart sends a PNG. Either way the file holds the title, subtitle, total line and the rendered bars — not the numbers behind them and not a table of items. For anything you intend to compute on, the read-only API is the route.
The app holds the raw material and draws eight charts from it. The ratios stay yours.
All of this rests on quantities recorded as stock actually moved. That habit is what the rest of the guide series keeps coming back to.
Start with three. Count accuracy, because every other number is built on it. Stockout rate on the items that cost you money when they hit zero. And turnover on that same short list, so you can see what is tying up cash. Add the other two of the monthly five — days of cover, and excess and shortage — once those three have a trend you trust. Carrying cost, dead stock and shrink are worth running, but quarterly or annually rather than on the monthly sheet. A metric nobody acts on is a chore, not a KPI.
There is no universal figure, and anyone quoting one is guessing at your business. Turnover is COGS divided by average inventory value at cost — $1,980,000 ÷ $330,000 = 6.0 turns, or 365 ÷ 6.0 = 61 days of stock. What matters is your own direction of travel over four quarters, and the category split underneath the total. A blended 6.0 can easily be a fast category at 12 turns sitting beside a slow one at 1.5. Pair turnover with GMROI — gross margin dollars ÷ average inventory at cost, $1,320,000 ÷ $330,000 = $4.00 — or the metric will push you toward cheap fast-moving stock that earns nothing.
No. Stockout calculates none of the metrics in this guide and stores none of them. It ships exactly eight charts: Total Stock Per Day, Weeks Cover, Sell Through, Intake & Outtake, Stock to Capacity, Stock at Cost vs Retail, Work Order Revenue vs Cost and Work Order Profit. What it does hold is the raw material — quantity, cost price and retail price on every item, and a stock-movement ledger — so you can build the figures yourself. Stock at Cost vs Retail gives you the current inventory value most of the formulas need, and the read-only JSON API is the way to pull the movement rows in bulk for your own reporting. COGS never comes out of the app at all: it is opening inventory plus purchases minus closing inventory, taken off your supplier invoices and your counts.
Days of cover is on-hand divided by your own average daily usage, normally measured over 60 to 90 days: 540 units at 18 a day is 30 days, or 4.3 weeks. Stockout's Weeks Cover chart is current stock divided by the units removed in the trailing 7 days, capped at 52 weeks. Three differences matter. The window is seven days, so a quiet week inflates it — the same 540 units read 4.3 weeks after an average week but 13.5 weeks after a week where only 40 moved. The denominator counts every negative movement, not sales, so count corrections, kit builds and work-order material pulls all feed it. And when nothing was removed in those seven days but stock is above zero, it returns 52, which means 'nothing moved', not 'a year of cover'. It knows nothing about lead time, so it is never a reorder trigger.
Build it from five components, each expressed as a percentage of average inventory value at cost: cost of capital, storage, insurance and tax, obsolescence and write-off, and handling and stock administration. An illustrative build of 8% + 5% + 1.5% + 4% + 2.5% gives 21%, which on $330,000 of average inventory is $69,300 a year, or $8.40 a year to hold one $40 unit. Use your own figures — the point of building it from parts is that you can defend each one. Include obsolescence even if you have never written anything off, because that is precisely why the dead-stock pile grows, and include handling, because every extra unit gets moved, counted and searched for. Once you have the rate, it prices every other decision: taking the same business from 6.0 to 7.0 turns drops average inventory to $282,857, releases $47,143 of cash and saves about $9,900 a year at 21%.
Fill rate is the share of demand you satisfied from stock; a cycle service level is the probability of not running short at any point during one replenishment cycle. Fill rate is measured after the fact and is almost always the higher of the two. Fill rate also has three versions that give different answers from the same month: lines shipped complete ÷ lines ordered (3,103 ÷ 3,150 = 98.5%), units shipped ÷ units ordered (24,180 ÷ 24,600 = 98.3%), and orders shipped complete ÷ orders (612 ÷ 640 = 95.6%). Order fill is always the lowest, because an order needs every line present: if misses were independent, an eight-line order at 98.5% per line would be complete only 0.985^8 = 88.6% of the time. Pick one basis, write down whether a substitution counts as a fill, and never drop cancelled backorders out of the denominator.
Two routes. The public API is read-only JSON over HTTPS — GET and HEAD only, 24 collections including the stock-movement ledger — with keys minted by an Owner or Admin at Settings, then Developers, then API Keys; a key reads the whole organization, not one site. That is the only bulk route to movement rows, and it is how you would reconstruct stockout days or a no-movement-since list. Everything else is read off the screen: quantity and cost price on the item, current value from the Stock at Cost vs Retail chart. There is no per-item movement history screen on any platform, and analytics trends are back-calculated by unwinding movements from today's on-hand total, so any figure you want to keep — a month-end inventory value being the obvious one — gets written down the day you take it.
Stockout keeps the quantity, cost price and retail price on every item, gives each one a live status, and alerts you the moment an adjustment takes stock across a threshold.