ERP for Restaurant and F&B Groups in the UAE: Central Kitchen, Recipes and Multi-Outlet POS
A restaurant group does not have a margin problem. It has a hundred small ones: a recipe that drifted, an outlet over-ordering, an aggregator commission nobody reconciled, a transfer from the central kitchen that was never booked. The ERP's job is to make each one visible before it reaches the month-end P&L.
Restaurant groups in the UAE grow fast and in several directions at once: more outlets, more brands, cloud kitchens, aggregator channels and a central kitchen to keep quality consistent. The POS usually keeps up. The systems around it rarely do. Purchasing lives in supplier WhatsApp groups, recipes in a chef's notebook, stock in a weekly count sheet and finance in an accounting package that sees a single daily sales figure per outlet.
The result is a business that knows its revenue to the dirham and its food cost to within a few percentage points, which in a sector with thin margins is the difference between profit and loss. This guide covers how an ERP should be designed for a multi-outlet F&B group in the UAE, where the POS fits, and what to get right first.
Key takeaways
- Recipes are bills of materials. Every menu item needs one with yields, and ingredient costs must update from purchases.
- The central kitchen is a production site with its own stock, production orders and transfers to outlets at an agreed cost.
- POS sales should consume ingredient stock automatically so theoretical versus actual usage is a daily report, not a monthly guess.
- Aggregator channels need their own sales channel, commission and payout reconciliation.
- Outlet replenishment from the central kitchen and from suppliers should run on par levels, not on a chef's phone call.
Where the POS stops and the ERP starts
A good POS is excellent at taking orders, splitting bills, running the kitchen display and closing the day. It is not designed to cost a recipe, plan central kitchen production, manage supplier purchasing across ten outlets or produce a consolidated P&L. Those jobs belong in the ERP, with the POS either part of the same platform or integrated so each outlet's sales, by item and by payment method, land in the ERP automatically every day.
The integration point is the item. If the POS menu item and the ERP product are the same record with the same recipe behind it, everything downstream works. If they are maintained separately, the mapping breaks within weeks and food cost reporting stops being trusted.
Recipes, yields and theoretical food cost
Every menu item needs a recipe: a bill of materials listing ingredients, quantities and preparation yields, including sub-recipes such as sauces and marinades made in batches. Ingredient costs should update from the latest purchase price or a moving average, so the theoretical cost of every dish is always current. This is where most groups find their first surprise: a dish priced two years ago on ingredient costs that have since moved, or a portion that has quietly grown.
| Recipe element | Why it matters |
|---|---|
| Ingredient quantity in purchase and usage units | Buy in cartons and kilograms, use in grams and pieces, without manual conversion |
| Yield and trim loss | A kilogram of fish is not a kilogram of fillet; cost the usable portion |
| Sub-recipes | Batch-made components costed once and consumed by many dishes |
| Modifiers and extras | Add-ons and substitutions consume the right stock and carry the right price |
| Target food cost percentage | Flags dishes that have drifted above the group's margin rule |
Menu engineering follows naturally. With sales volume and margin by item from the POS and the recipes, the group can see which dishes are popular and profitable, which are popular and unprofitable, and which should leave the menu.
The central kitchen as a production site
A central kitchen is a factory. It holds raw material stock, runs production orders for sauces, doughs, marinades, portioned proteins and finished items, and transfers the output to outlets. In the ERP it should be a separate warehouse with manufacturing orders based on the sub-recipes, production planned from outlet demand, and transfers to outlets booked at a transfer price so each outlet's food cost reflects what it actually received.
Shelf life matters here too. Production lots with expiry dates, first-expired-first-out picking for the outlet deliveries, and a record of what was discarded at the central kitchen all feed the waste figure. Where the central kitchen also sells to third parties, for example to a catering client or a sister brand, it becomes its own profit centre with sales invoices, and the ERP must separate the two flows.
Outlet replenishment and purchasing
Each outlet is a stock location with par levels by ingredient. Replenishment requests to the central kitchen and purchase orders to suppliers should be generated from par levels and expected sales, approved by the operations manager, and received at the outlet by scanning or quantity confirmation. Supplier invoices are matched to purchase orders and receipts, which removes the common problem of paying for cartons that never arrived.
Centralised purchasing across outlets gives the group buying power with suppliers and a single view of price movements. Supplier contracts with agreed prices for the quarter should be loaded as price lists, so a supplier invoice above the agreed price is flagged automatically.
Actual versus theoretical: the daily control
When POS sales consume ingredients through the recipes, the system knows what should have been used. A periodic count at each outlet, weekly for high-value items and monthly for the rest, gives what was actually used. The difference is waste, over-portioning, theft or a wrong recipe, and the report by outlet and by ingredient points to which. Groups that run this discipline typically find their largest variances in a handful of high-cost ingredients, and fixing those is where the margin returns.
Multi-outlet POS, payments and aggregators
Each outlet runs its own POS configuration with the brand menu, pricing and payment methods, and closes the day with a session that posts to the ERP by item and by payment type. Card settlements are reconciled against acquirer statements, and cash against the bank deposit. Discounts, voids and complimentary items are recorded by user, which is both a control and a training signal.
Aggregator orders from Talabat, Deliveroo, Noon and others are a channel in their own right. Each has a commission rate, promotional funding and a payout cycle, and the net amount received rarely matches gross sales minus a single percentage. Record aggregator sales by channel, book the commission as a cost against the channel and reconcile each payout against the platform statement. Where the aggregators are integrated into the POS, orders flow in once and the ERP receives clean channel data. Dine-in, delivery and takeaway margins by outlet then become visible, which often changes how a group thinks about its channel mix.
VAT, labour and the month end
Menu prices in the UAE are VAT-inclusive at 5 percent, so the POS has to back out the tax correctly on every sale, including on discounted items and aggregator orders where the platform's own treatment needs to be understood. Service charges and tourism fees, where they apply, are separate lines with their own treatment. The ERP produces the VAT return from the posted transactions rather than from a spreadsheet of daily totals.
Labour is the other major cost. Staff schedules, attendance and payroll through WPS can run in the same system or integrate with it, and labour cost by outlet alongside food cost gives the operations manager a complete picture of each outlet's prime cost. Month end then becomes a review of exceptions, not a reconstruction.
Implementation sequence
- Product and ingredient master: one item list shared by POS and ERP, with units of measure settled.
- Recipes and sub-recipes, costed, with target food cost by brand.
- Central kitchen as a production site with transfer pricing to outlets.
- Outlet stock locations, par levels and replenishment flow.
- POS configuration or integration, by outlet and brand, with daily posting to the ERP.
- Aggregator channels, payment reconciliation, VAT and consolidated reporting.
How Kaido approaches it
We begin with the food cost report the group wishes it had, and work backwards to the data that would produce it. That means the recipe and item master come first, before anything is configured, because they are the foundation of every report that follows. We then pilot the full flow, purchasing to central kitchen to outlet to POS to month end, on one outlet and one brand before rolling out, so the operations team learns the system on a scale they can manage.
Most groups of this size we implement on Odoo, which combines POS, manufacturing for the central kitchen, inventory, purchasing and accounting in one platform, with aggregator and payment integrations scoped per group. Where a group is committed to an existing POS, we integrate rather than replace it. In both cases the rollout is paced by the outlets' ability to count stock and receive deliveries in the system, because that is what makes the actual-versus-theoretical report truthful.
Running outlets on a POS, the kitchen on spreadsheets and finance on something else?
Talk to a senior consultant about recipes, central kitchen, outlet stock and multi-outlet POS in one system. We will start from your food cost report, not from a module list.
Book a discovery call →