Why does my inventory or report look wrong?

Inventory or a report usually looks wrong because one input is missing, doubled or set wrong: no first count, a delivery never entered, a receipt entered twice, waste nobody logged, or a wrong case size. Find your symptom below and fix the input it names. The numbers then recalculate. The math itself is rarely the cause.

Inventory or current stock looks off

Missing first count. If a product has never been counted, current stock is whatever receipts added minus waste. Without a baseline, the number is just "received minus thrown away" and is usually wrong. Bookkeeping starts from a count too: IRS Publication 538 asks you to value inventory at the beginning and end of each tax year. → Take your first inventory count.
Missing receipt. A delivery arrived but no receipt was entered. Current stock will be lower than reality. Look at Activity to confirm what was received.
Duplicate receipt. Same delivery entered twice (e.g. you forwarded the invoice AND entered it manually). Current stock will be higher than reality. Delete the duplicate from receiving history.
Record-only used on a new delivery. Stock didn't get the bump. See when to use record-only.
Waste not logged. Stock looks higher than the walk-in. Log the waste and stock catches up.
A short shipment never recorded. The invoice billed three cases, two came off the truck. Add a Short line to that receipt — see shorts, credits, and returns.
Wrong case size. Counts entered as cases-plus-loose are added up using the product's case size — if that doesn't match the supplier pack, every count is off by the ratio.

Cost or food cost looks wrong

A credit was faked as waste. This is the common one. A returned case or a supplier credit logged through Log waste gets current stock right, so nothing looks broken on the inventory side — but the money lands on spoilage. Your waste report overstates spoilage, your purchases never come down, and food cost stays high for a delivery you were credited for. Delete the waste log and re-enter it as a Credit or Return line on a receipt (shorts, credits, and returns). Symptom to look for: a waste report where Damaged is a large, recurring line for products that never actually spoil.
Zero or estimated cost on a product. No receipts yet — the report is using the product's default case cost as a fallback. Add at least one real receipt to switch to weighted-average pricing.
A specific report cost differs from the product page. That's expected — the product page shows the rolling latest, reports show weighted averages over the report range. How cost is computed explains the difference.
Recipe-output cost is wrong. A recipe-output's cost is built up from its ingredients' costs, so trace it down — find the ingredient with the wrong cost first.
Menu item food cost spiked. Either an ingredient cost moved (check receipts), the recipe was edited, or a conversion failure is causing an ingredient to use the wrong unit.

Why is usage too high or too low?

Usage is off when one of its three inputs is off: the starting count, what you received, or the ending count. Usage = starting stock + received − ending stock. If usage is too high, look for:

The ending count is too low (count error, or items shifted to another storage area).
A receipt was entered twice.
The starting count was too high.

If usage is too low, the inverse — typically a missing receipt (a delivery that arrived but was never entered), an ending count that's too high, or a starting count that's too low.

Low stock or ordering looks wrong

Wrong minimum stock. Set too high and everything looks low; too low and you stock out before reordering. Tune after a few count cycles.
No supplier set. The product still appears in the order list but with no delivery date, no order-by date, and grouped under "No supplier" at the bottom.
Burn rate too short. If you set the lookback to 7 days but only counted twice in that window, the burn rate is jumpy. Use 14–30 days once you have enough history.

Variance report shows large gaps

Variance requires Standard+ tier, sales data (via Toast auto-sync or CSV upload), and correct recipes. Top causes of unexpected variance:

Missing recipe for a menu item (theoretical usage is zero for it).
POS item not mapped to a Rinvy menu item.
Unit conversion warnings — the recipe uses cups but the product has no weight↔volume conversion. Standard tables don't bridge that gap: NIST's cooking measurement equivalencies take 1 cup to 240 mL and 1 pound to 454 g, but no row turns cups into pounds. Add the conversion on the product.
A recipe that was wrong before you fixed it. A recipe edit does not change earlier days: the report uses the recipe as it was on each day. Gaps before the fix stay, so correct a wrong recipe as early as you can.
Real waste, recipe drift, or theft — which is exactly what the report is built to surface.

When you can't find the source

Open Activity and filter to the product or time range. Every count, receipt, prep, and waste log is there.
Check whether the product is the right type. Status-tracked products don't appear in cost reports; recipe outputs can't be received.
Use the product lifecycle report (Standard and up) for a one-page view of every signal for a single product.

The Activity feed with type-filter chips — All, Counts, Receipts, Prep, and Waste — above a color-coded list of count, waste, and receipt events grouped by day

Common mistakes

Editing a count to "fix" a report

Edit the underlying issue (missing receipt, wrong case size, waste log) instead. Editing counts cascades forward to current stock but doesn't tell you what was actually wrong.

Editing the product's case cost to fix a report number

Reports use weighted-average from receipts, not the product's case cost (unless there are no receipts at all). Fix the underlying receipt.

Assuming variance = theft

Variance is "theoretical usage − actual usage." That gap is shrinkage, but shrinkage includes waste, portioning error, recipe drift, miscounts, and theft — not just theft.