Managing a Cloud Kitchen or Multi-Outlet Restaurant in India: Payouts, Food Cost, Shifts and GST

A single restaurant is a business you can hold in your head. You know what came in, roughly what went out, and whether the day was good. The moment you run three kitchens across two cities — or one cloud kitchen running five brands off the same hob — that intuition stops working. The numbers still exist, but they arrive in fragments: an aggregator payout statement on one cycle, a POS sales report on another, a vendor bill on WhatsApp, an attendance register in a notebook at the outlet, and a GST return that has to somehow reconcile all of it.

Multi-outlet food businesses in India do not usually struggle on food quality. They struggle at the four seams where information gets lost between outlets: aggregator money, food cost, labour, and compliance. This post is about those four seams specifically — what can go wrong at each, and what the control looks like.

Seam 1: The aggregator payout is not your sales number

A mistake worth guarding against as a chain grows is treating the aggregator payout as the sales figure. It is not. It is the order value minus a stack of deductions, some contractual, some discretionary, and none of them visible unless you read the statement.

Between the gross order value the customer paid and the amount that lands in your bank, the following get taken out, in some combination:

• Platform commission on the item value, at brand-specific or outlet-specific rates
• Payment gateway charges on the collected amount
• Restaurant-funded discounts — the "flat 50% off" you agreed to co-fund, and any freebie or coupon absorbed on your side
• Advertising and visibility spends, which are deducted from the payout rather than invoiced separately
• Cancellations and refunds, including customer-complaint refunds charged back to the outlet
• Penalties for rejected orders, delayed dispatch or item unavailability
• Packaging and delivery-fee adjustments, depending on the arrangement
• TDS under section 194-O, deducted by the e-commerce operator on the gross amount

Every one of those is legitimate in principle. The difficulty is that checking them line by line takes time nobody has set aside, so they tend to go unchecked — and a deduction you have never verified is a margin assumption rather than a margin.

What reconciliation actually means here

Real reconciliation is not "did the money come in". It is a three-way match, done per outlet, per cycle:

• Orders (your record) as captured in your POS or kitchen display for that period
• Orders (platform report) as listed in the aggregator's own order report
• Money as listed in the payout statement, deduction by deduction

What you are checking for is specific and repeatable: orders that appear in your POS but not in the payout at all; orders shown as cancelled that your kitchen believes it cooked and dispatched; commission you should tie back to the rate in your contract; a promotion you have exited that is still being co-funded; a refund raised on an order your outlet has dispatch evidence for. The point of the routine is that when a line does not tie out, you catch it inside the cycle with the evidence still to hand.

None of that is exotic. It is simply work that has to have an owner, a deadline and a paper trail — which is exactly why it collapses when it lives in one person's inbox. Making it an assigned task per outlet per payout cycle, with the statement attached and a query log that someone has to close before the next cycle opens, is a management problem before it is a software problem. A platform like GroviaOS helps here not by replacing your POS or the aggregator dashboard, but by giving that work a place to live: the task, the outlet it belongs to, the person accountable and the attached statement, in the same system as the purchases and invoices it has to agree with.

Seam 2: Food cost is an outlet-level number, not a chain-level one

Chain-level food cost percentage is a comforting number and a fairly useless one. If one kitchen runs at 28% and another at 38%, the average tells you nothing about which cook is over-portioning, which outlet is over-ordering perishables, or which brand's menu was priced before the last onion cycle.

The control is the variance between theoretical consumption and actual consumption, computed per outlet:

• Theoretical: every menu item has a recipe with standard quantities. Multiply items sold by their recipes and you get exactly how much chicken, paneer, oil and packaging you should have used.
• Actual: opening stock plus purchases minus closing stock, from a physical count on a fixed day.

The gap between those two is your leakage, and it has a small number of causes worth separating rather than lumping into "wastage": yield loss during prep (a crate of tomatoes is never entirely usable tomato), spoilage of perishables that were over-indented, staff meals, re-fires from order errors, portioning drift, and outright pilferage. A cloud kitchen running multiple brands off one line has an extra failure mode — shared ingredients get consumed by brand A and costed to brand B, so brand-wise profitability becomes fiction unless the recipe mapping is honest.

Practically, this means three disciplines: a locked recipe master that changes only with approval, a weekly physical count of the items that drive most of your spend rather than a heroic monthly count of everything, and purchase records captured against the outlet that received the goods. That last one is where it usually breaks: vendor bills that live only in a WhatsApp group never become a purchase record tied to an outlet, and without that the actual side cannot be built at all.

Seam 3: Shifts and payroll across kitchens

Labour in food service is not a monthly salary problem. It is a shift problem with a payroll consequence. Peaks are narrow — a lunch window and a dinner window — and the same chef may cover the dinner rush at one kitchen after prep at another. Split shifts, late-night closing, festival surges and Sunday spikes all mean that "who worked where, for how long" is genuinely hard to reconstruct at month-end from a register kept at each outlet.

What goes wrong is predictable. Overtime gets paid on someone's recollection. Staff deployed temporarily to another kitchen still get costed to their home outlet, distorting both outlets' numbers. Attendance is marked by the shift in-charge for people who arrived late. And PF and ESI applicability, which depends on headcount and wage thresholds, gets assessed on a fuzzy view of who is actually on the rolls.

The fix is mechanical, and mostly discipline rather than tooling: attendance recorded daily against the kitchen where the shift was actually worked instead of reconstructed at month-end; staffing planned and written down in advance rather than settled verbally at the door; and labour cost attributed to the outlet where the hours were spent, not to the outlet on the employee's file.

