Restaurant Delivery Profitability in UAE: How to Track Aggregator Sales, Fees and Margins

Most UAE restaurant operators know their Talabat or Deliveroo revenue. They see the order totals in the aggregator app, watch the weekly remittance hit the bank, and use that as a measure of how the delivery channel is performing.

That number is not your profit. It is not even close to your profit.

Between the gross order value a customer pays and what actually remains after aggregator fees, food cost, packaging and VAT, there are several deductions most operators never calculate at the item or channel level. This guide walks through each layer — what it is, how to find the numbers, and how to combine them into a genuine picture of restaurant delivery profitability.

Why revenue is not the same as profit in food delivery

A customer places a AED 80 order on Talabat. Your dashboard shows AED 80 in sales. But you will not receive AED 80. The aggregator deducts its service fee before remitting. After that, you pay for the ingredients in those dishes, the packaging, and the VAT you owe the FTA. What remains is your contribution from that order — and it is materially lower than AED 80.

This is not unique to restaurants, but the gap is wider in food delivery than in most other industries because:

• Aggregator service fees are applied to every single order
• Food cost (COGS) is a direct per-order expense that does not scale away
• Delivery orders often skew toward lower-margin items (sides, drinks, value meals)
• Packaging adds a cost that does not exist in dine-in

Understanding delivery margins starts with separating these layers clearly.

Three channels, three margin profiles: dine-in, takeaway and delivery

Most UAE restaurants operate across at least two of these channels. Each has a different revenue and cost structure.

The key insight is that food cost is the same across all three channels — your ingredients cost what they cost regardless of how the order was placed. The difference in profitability comes from channel-specific costs on top of that.

What your aggregator sales report actually shows

Platforms like Talabat and Deliveroo provide a restaurant reporting portal where you can download sales data, typically broken down by week or month. A standard aggregator sales report will show:

• Gross order value — the total amount customers paid, including delivery charges paid by the customer
• Number of orders — total transactions in the period
• Cancellations and refunds — orders that were refunded, reducing your net total
• Service fee — the platform's charge deducted from your sales
• Net remittance — what the platform actually pays you: gross order value minus fees and refunds
• Payment date — when the remittance will be or was transferred to your account

This report is the starting point for aggregator sales reconciliation. It is not a profitability report. It shows your revenue from that platform — not what you earned after costs.

Platforms may also provide performance data such as average order value, top-selling items and customer ratings. These are useful for menu optimisation but distinct from financial reporting.

Aggregator fees and costs: what reduces your delivery margin

The fees aggregators charge vary by platform, contract tier, market and whether the platform handles delivery logistics or you do. We will not quote specific percentages here because these terms change and vary by operator agreement — your account manager or contract document is the authoritative source.

What matters for profitability analysis is understanding the categories of cost that aggregators typically apply:

• Service/commission fee — a percentage of the order value charged for using the platform's marketplace and order management
• Delivery fee handling — if the platform handles rider logistics, there may be a separate delivery cost; if you use your own riders, this is your cost
• Payment processing — card processing fees on customer payments
• Promotional costs — discounts funded by the restaurant (e.g. offers you opt into) that reduce your effective revenue per order
• Cancellation charges — some platforms charge a fee on cancelled orders or reduce remittance for high cancellation rates

Each of these reduces the net amount you receive from a delivery order. The difference between the gross order value and the net remittance is the total platform cost for that period. Dividing it by the number of orders gives you an average cost per delivery transaction — which is more useful than a percentage for daily operational decisions.

Food cost and COGS for delivery orders

Food cost — also called cost of goods sold (COGS) — is the direct ingredient cost of every item you sell. It applies equally to every channel. A grilled chicken dish costs the same to prepare whether it goes to a dine-in table or into a delivery bag.

However, the food cost percentage relative to revenue can look different across channels for two reasons:

1. Delivery pricing: Many UAE restaurants charge slightly higher prices on delivery platforms compared to their in-restaurant menu, which improves revenue without changing food cost. If your delivery prices match your in-restaurant prices exactly, your food cost percentage will be similar across channels. If delivery prices are higher, your food cost percentage improves on delivery orders.
2. Menu mix: Delivery customers often order differently from dine-in customers — more mains, fewer high-margin beverages and desserts. This affects your average food cost percentage even if individual item costs are identical.

Tracking food cost by channel requires recipe costing — knowing the exact ingredient cost of each menu item. The Luqma inventory module supports recipe-level costing so that food cost is calculated automatically as orders are placed, rather than estimated at month-end.

Item-level margin: not all delivery items are equal

A channel sales report tells you how much revenue came from delivery. It does not tell you whether the right items were sold. Two restaurants with identical delivery revenue can have very different delivery profits if one sells mostly high-margin items and the other sells mostly low-margin ones.

Item-level margin answers the question: after food cost, which items on my delivery menu are worth selling, and which ones are dragging down my average?

To calculate it for any item:

1. Take the delivery selling price of the item
2. Subtract the food cost (recipe cost) of that item
3. The result is the gross contribution of one sale of that item

When you run this across your delivery menu, you will typically find a cluster of items with strong contribution and a tail of items — often those that are complex to prepare, require expensive ingredients or are priced too low — where the margin is thin or negative after adding packaging cost.

This analysis is the basis for delivery menu engineering: deciding which items to promote, which to reprice and which to remove from your aggregator menu entirely. A delivery menu does not need to mirror your full in-restaurant menu. It should contain the items that deliver best.

