F&B operations glossary

Food cost percentage

Food cost percentage is the portion of revenue spent on the ingredients sold to guests over a given period. It is the single most-watched cost metric in restaurant operations because it compresses purchasing discipline, recipe accuracy, portion control, and waste into one number. In Dubai full-service F&B, healthy targets typically sit between 28% and 35% — fine dining and steak concepts run higher, high-volume casual and bakery concepts run lower. Tracked weekly, it warns you about recipe drift and supplier price moves long before the P&L confirms them.

Food cost % = (COGS ÷ Net revenue) × 100

Worked example: an outlet sells AED 500,000 of food (net of 5% VAT) in a month and records AED 160,000 of food COGS. Food cost = (160,000 ÷ 500,000) × 100 = 32.0%. If the budget target was 30%, the 2-point gap equals AED 10,000 of margin to recover — usually through tighter par levels, recipe enforcement, and waste reduction.

Related: How it works — cost engine · Product: Inventory

Theoretical food cost

Theoretical food cost is what your food cost should have been if every recipe was followed to the gram and nothing was wasted, miscounted, or stolen. It is calculated by multiplying each item sold through the POS by the unit cost of its recipe, summed across the period. Theoretical cost is the projection the system owes the operator: it isolates recipe and pricing variables from operational ones, so when actual cost diverges you know whether the gap is a kitchen issue or a recipe/menu issue.

Theoretical food cost = Σ (POS qty × recipe unit cost)

Worked example: a steak dish sells 600 covers at a recipe cost of AED 38.40, and a salad sells 900 covers at a recipe cost of AED 9.20. Theoretical cost for these two items = (600 × 38.40) + (900 × 9.20) = AED 23,040 + AED 8,280 = AED 31,320. Add the same calculation for every menu item and you have the period's theoretical food cost.

Related: How it works — recipes & POS

Actual food cost

Actual food cost is the cost the period really consumed — what came in, what stayed, and what is no longer on the shelf. It is reconciled at period close from the stock ledger, not estimated from purchases. In a system like EYP Ops, where every movement (invoice, transfer, waste, staff meal, recipe deduction) writes a ledger entry with its own unit cost, actual food cost is simply the sum of OUT moves valued at post-time cost over the period.

Actual food cost = Opening stock + Purchases − Closing stock

Worked example: opening stock AED 80,000, purchases AED 175,000 (net of VAT), closing stock AED 88,000. Actual food cost = 80,000 + 175,000 − 88,000 = AED 167,000. Compare with theoretical food cost for the same period to surface the variance, then drill into the moves that caused it.

Related: How it works — period close · Product: Inventory

Variance (theoretical vs actual)

Variance is the gap between actual food cost and theoretical food cost. It is expressed in AED, in percentage of revenue, or in percentage of theoretical — pick one and stay consistent. Variance is where management lives: a clean variance report ranks each ingredient by gap and lets the operator chase the largest offenders first instead of scrubbing the entire menu.

Variance = Actual food cost − Theoretical food cost

Common drivers: over-portioning at the pass, recipe cards drifting from the kitchen practice, unrecorded waste, untracked staff meals, supplier price changes the recipe still reflects at old cost, theft, and miscounting at period close. A variance under 1% of revenue is excellent; over 3% is an immediate operational review. Worked example: actual AED 167,000 vs theoretical AED 158,000 = AED 9,000 variance, or 1.8% on AED 500,000 of revenue.

Related: How it works — variance reporting

COGS (Cost of Goods Sold)

COGS — Cost of Goods Sold — is the accounting term for the cost of the inventory consumed to generate the period's revenue. On a restaurant P&L it is the primary cost line above gross profit and typically splits into food COGS and beverage COGS. COGS is calculated either from the inventory identity (opening + purchases − closing) or, in a ledger-based system, by summing the cost of OUT moves (recipe, waste, staff meal, supplier returns) at their post-time unit cost. Both methods must reconcile.