GroviaOS covers the record-keeping half of that — attendance, leave and payroll in one HR module, so hours and cost sit in the same system as your purchases and invoices rather than in a notebook at the outlet. It does not do shift rostering; its attendance model assumes a single work schedule, so rotations stay wherever you plan them today.

Seam 4: Consolidated GST when you have outlets in multiple states

GST is where multi-outlet food businesses discover that their structure has compliance consequences they never chose deliberately.

The core points that shape the work:

• Registration is state-wise. Outlets in one state can sit under a single GSTIN with additional places of business declared; outlets in another state need a separate registration. Three states means three sets of returns, three sets of reconciliations, three sets of deadlines.
• Restaurant service is generally taxed at 5% without input tax credit for standalone restaurants, which means the GST on your rent, packaging, commissions and equipment is a cost, not a credit. This is precisely why food cost and labour discipline matter more here than in businesses that recover their input tax.
• Orders through aggregators fall under section 9(5). For restaurant service supplied through an e-commerce operator, the operator discharges the GST. You still report those supplies — in GSTR-1 and in the corresponding table of GSTR-3B — but you are not paying the tax on them yourself.
• Your dine-in, takeaway and direct-delivery sales are yours to tax and report in the normal way, which means a single outlet's monthly filing draws from at least two different streams.

The law is specific about which supplies go where, and reporting a 9(5) supply as your own — or leaving it out — creates a mismatch you then have to explain. Consolidation, then, is not one return. It is a repeatable monthly close: sales by channel and by outlet, mapped to the right GSTIN, split between 9(5) supplies and your own supplies, tied back to what the POS recorded and what the aggregators reported. Chains that do this well treat it as a checklist with owners and dates. Chains that do it badly treat it as something the accountant will sort out on the 18th, and pay for that in mismatches.

The pattern behind all four

Each seam is the same failure in different clothing: the operational record and the financial record live in separate systems, so nobody can answer "how did outlet 3 actually do last month" without a day of spreadsheet work. Your POS is genuinely good at taking orders. Aggregator dashboards are genuinely good at showing platform performance. Neither was built to be the place where vendor bills, staff attendance, disputed payouts and compliance deadlines converge — and that convergence is the actual job of running a chain.

That layer is what GroviaOS is for: one place where purchases, expenses, GST-compliant invoicing with HSN/SAC and place-of-supply handling, staff attendance, leave and payroll, and the tasks that carry your payout reconciliation and monthly close all sit in the same system, each with an owner and a due date. Profit and loss reporting is organisation-level, with separate profitability on projects, so one workable way to get a per-kitchen view is to set each outlet up as its own project and book its purchases, expenses and time against it. The web app carries the office work; the mobile apps cover tasks, tickets, chat and field work. Keep your POS. Fix the layer above it.

If you are running two or more kitchens and your monthly numbers still come together in a spreadsheet, that is the constraint on how many more you can open. Start a free trial of GroviaOS, set it up the way you actually run the kitchens, and see how much of the month-end reconstruction disappears. Pricing is on the pricing page.

Frequently Asked Questions

How do I reconcile Swiggy and Zomato payouts with my actual orders?

Match three sources for each outlet and each payout cycle: your POS order list, the platform's own order report, and the payout statement line by line. Check that every order you cooked appears in the payout, that anything shown as cancelled matches your kitchen's own record, that commission ties back to your contracted rate, and that no promotion you have exited is still being co-funded. Log any line you cannot explain with the order ID and your evidence, and give one person ownership of closing those queries before the next cycle.

Do I need a separate GST registration for each restaurant outlet?

Registration is state-wise, so each state in which you operate needs its own GSTIN. Multiple outlets within the same state can operate under one registration with the additional locations declared as places of business, though separate registrations within a state are permitted in certain cases. Confirm your specific structure with your CA, because it determines how many returns you file every month.

Who pays GST on orders received through Swiggy or Zomato?

Under section 9(5), the e-commerce operator is liable to pay GST on restaurant service supplied through its platform. As the restaurant, you still report those supplies in the designated tables of GSTR-1 and GSTR-3B, but you do not discharge the tax on them yourself. Your dine-in, takeaway and direct-delivery sales continue to be taxed and reported by you in the normal way.

How do I control food cost across multiple kitchens?

Compute theoretical consumption from a locked recipe master multiplied by items sold, then compare it against actual consumption from opening stock plus purchases minus a physical count. Do this per outlet, never as a chain average, and separate the causes of the gap — prep yield loss, spoilage, staff meals, re-fires and portioning drift — because each has a different fix. A weekly count of the items that drive most of your spend beats a monthly count of everything.

Can GroviaOS replace my restaurant POS?

No, and it is not meant to. Your POS handles order taking, KOT and billing at the counter, and your aggregator dashboards handle the platforms. GroviaOS sits above that as the business layer — vendor bills and purchases, expenses, GST-compliant invoicing, staff attendance, leave and payroll, and the reconciliation and compliance work carried as assigned tasks with owners and due dates. It does not take orders and it does not connect to the delivery platforms.

How should I track staff who work across more than one kitchen?

Record attendance daily against the kitchen where the shift was actually worked rather than against the person's home outlet, and keep it in one system rather than a register at each location, so month-end is a read rather than a reconstruction. Agree cover in advance in writing rather than improvising at the door. Without attributing hours to the kitchen that used them, a chef covering a dinner rush elsewhere still loads cost onto their home outlet, which distorts both outlets' margins and makes underperformance impossible to diagnose.