F&B Cost Control: Recipe Cards, Portions & Menu Engineering
The menu is a price list for recipes nobody costed — recipe cards, portion discipline, waste as a transaction, and menu engineering: the four habits that hold food cost where the budget says.
Most Kenyan restaurants price by market: the burger costs what the competitor's burger costs, plus or minus ambition. What almost nobody knows is what the burger costs to make — this week, at this supplier's prices, at the portions the kitchen actually serves. Without that number, "food cost control" is a monthly autopsy. With it, every dish on the menu is a small business whose profit you can read.
Habit 1: recipe cards with live costs
- Every menu item gets a recipe card: ingredients, exact quantities, yield — the BOM discipline, plated.
- Ingredient costs update from purchasing automatically — when tomatoes double in the rains, every recipe using them re-costs itself the same day.
- The output is a live margin per dish: recipe cost vs menu price, ranked. The ranking is where every pricing and menu decision starts.
- Prep items (stocks, sauces, marinades) are sub-recipes — costed once, consumed by the dishes that use them.
Habit 2: portion discipline
The recipe card says 180g of beef; the ladle says whatever the cook's mood says. Portion drift of 10–15% is invisible on the plate and lethal on the month:
- Portioning tools where they matter — scoops, ladles, scales at the protein station — cost a few thousand shillings and repay weekly.
- Spot-weigh plated dishes against cards twice a week, publicly and blamelessly; measurement itself corrects most drift.
- Pre-portion the expensive proteins at prep time (butchered, weighed, bagged) so service-time speed never fights portion accuracy.
- Track yield on butchering and prep: the whole chicken → portions math is a yield reconciliation the kitchen should win, not wonder about.
Habit 3: waste is a transaction
| Waste type | Hides as | Record it as |
|---|---|---|
| Spoilage (produce, dairy) | General food cost | Waste entry with item, quantity, reason — trends expose ordering errors |
| Prep waste beyond yield | The kitchen's secret | Yield variance per prep batch |
| Returned plates & comps | Lost revenue nobody logs | Void/comp reasons on the POS, reviewed weekly |
| Staff meals | A perk that eats 2–3 points | A defined staff-meal allowance, issued and costed like any outlet |
The cost of "it's just a little"
A restaurant doing KES 3M monthly at 32% food cost spends ~KES 960,000 on food. Two points of drift — portions, waste, staff meals — is KES 60,000 a month, quietly. That is a salary, disappearing into generous ladles and unlogged spoilage.
Habit 4: menu engineering
With live recipe costs and POS sales data, every item lands in one of four boxes — high margin/high volume (stars: protect them), high margin/low volume (puzzles: promote or reposition), low margin/high volume (workhorses: re-cost, re-portion, or re-price), low margin/low volume (dogs: cut them). Reviewing the grid quarterly is how menus earn more without a single price increase the customer notices — portion architecture, plate composition, and placement do the work.
All four habits assume the plumbing underneath: store-to-kitchen issues, daily counts, a POS that consumes recipes, and purchasing that tracks ingredient prices. The bar runs the same play with tighter tolerances.
What AWRA OpsHub does today
- Waste and spoilage recorded as adjustments with a reason drawn from a configured catalogue and a named user.
- Live ingredient costs — weighted average cost per item, updated as goods are received, with landed cost included.
- Stock counted per location with blind entry, so kitchen and store variance is measurable at the item level.
- Purchase price history per supplier, so ingredient cost movement is visible.
- Recipe cards as bills of materials — each dish defined by its ingredients and quantities, priced at today's ingredient costs, so a plate cost moves when the tomato price does.
- Sub-recipes built one level at a time — a stock or sauce made into stock with an assembly order, carrying the actual cost of what went in, then consumed by the dishes that use it.
- One check-out for every ingredient across a service's portions, raised from the recipe and approved like any other issue.
More we can add to your workspace
- Theoretical usage and portion variance. Expected consumption from each recipe and the period's sales, set against what the kitchen actually drew.
- A menu-engineering grid. Popularity against plate margin, ranked into the four boxes, from the recipe costs and POS sales already held.
- Yield and trim factors on a recipe, so a whole chicken or a side of beef accounts for what is lost before the plate.
- POS depletion by recipe, so a dish rung at the till takes its ingredients out without a separate check-out.
Habit 1 runs in the product: recipes priced from live ingredient costs, sub-recipes built into stock, and ingredients issued from the recipe. Habits 2 and 4 need a comparison layered on those recipes — actual against theoretical, and margin against popularity — and that layer is the one we can add. The inputs it would read are already accurate.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsCost the burger, then the menu
Live ingredient costs with [landed cost](/glossary/landed-cost) included, waste captured with a reason, and stock counted per outlet — the accurate inputs a plate cost needs.
See F&B cost control in AWRAFrequently asked questions
How many recipe cards do we need before this works?
Start with the twenty items that drive 80% of sales — costing them takes a few kitchen afternoons and covers most of the money. The long tail follows at a card or two a week. What fails is trying to cost 200 items before turning anything on. In AWRA each card is a bill of materials on the dish, so the twenty cards are twenty short lists of ingredients and quantities, and each one is priced from current ingredient costs the moment it is saved.
Ingredient prices change weekly at the market. How do cards stay current?
Purchase prices flow from receiving into ingredient costs, so the per-kilo and per-litre figures are current without anyone retyping them, and a recipe held as a bill of materials is priced from those current costs whenever you open it. What stays a person's job is the quarterly review: reading which dishes moved and deciding whether to re-portion, re-price or drop them. Prep items built into stock with an assembly order carry the cost of the batch they came from, so a sauce made last week reflects last week's prices until the next batch.
Is cutting staff meals really worth the morale cost?
Don't cut them — define them. A costed staff-meal allowance (what, when, budgeted value) is a benefit everyone understands; an undefined "kitchen eats" policy is 2–3 food-cost points with no owner and endless suspicion. Definition is the win, not deprivation.
What margin should individual dishes make?
Think in shillings and mix, not just percentages: a 60%-margin soup earning KES 180 matters less than a 45%-margin platter earning KES 520. The menu-engineering grid weighs both — margin per plate and plates per week — which is why it beats a single food-cost target applied to everything.