COGS = Opening + Purchases − Closing

Worked example: a casual dining outlet records food COGS of AED 167,000 and beverage COGS of AED 32,000 in March against revenue of AED 620,000. Total COGS = AED 199,000, leaving gross profit of AED 421,000 (67.9%). EYP Ops always reads COGS from posted ledger moves — never recomputed at report time — so the number on the P&L matches the number on the variance report to the cent.

Related: Product: Finance · How it works

Par level

The par level for an item is the minimum quantity that must be on hand at the start of a service period for the kitchen to operate without a stockout, plus a small safety buffer. It is the foundation of disciplined ordering: instead of guessing, the buyer compares current stock to par and orders the difference. A correct par cuts both stockouts and over-stock at the same time.

Par level = (daily avg consumption × lead time in days) + safety stock

Worked example: a restaurant uses 12 kg of chicken breast per day on average, the supplier delivers in 2 days, and the buyer holds a 1-day safety buffer. Par = (12 × 2) + 12 = 36 kg. If the count shows 14 kg on hand, the order is 22 kg. Pars are recalibrated whenever the menu mix shifts or a supplier's lead time changes.

Related: Product: Orders

Recipe yield

Recipe yield is the usable fraction of an ingredient after preparation: trimming, cooking, peeling, butchering, or reducing. It is the difference between purchase weight (as-purchased, AP) and edible weight (edible-portion, EP). A recipe that ignores yield understates true cost and produces theoretical numbers that never reconcile with actuals. Yield is typically expressed as a percentage and must be measured per ingredient under your own kitchen's conditions, not borrowed from a textbook.

Yield % = (Edible weight ÷ As-purchased weight) × 100

Worked example: a kitchen receives 1.0 kg of raw whole chicken at AED 22.00/kg. After breaking down and cooking, 0.6 kg of edible portion remains. Yield = 60%. True EP cost = 22.00 ÷ 0.60 = AED 36.67/kg. The recipe must use 36.67/kg, not the 22.00/kg invoice price, or it will under-cost every dish that uses cooked chicken.

Related: How it works — recipes

FIFO (First In First Out)

FIFO — First In First Out — is the rule that the oldest stock on hand is the next to be consumed. Operationally it is a kitchen and warehouse discipline: rotate shelves so the oldest batch is in front. Financially it is a costing method: each OUT move is valued at the unit cost of the oldest remaining IN batch. FIFO is the right default for fresh and short-shelf-life products (produce, dairy, fresh proteins) because it matches the physical reality of the kitchen and minimises spoilage.

Worked example: a kitchen receives 10 kg tomato at AED 8/kg on Monday and another 10 kg at AED 9/kg on Wednesday. On Friday the recipes consume 12 kg. Under FIFO, the first 10 kg is valued at AED 8 (= AED 80) and the next 2 kg at AED 9 (= AED 18), for a total OUT cost of AED 98. Closing stock is 8 kg at AED 9 = AED 72.

Related: How it works — costing methods

WAC (Weighted Average Cost)

WAC — Weighted Average Cost — values OUT moves at the weighted average of all available IN batches. After every IN move, the running average is recomputed; every subsequent OUT uses that single blended cost until the next IN. WAC smooths price volatility and is the right default for stable, non-perishable products (dry goods, oils, packaging) where batch traceability is not required and small recipe-level cost swings would be operational noise rather than signal.

WAC = (qty1 × cost1 + qty2 × cost2) ÷ (qty1 + qty2)

Worked example: 50 kg flour at AED 4.00/kg followed by 50 kg at AED 5.00/kg gives a blended unit cost of (50 × 4 + 50 × 5) ÷ 100 = AED 4.50/kg. A subsequent OUT of 30 kg is valued at 30 × 4.50 = AED 135. EYP Ops persists this unit cost on the StockMove at post time so it never drifts later.

Related: How it works — costing methods

Mark-to-market (anti-pattern)

