Undoubtedly, restaurant industry is one of the hardest to succeed. Food and labor cost can account for close to 65% -70% of sales. Food cost itself varies from 25% to 42%. A well run restaurant will typically be in a low 30’s or thereabouts, while the one’s who cross that line are slowly preparing for their own funeral.
Calculating food cost
When someone opens a restaurant, they have to plan the menu and price each dish. Apart from this, one needs to account for competition, location, rental and other fixed and variable costs. The only income is from your food sales, this needs to account for every expense and leave you with a healthy margin. Why else would you open one ? To achieve your targeted margin, you need to have a tab on your variable expenses, the fixed costs remain whether you do business or not. Now back to pricing your menu — if you don’t know what exactly is your cost price, you cannot arrive at the selling price. Unfortunately, price is dictated by ball park calculations and comparisons rather than scientific means.
Let us assume a fictitious restaurant QuikBites has set their theoretical food cost at 35% on an average for all their dishes. They don’t have recipes. They sold food worth Rs.15,00,000, purchased items worth 6,00,000 in that month. There is a closing inventory value worth Rs. 60,000. Opening inventory was Rs. 1,00,000. Many restaurants simply calculate their food cost by diving the purchase for a given period with sales, which is inaccurate. It could either be sheer ignorance or laziness to count their inventory weekly/monthly.
The calculated food cost will be 40% i.e. (6/15). There is a 5% negative variance which amounts to Rs.75,000.
i.e Expected consumption is 5,25,000 L (35%), wrongly calculated consumption is 6,00,000, actual is 6,40,000
Whereas the actual food cost is — 42.67% i.e. (1+6–0.6)/15 . This equates to variance of about Rs.1,15,000. i.e Expected consumption is 5,25,000 L (35%), wrongly calculated consumption is 6,00,000, actual is 6,40,000
For any given time period,
F.C = (Opening Stock + Purchase — Closing Stock)/Sales
Note: If there are any transfers in/out, you need to account for that in the numerator. Transfers-in gets added to your purchase, transfers-out gets subtracted. Again, transfers and stocks can be finished goods/semi-finished or raw ingredients (SKUs).
Oh, this is high, let us act on it.
Great, QuikBites identified that they have overshot their theoretical food cost by 5% (according to their simplified calculation, we can live with it for now). Now, do they need to know why Rs.75,000 was spent more and specifically where ? There isn’t any use of above exercise if you don’t want to act on it. But they are likely to act on it as its a matter of 5% of their sales. If that number even reduced by 2% (FC of 38), they would have added Rs.30,000 more to their bottomline.
The owner wants to dwell deep into what dishes or ingredients caused this difference (loss). Unfortunately for them, they won’t be able to drill further, as there are no recipes, so no deeper insight into which ingredients are leading to this loss and by how much. Most restaurateurs reach the dead end here. A quick and dirty way to do this is to pick the top selling items, put them down in an excel sheet, write down the opening, closing and purchase quantity of top ingredients (used in the best sellers), do some basic math based on recipe and sub recipes and talk to the chef about overconsumption. This is a painstaking exercise by the way and doesn’t scale with excel sheets. In fact it is extremely difficult to even compute expected consumption once you have sub recipes.
Reporting with Variance in ingredients
Variance is the amount you lost or gained in inventory for any specific period of sales, with physical stocks taken at the start and end of that period. Or simply put, the difference between theoretical and actual food cost.
A variance report is extremely insightful and gives you minute details that can lead you to better decision making, achieve consistency of preparation and control your costs. But unless you have the recipes, theoretical COGS can never be generated and variance cannot be reported. Remember the dead end ?
Another important point to note is that irrespective of overall result (positive or negative), both will co-exist at ingredient level. That is, you would have saved money on many ingredients and lost on many — leading to both negative/positive aggregates leading to a final number (which is usually negative).
The most common case is negative variance, in case of QuikBites — they overshot their expected consumption in inventory by Rs. 1.15 lakhs for that month. What could be the possible reasons for this ?
Let us take some of the contributing ingredients towards the negative variance using a sample table representation below. Numbers are items are for representational purposes only.
Expected vs actual consumption at ingredient level. Take for e.g. Butter. There is a difference of 195 kgs on expected versus actual consumption, contributing to negative variance of about INR 38,000.
Note: Expected consumption above needs to handle the yield of the ingredient. For e.g. if Onion has a yield of 90%, and if expected consumption is X, the value above is X/0.9. The opening and closing stock values are pre yield quantities, i.e raw values. Hence we need to convert recipe aggregated values to non yielded form for just comparison.
Fixing the leakage:
Great, you identified top 10, what do I do now ? How do I know which items in the menu are contributing to a particular SKU over consumption. Well, typically you will have an item used across multiple recipes, so narrowing down to a menu item isn’t that easy right ?
It will be impossible to track and solve every variance you see. So, it would suffice that you sort the table with negative variance values and pick the top 10 to solve for the week/month. Once you have a good hold over the top 10, ensure they don’t reflect again and move to next set of items with high variance.
List all menu items using the ingredient showing high variance, start with your top sellers down to every item using it, weigh the grammage (sic) of each at random intervals. This is grunt policing work, something your controller would have to do. But in general, it will be one or more of your top sellers, so you can save time narrowing down.
Take more frequent physical stock values only for these items instead of doing monthly, that way you can narrow down to the menu item quickly and arrest the leakage.
Some of the restaurants we work with do exactly what’s written above. Just that they weren’t used to doing this earlier because recipes (if present) were in excel sheets, contained SKUs that are never purchased, SKU’s purchased years or months ago but still used in recipes, yield was missing, recipes were not linked to menu items. This was something many were not used to, but we did make them see the value if they did all of this. This exercise also takes time and commitment from restaurant owner.
They track daily variance, identify top items and plug it before it is too late. By doing this, you can save a lot of money. And yes, you need to spend time getting your recipes in place, else any inventory system will be of little help. In fact I would argue you are better off with excel sheets. What you don’t know will only hurt you.
I may have made all of this look rosy, but there are some cases you need to account for while reading data.
- SKU mixing — Your recipe may have Amul butter but if you used Nandini Butter due to unavailability of Amul in any given time period, variance will show up for Amul as positive. Because it will show X as expected consumption and 0 or so as actual consumption. Likewise Nandini will show 0 as expected consumption but actual consumption will be Y, leading to negative variance. Workaround is that you add both values (Amul, Nandini) and ensure they don’t cumulatively lead to high -ve variance.
- Yield — If mutton leg has a yield of 60% but you have not entered it, it will lead to high variance. Because expected consumption will show X as opposed to X/.6.
- Unlinked menu items — All menu items need to be linked to a recipe in Eagleowl, so we can compute expected consumption based on sales. In absence of this, you will see high variances for SKUs that are part of that menu item(s).
- Party/Buffet items — We have yet to solve this. Say, as part of a menu item like Party package ABC, you give 2 mugs of beer, 1 starter, 1 main course item and a dessert. And each package will contain variations of beer, starter or dessert. Unless the sale is broken down and linked individually to a recipe (which is usually tricky and difficult), it is not possible to handle this case. So variances shown will not account for such non linkages.
In EagleOwl, we also have live tracking of inventory, where say, you sell a cup of coffee, we can show how much of each ingredient within coffee is debited live. This is to preempt and fix the problem quickly rather than wait till end of week or month to do post mortem. Will cover live inventory and related modules in next blog.