Restaurant ERP Consultant, India

Reading an aggregator payout, line by line

For cloud kitchens in particular, aggregators are often the main sales channel, and their payout is the hardest number to explain. A weekly settlement per outlet ID typically starts from order value and then deducts commission, payment and platform fees, advertising spend, restaurant-funded discounts, cancellations and penalties, and lines for tax deducted or collected at source. GST on the aggregator's own services appears on its invoice.

Posting only the bank credit leaves sales understated, hides the cost of discounts and ads, and makes it hard to claim what is due back from the tax lines. I design the flow so gross sales come from the POS by outlet ID, the settlement file clears them through an aggregator control account, every deduction lands in its own ledger, and the aggregator's GST invoice is booked as a purchase. Differences above a tolerance are listed by order for the outlet team to dispute.

GST on restaurant orders placed through aggregators follows specific rules on who collects and pays the tax, and those rules have changed in recent years. Your chartered accountant confirms the current position; I make sure postings follow it. GST on dine-in, banquets and liquor is discussed on my India hospitality ERP page.

Cloud kitchens running several brands from one kitchen

A single Indian cloud kitchen can produce biryani, rolls, pizzas and desserts under separate brand names, sharing staff, equipment and much of the same stock. Operators may run dozens of such kitchens across cities, open new brands quickly and close weak ones within months. Without a firm structure, brand profitability becomes guesswork.

I keep inventory at the kitchen and tag sales and recipe consumption with the brand. Shared base preparations, such as a makhani gravy used by three brands, are costed once as sub-recipes and consumed by each brand in proportion to sales. Packaging, which can be a meaningful share of cost for delivery food, sits inside each recipe. Kitchen rent, utilities and staff are shared out using a formula the founders sign off, so brand contribution is comparable from month to month.

Menu changes need discipline. A new dish should not go live on an aggregator until its recipe exists in the system, otherwise theoretical cost loses accuracy quietly. When a brand closes, its items are archived, not deleted. Each kitchen also needs its own FSSAI registration or license, recorded on the kitchen master with renewal dates so expansion does not outrun compliance. The general recipe and theoretical cost model is described on ERP for restaurants.

Base kitchen indents, dispatches and theoretical food cost

Dine-in and QSR chains in India often prepare gravies, marinated proteins, doughs and desserts in a base kitchen and dispatch them to outlets daily. Outlets raise indents by phone or messaging app, the kitchen cooks to a rough estimate, and what arrives at the outlet is not always what left the kitchen. The outlet's food cost absorbs every gap.

The flow I design starts with structured indents from each outlet against par levels, consolidated into a production plan by the base kitchen. Each batch records yield and use-by date, dispatches carry the batch reference, and the outlet confirms receipt in the system. Short or damaged deliveries become visible on the same day, not at month end. Where the base kitchen and outlets sit in different states or entities, the dispatch has GST and documentation implications that your CA confirms.

Once dispatches and POS sales are clean, theoretical versus actual food cost becomes meaningful. Theoretical usage follows from recipes and items sold; actual usage follows from opening stock, receipts, dispatches and closing counts. Variances are listed by outlet and item, so the area manager can act on paneer, chicken or oil specifically rather than on a percentage. Rolling this out in a structured way is part of my ERP implementation support.

Own channels, loyalty and the link to customer acquisition

Aggregators bring reach, but they charge commission on each order and keep much of the customer relationship. Many Indian brands therefore invest in their own ordering website or app, WhatsApp ordering, loyalty programs and performance marketing. The decision about how much to spend on each channel is only as good as the margin data behind it.

This is where my second area of work, growth and customer acquisition, meets the ERP. I design how contribution margin by brand, outlet and channel flows from the ERP into the reporting that marketing uses, alongside order data from the POS, own channels and CRM. Aggregator advertising spend, discount funding and own-channel ad spend are all treated as acquisition costs, so the business can compare cost per profitable order across channels.

Customer data needs care. Own-channel orders and loyalty programs collect personal information, and India's data protection law sets expectations for consent and use; your legal advisor confirms what applies. I keep the design simple: the CRM or loyalty tool owns customer records, the ERP owns margins, and integration passes only what each side needs. For the CRM side of this work, see my CRM consulting service.

Tally, restaurant software and a remote rollout across cities

A common Indian starting point is a restaurant POS with its own inventory module, Tally for accounts and GST, and Excel for recipes and payout reconciliation. For a handful of outlets that stack may be sufficient, and I will tell you if it is. A full ERP is justified when there are base kitchens, several brands or entities, multiple GSTINs, investor reporting or a cloud kitchen network growing quickly.

Zoho, Odoo, ERPNext and Microsoft Dynamics 365 are compared on Indian restaurant cases: an aggregator settlement with tax deduction lines, a base kitchen dispatch to an outlet in another state, a multi-brand kitchen's month-end and a GST return extract. Some groups keep Tally for statutory accounts and let the ERP manage operations; I design the hand-off if so. Broader GST, e-invoicing and Tally questions are covered on my India ERP consultant page.

I deliver remotely, in Indian Standard Time, with recorded walkthroughs for outlet managers and kitchen supervisors who work long shifts. Rollout runs city by city, with a pilot kitchen first and its variance report reviewed with the head chef before the template moves on. On-site visits can be arranged if a specific stage needs one. Everything else I cover for Indian businesses is linked from the India hub.