Where to find it: Insights → Inventory → Choose report → Actual vs. Theoretical
What this Report Tells You
This report answers one question: did you use more products than your sales say you should have?
Theoretical usage is what your recipes say you should have used, based on what you sold.
Actual usage is what your inventory counts say you really used.
Variance is the gap — and that gap is usually waste, over-portioning, theft, spillage, unrecorded transfers, or receiving errors.
A small variance means your recipes, counts, and portioning are in sync. A large variance is money leaving the building without a sale attached to it.
The full formula, in one place
Actual Usage = Beg. Inv. + Purchases + Prep − Waste − Transfers − End Inv.
Theoretical = Sales quantity, expanded through recipes into ingredients
Variance = Actual Usage − Theoretical
Variance % = Variance ÷ Actual Usage × 100
Actual COGS % = Total actual usage value ÷ Total revenue
Theo COGS % = Total theoretical usage value ÷ Total revenue
Total Variance = Actual COGS % − Theo COGS % (percentage points)
Getting Started with Avt Reporting in opsi
Getting Started with Avt Reporting in opsi
Before you run an AvT Report, you need two completed inventory counts. The report defaults to the date range between your two most recent completed counts, which is almost always the range you want. Dates with a completed count are highlighted in the date picker.
If you pick a start or end date that has no count on it, opsi estimates that inventory level instead of using a real number. You'll see a ⚠️ warning next to the date range telling you which end is estimated:
"Your selected start date does not include an inventory count. The starting inventory value will be estimated (theoretical)."
Estimated endpoints make your variance far less reliable. For a trustworthy result, always anchor both ends to a real count.
The Top Right Toggles:
Toggle | What it does |
Show $ | Off = every column is a quantity in the item's counting unit. On = every column is a dollar value. |
Include sales on initial inventory date | On (default) = sales made on the start date are counted. Turn off if you counted inventory at the end of that day rather than the start, so those sales shouldn't be attributed to the period. |
Note on quantity view: items are counted in different units (lbs, cases, each), so category header rows show -- instead of a total. Only the Show $ view rolls up to category and grand totals. Use dollars when you want totals; use quantities when you're investigating a specific item.
Summary Tiles
Tile | What it means | How it's calculated |
Actual COGS % | The percentage of revenue your real product usage consumed | Total actual usage value ÷ total sales revenue |
Theoretical COGS % | The percentage of revenue your recipes say it should have consumed | Total theoretical usage value ÷ total sales revenue |
Total Variance | The gap between the two, in percentage points | Actual COGS % − Theo COGS % |
Total Variance $ | The dollar value of the gap | Sum of every item's variance value |
How to read it: if Actual COGS is 32% and Theoretical is 28%, your Total Variance is 4 ppts — four cents of every revenue dollar went to a product you can't account for with a sale. Both percentages use total sales revenue for the period as the denominator.
⚠️ If any item in the report has a data warning, the Total Variance $ tile shows a caution icon:
"This value may be affected by missing, unmapped, or invalid unit conversions. Please validate any items with errors below."
Column By Column Explanation
Column By Column Explanation
Rows are grouped by item category, expandable to individual items. Each item shows its counting unit in parentheses, e.g. Ground Beef (lb).
1. Item
The item name, plus its counting unit. A ⚠️ warning triangle here means opsi hit a unit-conversion or mapping problem for this item — see Data warnings below.
2. Beg. Inv. (Beginning Inventory)
What you had on hand at the start of the period.
Source: your completed inventory count on (or nearest to) the start date
Shows -- if no count is available
In $ view: the counted quantity × its cost at count time
3. Purchases
Everything you received during the period.
Source: published invoices, plus spot invoices
In $ view: actual invoice spend — the real dollars you paid
4. Waste
Product logged as wasted, spoiled, or spilled.
Source: your waste log entries in the period
In $ view: waste quantity × the item's cost
Shown to 4 decimal places in quantity view, since waste is often a fraction of a unit
This is subtracted from usage — this is product that left inventory without a sale, and logging it is what keeps it out of your variance. Unlogged waste is one of the most common causes of a large positive variance.
5. Transfers
Product moved out to another one of your locations.
Source: item transfer records
In $ view: transfer quantity × the item's cost
This is subtracted from usage — it left this location but wasn't sold here
6. Prep
Product produced by prep tasks during the period.
Source: completed prep events
In $ view: prepped quantity × the item's cost
This is added to usage. It matters most for prepped/batch items — if you made 20 lbs of sauce, that sauce entered inventory without a purchase invoice
7. End Inv. (Ending Inventory)
What you had on hand at the end of the period.
Source: your completed inventory count on (or nearest to) the end date
Shows -- if no count is available
In $ view: the counted quantity × its cost at count time
8. Usage — this is your "Actual"
What your inventory counts prove you actually consumed.
Usage = Beginning Inventory
+ Purchases
+ Prep
− Waste
− Transfers
− Ending Inventory
This is a pure inventory calculation — it makes no reference to sales or recipes. If you started with 100 lbs, bought 50, wasted 5, and ended with 20, your actual usage is 125 lbs, regardless of what you sold.
In $ view: purchases are valued at real invoice spend; all other movements are valued at the item's cost from your ending count (falling back to the starting count if there's no ending count).
9. Sales — this is your "Theoretical"
What your recipes say you should have used, given what you sold.
Source: POS sales for the period, run through your recipe definitions and POS mappings
Every sale of a menu item is decomposed into its ingredients — including nested sub-recipes and modifiers — and the ingredient quantities are added up
In $ view: the cost value of that theoretical usage
This column depends entirely on two things being correct: your POS items must be mapped to recipes, and your recipes must have accurate quantities and units. If a menu item isn't mapped, its ingredient usage never appears here — which inflates your variance.
10. Variance — the answer
Variance = Usage (Actual) − Sales (Theoretical)
In quantity view it also shows a percentage:
Variance % = Variance ÷ Usage × 100
Reading the sign:
Positive + (used more than sold) = Product loss
Typical causes are unlogged waste, over-portioning, spillage, theft, unrecorded transfers, receiving short but invoiced fullNear zero = Healthy
Recipes, counts, and portioning agreeNegative - (used less than sold) = Usually a data problem
Usually a miscount, under-portioning, recipe overstates quantities, wrong unit conversion, double-counted purchases, etc. Not a windfall.
The table sorts by Variance ascending by default, so the largest negatives appear first — click the Variance header to flip it and surface your biggest losses.
Data Warnings
Data Warnings
A ⚠️ warning triangle next to an item name means opsi couldn't complete a calculation cleanly. Hover it to see the specific issues. The common ones:
Warning | What it means | How to fix |
"Missing count unit" | The item has no inventory counting unit set | Set the item's inventory unit |
"X cannot convert to Y" | No conversion path between a recipe unit and the counting unit | Add the missing unit conversion on the item |
"POS mapping cannot convert to Y" | The item sells through a POS mapping whose unit can't be converted | Fix the unit conversion, or the POS mapping |
"Y needs to be validated for [vendor item]" | A vendor item's pack size hasn't been confirmed | Review and confirm that vendor item's pack size |
Items with warnings still appear in the report, but their variance is unreliable. Clear the warnings first, then re-read the numbers — otherwise you'll chase a variance that's really a conversion bug.
Good to Know
Good to Know
Items in multiple categories are split proportionally. If an item is categorized 60% Food / 40% Beverage, 60% of its numbers land in the Food row and 40% in Beverage. Totals stay correct.
Hidden categories are excluded. Any category marked as hidden for reporting won't appear here.
Items with no activity are omitted. An item only appears if it had a count, a sale, or usage in the period.
Costs come from your counts, not averages. Purchases use real invoice spend. Everything else (waste, transfers, prep, beginning/ending value) is valued using the item's cost at your ending count, falling back to the starting count. If neither exists, those movements value at zero.
One adjustment isn't shown as a column. Product shipped out is also subtracted from actual usage but has no dedicated column, so it's folded into the Usage figure. If an item's Usage looks lower than the visible columns explain, check whether it had shipments in the period.
Suggested Workflow
Suggested Workflow
Complete an inventory count at the start and end of the period you want to measure.
Open the report — the date range should already snap to your last two counts.
Check for the ⚠️ next to the date range. If either endpoint is estimated, pick dates that have real counts.
Clear item warnings first. Fix conversions and mappings before interpreting variance.
Read the Total Variance tile for the headline, then switch to Show $ and sort by Variance to find your costliest items.
Drill into the worst offenders in quantity view — the raw units usually make the cause obvious.
Work the usual suspects in order: unlogged waste → portioning → unmapped POS items → recipe accuracy → receiving accuracy.