Mark-to-market is the practice of revaluing historical inventory movements at today's price each time a report runs. It seems convenient — “just use the current cost” — but it silently rewrites prior periods every time a new invoice posts. Last month's COGS, gross margin, and food cost percentage all shift after the books were closed. Auditors lose the trail and managers stop trusting the numbers, because the same date never returns the same value twice.

EYP Ops does not mark-to-market. Every StockMove is written with its unit cost at post time and that cost never changes. RECIPE_OUT, PRODUCTION_OUT, WASTE_OUT, STAFF_MEAL_OUT, and BUTCHER moves all persist their post-time cost; reports read the persisted value and never recompute. If a historical cost view is needed, it is built as a separate snapshot model — never by mutating the ledger. This is a hard architectural invariant in our codebase, deliberately preserved after migrating from a system that did silently mark-to-market.

Related: Trust — append-only ledger

3-way match

A 3-way match is the financial control that matches three documents before a supplier invoice is approved for payment: the Purchase Order (what was ordered), the Goods Receipt (what was actually delivered, in agreed condition), and the Supplier Invoice (what the supplier billed). When all three agree on quantity and price within tolerance, the invoice posts and pays normally. If any of the three disagrees — short delivery, wrong price, missing line — the invoice is held for investigation rather than being silently overpaid.

Worked example: an order is raised for 50 kg beef ribeye at AED 90/kg (PO total AED 4,500). The receiver weighs 48 kg in (GRN AED 4,320). The supplier's invoice arrives at 50 kg × AED 92/kg = AED 4,600. The 3-way match flags both a quantity gap (2 kg short) and a price gap (+AED 2/kg). The invoice is held until the supplier issues a credit note or the discrepancy is resolved.

Related: Product: Orders

Ledger (append-only stock ledger)

An append-only stock ledger is a single chronological record of every stock movement — IN, OUT, transfer, adjustment — where rows can be added but never updated or deleted. Corrections are made by posting a reversing entry, not by editing the original row. This guarantees that the ledger always reproduces the same number for the same date, that an auditor can trace any closing balance back to the source documents, and that no manager can “tidy” last month's books after the fact.

In EYP Ops, the StockMove table is the ledger. Every transaction (purchase invoice, recipe deduction, transfer, wastage, staff meal, supplier return, production, butcher, opening, adjustment) writes one or more StockMove rows with a persisted unit cost. The database enforces append-only at the application layer and at the role/audit layer. Reports read the ledger as the single source of truth.

Related: Trust — append-only ledger · How it works

Period close

Period close is the moment a reporting period (typically a calendar month) is locked: closing stock counts are signed off, snapshots are written, and the numbers for that period become canonical. After close, the period's opening and closing stock, COGS, variance, and food cost percentage are fixed. Any later correction is visible: the period must be unlocked, the change is recorded against an actor in the audit log, and a new snapshot is computed.

In EYP Ops, period close writes a count-aware snapshot per location and item (StockPeriodSnapshot) and prevents the next period from opening until the previous one is locked. Reports for closed periods read snapshot-only — they never recompute from raw ledger sums — so the closing number on March's P&L matches the opening number on April's, always.

Related: How it works — period close · Trust — period lock

Opening count

An opening count is the bootstrap inventory count that establishes the starting quantity and value of stock for the very first period — the moment a new outlet starts using the system. Unlike regular periodic counts (which act as a reset point but do not write ledger movements), the opening count writes one OPENING_IN StockMove per item per location at a unit cost set by the operator. From that moment on, every subsequent change to stock is captured by a real ledger move.

Worked example: a new outlet opens on 1 March 2026. The team counts 22 kg flour at AED 4.30/kg in the Kitchen location. EYP Ops posts an OPENING_IN move with effectiveAt = period start − 1h UTC, qty 22, unitCost 4.30. The variance report for March will use this as opening stock; the closing snapshot at end-of-March will become April's opening, with no manual carry-over.

Related: How it works — onboarding

Butcher yield