Channel profitability: comparing dine-in, takeaway and delivery side by side

To compare channels properly, you need a consistent metric. The most useful one is contribution margin per order: what a single order leaves after subtracting its direct costs (food cost, packaging, channel fees).

The calculation per channel looks like this:

• Dine-in: Average order value − food cost of that order − minimal packaging
• Takeaway: Average order value − food cost − packaging cost per takeaway order
• Delivery: Gross order value − aggregator fee − food cost − delivery packaging cost

This gives you a comparable contribution figure per transaction across all three channels. Multiply each by the number of orders in a period and you have the total contribution per channel — which tells you where your restaurant actually makes money, not just where it collects revenue.

A restaurant channel sales report from your POS gives you the order volume and revenue by channel. Combining that with your food cost and aggregator fee data produces the full picture. If you operate multiple concepts or brands, this analysis becomes even more important — a cloud kitchen running four brands across two aggregators has 8+ channel combinations to evaluate, and guessing which ones are profitable is not a sound basis for decisions.

Daily reconciliation: closing the loop between POS and aggregator

Aggregator remittances do not arrive daily. Platforms typically pay weekly or fortnightly, and the payment covers orders placed several days earlier. This timing gap — combined with the difference between gross order value and net remittance — makes it easy for small errors to go undetected for weeks.

Daily reconciliation is the practice of recording delivery sales correctly at the POS level each day, so that by the time the aggregator remittance arrives, you can match it precisely.

A clean daily reconciliation workflow looks like this:

1. End of service: Your POS shift report shows total delivery sales by aggregator for that day — the gross order value of all delivery orders entered into or received by the POS
2. Weekly aggregator report: Download or export your aggregator sales report for the same period
3. Match gross values: The gross order value in your POS should match the gross order value in the aggregator report. Any variance needs investigation — it may indicate missed orders, orders not entered at the POS or data entry errors
4. Verify net remittance: Confirm the net remittance figure in the aggregator report matches what actually arrived in your bank account on the payment date
5. Record the fee separately: The difference between gross order value and net remittance is your platform cost for that period. Record it as an expense in your accounts, not as a revenue reduction

This process is straightforward when your POS captures delivery orders in real time. It becomes difficult when delivery orders are entered manually or not recorded in the POS at all — a situation common in operations that handle each aggregator's tablet separately from their main POS.

For high-volume delivery operations and cloud kitchens, clean aggregator reconciliation is foundational to understanding whether each brand and each platform is financially viable.

VAT on delivery sales in UAE

UAE 5% VAT applies to restaurant food sales, and delivery is not exempt. If your restaurant is VAT-registered — mandatory once annual taxable turnover exceeds AED 375,000 — VAT must be applied to every taxable delivery order.

Several specific points are worth confirming with your accountant:

• Who collects VAT on aggregator orders: Depending on your agreement with the platform, the aggregator may collect VAT on the order total and remit it to you as part of your gross order value — meaning you are responsible for paying it to the FTA. Or the aggregator may handle VAT collection and remittance separately. The treatment varies by platform and contract type; do not assume without verifying.
• VAT on delivery fees paid by the customer: If the customer pays a delivery fee shown on the platform, VAT may apply to that fee as well. The correct treatment depends on whether you or the aggregator is the principal for that delivery fee.
• Tax invoice requirements: Delivery orders to B2B customers may require a full tax invoice rather than a simplified invoice. Ensure your POS can produce both formats.
• Z-report VAT totals: Your daily Z-report from the POS should show VAT collected on delivery orders separately, so that your total VAT liability for each tax period is accurate and auditable.

For a full overview of UAE VAT requirements for restaurants, see the UAE VAT guide for restaurants.

How POS reporting helps you see the full picture

The analysis above is only practical if your data is in one place. When delivery orders live in separate aggregator dashboards and your POS only captures dine-in and takeaway, you are working with an incomplete picture — and the comparison between channels cannot be done reliably.

The Luqma reporting module is designed around channel-level visibility for UAE restaurant operators. It covers:

• Sales by channel: Dine-in, takeaway and delivery split by order type, with revenue and order count per channel
• Aggregator sales report: Delivery sales attributed by platform, so you can see Talabat restaurant reporting, Deliveroo restaurant reporting and other channels separately
• Item sales report: Which items sold across which channels, forming the basis for item-level margin analysis when combined with recipe costs
• Food cost reporting: Available on the Professional plan, this links recipe costs to sales data to show actual food cost percentage per period
• Daily Z-reports with VAT breakdown: Shift-level VAT summary for FTA compliance
• Shift reconciliation: Cash, card and payment method totals per shift, enabling the daily cross-check between POS and aggregator data

The Luqma POS platform connects all of this in one system — so that a restaurant running dine-in, takeaway and two aggregators does not need to consolidate data from five separate sources at the end of each week.

A practical starting point: the weekly channel review

You do not need a finance team to track delivery profitability. A weekly channel review takes less than 30 minutes if your data is organised, and it answers the questions that actually matter for decisions:

1. What was my revenue by channel this week? (POS channel sales report)
2. What did the aggregator pay me, and does that match my POS delivery total? (Aggregator report vs POS)
3. What was my food cost this week, and how does it split by channel? (Inventory/recipe data)
4. Which items drove the most delivery revenue — and do I know if they are high or low margin?
5. Is my delivery contribution trending up or down relative to last week?

These five questions, answered weekly from reliable data, give you more operational clarity than any dashboard that shows only revenue.

Frequently asked questions