How Supy Stops Increases Inventory Accuracy By Reducing Phantom Inventory Variance

Phantom inventory variance is a gap between your stock count and your system that no physical loss can explain. It appears whenever a recipe quantity, a production event, or a recipe's start date is entered without backdating it to the date it actually took effect. The system then re-runs months of past sales against the wrong figure, fabricating a variance that never happened on the shelf.
The same mechanism shows up in four everyday ways, and each one manufactures variance the same way:
- A recipe quantity changes but the edit is dated today instead of when it actually changed, so months of past sales keep depleting the old, smaller quantity.
- A production event is entered into the count by hand instead of run as production, so stock and value stay wrong until that event is backdated to when it really happened.
- A recipe is created after its sales were already imported, so those earlier sales link to nothing and deplete no stock at all.
- An ingredient swap is dated today rather than its true effective date, so it quietly rewrites prior months' cost history and margins.
The through-line is timing, not counting. Theoretical stock is not a number typed in once and left alone; it is derived continuously from every goods receipt and every recipe consumption event, so the instant a recipe or production record changes, the system re-runs it against all the sales it can see. Backdating tells it which window that change belongs to. Skip the backdate and you have not just changed things going forward, you have silently rewritten the past, which is why no amount of recounting will close the gap.

The scale this reaches is easy to underestimate. One multi-branch restaurant group's review turned up a roughly 54,000-unit net variance between two counts a month apart, about 71,000 units negative against 17,000 positive, yet item by item almost none of it was real loss. The count was accurate and the recipe was correct going forward. The single fault was a recipe quantity that had been changed with no effective date, so months of historical sales had only ever depleted the old, much smaller quantity. Nobody had lost 54,000 units of anything; the discrepancy lived in the timing of the change, not on the shelf.

The Fix: Backdate Every Change to Its Real Date, and Get Variance You Can Trust
The fix is not to recount or hand-adjust a number. It is to backdate each change to the date it actually took effect, so the system re-runs historical sales at the corrected figure instead of the stale one, then to lock the reconciled count so no later edit drifts it again. Correct the timing and the variance corrects itself.
In Supy that is a deliberate, repeatable workflow rather than a spreadsheet rescue. Find the date a change really took effect: when the quantity changed, when the production ran, when the ingredient swap started. Use Action > Backdate Recipe to set that true effective date, and Supy re-depletes historical sales at the corrected amount instead of the stale one. Because theoretical stock is kept continuously up to date from every goods receipt and recipe consumption event, that correction propagates cleanly through the whole history the change touches, which is exactly why backdating fixes it and a manual number tweak cannot. Once the figures reconcile, lock the stock count so no edit drifts it while finance signs off.

The impact is that variance starts meaning something again. Instead of teams burning days recounting shelves to chase a loss that never happened, the number on the report reflects what physically moved. Margins and closing stock value stop swinging on data-entry timing, investigations get shorter, and a locked, reconciled count is something finance can actually sign off. That is the difference between an inventory system that merely records numbers and one whose theoretical stock is trustworthy enough to run the business on.
Before you write off your next big variance as loss, run three quick checks: did any recipe change in the period without an effective date; were any production events keyed in by hand instead of run as production; was any recipe created after its sales were already imported? If the answer to any of them is yes, the variance is almost certainly fabricated by timing, and backdating, not recounting, is the fix. See how Supy's recipe management and inventory management keep theoretical stock honest, and our guide to stocktake failure modes across multi-site groups covers the other timing traps that distort a count.


.jpg)