Butcher yield is recipe yield applied at the protein-breakdown station: a primal cut comes in as one item and is broken down into multiple sub-cuts plus trim and waste. Each sub-cut has its own yield percentage and effective unit cost. Without a butcher posting, the chef sees one expensive ingredient where the kitchen actually uses several distinct ones, and recipe costs for premium cuts are wildly wrong.

Worked example: 1.0 kg whole chicken in at AED 22.00 (AED 22.00 total). After butchering: 0.40 kg breast (40%), 0.30 kg thigh (30%), 0.15 kg wing (15%), 0.15 kg trim/loss (15%). The breast carries a higher allocated cost per kg than the wing because it commands menu premium; weights and prices are set on the butcher document and posted as a BUTCHER_OUT for the whole chicken plus BUTCHER_IN moves for each sub-cut. Total IN cost equals total OUT cost — yield is reflected in the kg, not invented in the AED.

Related: Product: Inventory

Supplier ledger / AP aging

The supplier ledger is the per-supplier running balance of invoices, supplier returns, and payments. AP aging — Accounts Payable aging — is the same balance sliced by how long each open invoice has been outstanding, typically into 0–30, 31–60, 61–90, and 90+ day buckets. Aging is the cash-flow tool of the finance team: it tells you which suppliers will stop deliveries first if cash tightens, and which credit lines you are quietly relying on.

Worked example: Supplier A balance is AED 42,000 — of which AED 28,000 is in 0–30 days (current), AED 10,000 in 31–60 days, AED 4,000 in 61–90 days, and AED 0 in 90+ days. The ops team prioritises clearing the 31–60 bucket before it ages further. Each row in the supplier ledger links back to its source document (invoice, return, payment) so the balance is auditable to the cent.

Related: Product: Finance

Staff meal accounting

Staff meal is the food consumed by employees during shifts. It is a real cost — the ingredients leave the kitchen — and ignoring it inflates variance because OUT moves go untracked. The right pattern is to post a STAFF_MEAL_OUT move at the moment the meal is served. This keeps the stock ledger accurate and isolates staff meal as a separate cost category, distinct from food COGS sold to guests, which the finance team can report and (where applicable) treat as a payroll fringe benefit.

Worked example: a Dubai restaurant serves staff meal nightly using a fixed recipe that costs AED 4.20 per cover. With 20 staff per night across a 30-day month, that is 600 staff covers × AED 4.20 = AED 2,520 of staff meal cost. Posted as STAFF_MEAL_OUT moves, this AED 2,520 is excluded from food COGS attributed to guest revenue and reported separately on the P&L.

Related: Product: Inventory

Transfer cost (intra-outlet vs inter-outlet)

Transfers move stock from one location to another. Intra-outlet transfers (Kitchen → Bar inside the same outlet) are cost-neutral at the outlet level: the outlet's total stock value is unchanged, and food cost should not move. EYP Ops models variance and COGS at the outlet level for exactly this reason — per-location negative balances are normal during service and are not an error. Inter-outlet transfers (Outlet A → Outlet B) are different: stock and cost leave one outlet's P&L and join another's, so each outlet's variance, COGS, and food cost percentage shift accordingly.

Worked example: 5 kg of chicken at AED 36.67/kg moves from Kitchen to Bar inside Outlet A. TRANSFER_OUT (Kitchen) and TRANSFER_IN (Bar) are written, both at AED 183.35. Outlet A's P&L is unchanged. If instead the same 5 kg moved from Outlet A's Kitchen to Outlet B's Kitchen, Outlet A's closing stock drops by AED 183.35 and Outlet B's rises by the same amount.

Related: Product: Inventory

UAE FTA-compliant VAT

UAE VAT — administered by the FTA (UAE Federal Tax Authority) — is charged at 5% on most F&B supplies in the UAE. For a registered restaurant, the supplier invoice carries the supplier's TRN (Tax Registration Number) and a 5% VAT line; the buyer recovers that VAT as input tax against the VAT collected on guest sales. To stay compliant, the operator must validate the supplier's TRN, keep tax invoices on file, and report inventory and cost on a net (VAT-exclusive) basis.

Worked example: a supplier invoice shows AED 1,000 net + AED 50 VAT (5%) = AED 1,050 gross. EYP Ops stores the unit cost net of VAT (AED 1,000 ÷ qty), so food cost percentage and variance reports are computed on net values. Recoverable input VAT (AED 50) is tracked separately for the tax return. Items priced VAT-inclusive on the menu are decomposed at posting time so neither side of the P&L double-counts the tax.

Related: Product: Finance

Supplier licensing (DED)

Supplier licensing is the practice of checking that a Dubai supplier can legally sell the products it invoices. For F&B, the usual diligence pack is trade license, TRN, bank account letter, delivery contact, and product category fit. A restaurant does not need to become a regulator, but finance should not onboard a supplier whose legal name, bank beneficiary, and invoice name disagree without explanation.

Worked example: a produce vendor invoices AED 18,000/month. Before first payment, the buyer stores the license number, TRN, payment terms, and bank beneficiary in the supplier master. EYP Ops keeps that reference next to invoices and supplier ledger rows so AP review is operationally traceable.

Khaleeji supplier patterns

Khaleeji supplier patterns describe the GCC operating reality where WhatsApp orders, same-day substitutions, mixed Arabic-English invoices, driver-delivered statements, and relationship-based credit terms coexist with formal accounting requirements. Software has to support the paper trail without pretending the market is fully EDI-driven.

Example: the chef confirms tomato substitution on WhatsApp, the receiving team weighs the delivery, and AP later receives a PDF invoice with a different item label. The system must preserve all three signals and reconcile by item, quantity, price, and supplier, not only by invoice total.

DIFC vs onshore entity

DIFC and Dubai onshore entities operate under different legal and regulatory frameworks. Most restaurant operating companies are onshore entities licensed for hospitality activity, while holding, advisory, or investment structures may sit elsewhere. For EYP Ops, the operational impact is entity separation: outlets, invoices, VAT reporting, and supplier balances should be scoped to the legal company that owns the restaurant activity.

Example: a group may own a brand through a holding entity but purchase food through the onshore restaurant operator. The purchase invoice belongs to the onshore operator ledger, not the holding company dashboard, unless consolidation is explicitly configured.

Trade license categories

Trade license categories define what a Dubai F&B business is allowed to do: restaurant, cafe, catering, cloud kitchen, hotel F&B, foodstuff trading, or central kitchen activity. The category affects supplier onboarding, storage flows, production records, and whether an outlet behaves like a selling restaurant, a commissary, or both.

Example: a cloud kitchen and a dine-in restaurant may use the same recipe cost engine, but the cloud kitchen usually needs tighter production batch tracking and brand-level reporting, while the dine-in outlet needs cash, bank, and POS reconciliation tied to guest sales.

Recipe modifier

A recipe modifier is a guest- or staff-driven adjustment to a base recipe — extra cheese, no onion, double protein, sauce on the side. Modifiers are written on the POS check and must flow back to the recipe engine, otherwise the OUT move under-counts (extra cheese leaves no trace) or over-counts (the no-onion ticket still depletes onion). Each modifier should be linked to a delta on the recipe ingredient list, positive or negative, with its own unit cost contribution.

Worked example: a burger has a base cost of AED 14.50. The “extra cheese” modifier adds 30 g of cheddar at AED 60/kg = AED 1.80 of additional cost; the “no onion” modifier removes 20 g of onion at AED 8/kg = AED 0.16 of cost saved. A check with both modifiers posts a recipe OUT of (base) + 30 g cheddar − 20 g onion, and the theoretical food cost line for that ticket is AED 16.14. EYP Ops applies modifiers directly on the RECIPE_OUT calculation so theoretical and actual reconcile.

Related: How it works — POS & recipes