Running a Food Court? Here's How Shared Table & Menu Software Actually Works

Search for "food court POS software" and almost everything you'll find assumes the same underlying model: one operator, one central cash counter, prepaid cards or wallets customers load money onto, and stalls that are really just sub-tenants of a single business. That model exists, and it fits some genuinely centrally-run food courts. But it's the wrong model for a very common, different situation — several completely independent restaurant businesses, each with their own GSTIN, their own staff, and their own billing, that happen to share one physical seating area.

If you're one of several independent stalls sharing a food court, or you're the person trying to bring several independent restaurants into a shared space, software built around a single-operator, central-till assumption doesn't just fit awkwardly — it actively misrepresents how the arrangement actually needs to work. This guide is about the alternative model: independent restaurants sharing physical space, tables, and even menu items, without any of them giving up their own separate billing, their own separate GST invoicing, or their own separate business.

That's the actual promise of a well-built shared-space arrangement — genuine collaboration between independent businesses, not one business absorbing the others into a single till. The rest of this guide walks through exactly how that works mechanically, what stays separate, and what a food court actually gains from doing it this way instead of the central-operator model most software assumes.

The Wrong Model Most "Food Court POS" Software Assumes

The default assumption in most food-court software is straightforward, and straightforwardly wrong for a lot of real situations: one operator runs the whole show, customers load money onto a prepaid card or wallet at a central counter, individual stalls just tap or scan to deduct a sale, and at the end of the day, the operator reconciles everything and pays out each stall's share.

That model works when there genuinely is one business behind every stall — a single company running multiple branded counters under one roof. It breaks down immediately when the stalls are actually independent businesses. Six different restaurant owners, each responsible for their own GST filing, their own staff, their own supplier relationships, do not want their sales routed through someone else's central till before they see a rupee of it. They want their own POS, their own billing, their own reports — and they want the shared-space arrangement layered on top of that, not replacing it.

What Actually Changes When Restaurants Share a Space

The real requirements of a shared-space arrangement between independent restaurants turn out to be narrower and more specific than "merge everything into one system." What actually needs to be shared is limited to three things: physical tables, so customers seated in a shared area can be served by any participating restaurant; optionally, specific menu items, so one counter can sell across multiple kitchens without every kitchen needing its own separate order point; and, if the arrangement includes one, a commission settlement between an operator and vendors.

Everything else — billing, GST invoicing, staff, inventory, reporting, settlement — stays exactly as separate as it would be for restaurants that had never met each other. That's the core design principle worth understanding before anything else in this guide: sharing is additive and narrow, not a merger of the underlying businesses.

The Two-Layer Consent Model: Nothing Shared By Accident

A genuinely important detail, easy to get wrong: two restaurants agreeing to collaborate should not, by itself, expose any data at all. A real shared-space arrangement works in two distinct layers, and understanding the gap between them is what prevents an accidental over-share.

Layer one — the trust connection. One restaurant invites another, by a specific, known identifier — not an open search anyone could browse. The other accepts or rejects. On its own, this layer establishes nothing more than "these two businesses have agreed to work together." No tables, no menu items, no order data becomes visible from this step alone.

Layer two — deliberate, specific sharing. Only after the trust connection exists does the restaurant that owns tables or menu items choose, explicitly, what to actually expose — which specific tables, which specific menu items — and only that restaurant can make that choice, since it's their own resource being shared.

Sharing Tables Without Sharing Data

Even once a table is shared, what the other restaurant can actually see about it is deliberately limited by default — and this is worth spelling out precisely, because "sharing a table" sounds like it should mean full visibility, and it specifically shouldn't, unless both sides separately agree to more.

That "both sides must opt in" requirement is deliberate, not an oversight. One restaurant wanting to show its own orders to a partner doesn't mean the partner is comfortable reciprocating — symmetric consent means neither side's privacy preference can be overridden by the other's.

Selling Across the Table: How Shared Menus Actually Work

Table sharing solves seating. It doesn't, by itself, let one counter sell another kitchen's food. That's a separate, higher-trust capability: a restaurant can choose to share specific menu items so a partner's own counter can sell them directly.

The mechanism that makes this work correctly is worth understanding, because it's what keeps billing honest across independent businesses: a shared menu item isn't copied anywhere. It's the owning restaurant's real menu item, made sellable by a partner. When the partner's counter sells it, the resulting order is created under the item's actual owner — billed with the owner's own GST invoice, settled through the owner's own account. The partner's staff member who processed the sale is recorded for accountability, but the transaction and the money belong to the item's owner, exactly as if that owner's own staff had rung it up.

An optional, separate, higher-trust permission goes further — letting a partner actually edit an item's name, price, or description, not just sell it as-is. This is off by default specifically because it's a materially bigger grant than simple sell-permission, and should be a deliberate choice, not an assumed default.

One QR Code, Every Stall

Table sharing and menu sharing come together most visibly in QR self-ordering across a shared table. A customer scanning one physical table's QR code, in a properly built shared-space arrangement, sees every participating, QR-enabled restaurant available at that table — not just the table's original owner — and can order from more than one in the same visit.

Every restaurant's order through that shared QR code stays its own separate transaction: its own bill, its own GST invoice, accepted or rejected by its own staff. The QR code is genuinely shared infrastructure; the billing behind it never is. A group of four ordering from three different stalls at one shared table ends up with three separate bills, not one combined check split awkwardly afterward.

Commission Between a Food-Court Operator and Vendors, Done With Consent

Many food courts run on a commission model instead of flat rent — an operator takes a percentage of each vendor's sales in exchange for the space and shared infrastructure. Done informally, this is exactly the kind of arrangement that erodes over time the same way an untracked referral deal does: no real record, no way for either side to verify what's owed, and an easy source of quiet resentment once volumes get large enough to matter.

A properly built version treats this as a real financial arrangement requiring explicit consent from both sides, not a number one party can just impose or change unilaterally.

Once active, commission calculates automatically on every relevant order — no manual entry, no month-end reconstruction from memory — with a real payout ledger tracking what's accrued, what's been paid, and what remains outstanding. The asymmetry in who can revoke is deliberate: a vendor who agreed to a rate shouldn't be able to simply stop honoring it once it becomes inconvenient, while the arrangement itself only ever started with their explicit consent in the first place.

A Six-Stall Food Court, Before and After

Picture six independent restaurant owners — a juice counter, a pizza stall, a Chinese counter, a sweet shop, a biryani stall, and a beverage kiosk — sharing one seating area of about thirty tables.

Under the central-till model: Customers load a prepaid card at one central counter. Each stall taps the card to deduct a sale. At month-end, the operator reconciles six stalls' worth of transactions against the central till, calculates each stall's share, and distributes payouts — a process that takes real administrative time and gives every single vendor a reason to double-check the operator's math, since none of them can independently verify it themselves. If the operator is slow, disorganized, or simply has a bad month administratively, all six vendors feel it.

Under the independent-collaboration model: Each of the six stalls runs its own POS, its own billing, its own GST invoicing — exactly as if it were a standalone restaurant, because for billing purposes, it is one. The shared seating area is set up once: each stall collaborates with the space's coordinating restaurant (or with each other directly), tables are shared so any stall can serve any table, and a subset of popular items get cross-listed so, say, the juice counter can sell a drink alongside another stall's food order at the same table. If there's a commission arrangement with whoever coordinates the space, it's proposed, explicitly accepted, and then calculated automatically on every relevant order — no month-end reconciliation scramble, and no single point of administrative failure that all six businesses depend on.

The second model isn't just more convenient — it changes who bears the operational risk. In the first, every vendor's cash flow depends on one central party doing reconciliation correctly and promptly. In the second, each vendor's own revenue reaches them directly, through their own billing, the moment a customer pays.

What This Explicitly Does NOT Do

Given how much food-court software defaults to the central-till, prepaid-card model, it's worth being direct about what a properly built independent-restaurant shared-space arrangement deliberately does not include — not as a limitation to apologize for, but as the whole point of the design.

This isn't a gap to work around — for independently-owned stalls, it's precisely the feature. Nobody's revenue passes through anyone else's till before reaching them, and nobody's GST filing depends on a third party's reconciliation process being done correctly and on time.

Worth a direct clarification, since the word "commission" gets reused across a few different Billzova features: this vendor-to-operator arrangement is a different mechanism from a single restaurant paying its own referral partners for bringing in customers, covered in our restaurant referral program guide. It's also unrelated to becoming a Billzova partner yourself. All three involve the same word; none of them are the same arrangement.

Is This Right for Your Space?

"Food court" is the most obvious use case, but it's not the only one. The same underlying arrangement — independent businesses sharing physical space without merging their billing — applies more broadly than the mall-food-court image it usually conjures.

How to Actually Set This Up

Frequently Asked Questions

Does this require a single company to own all the stalls?

No — this is specifically built for independently-owned restaurants collaborating, each keeping their own separate business, billing, and GST registration. A single-owner, multi-brand setup can also use it, but it isn't a requirement.

Can a food-court operator see every vendor's sales data?

Not by default. Order visibility on a shared table is occupancy-only unless both the vendor and the party wanting visibility explicitly opt in to more — an operator doesn't get automatic access to a vendor's order details just by virtue of running the space.

What happens to shared tables and menus if a collaboration ends?

Ending the collaboration ends the sharing immediately, in one step — the partner no longer sees those tables or menu items, and no new cross-vendor activity can happen against them. Anything already completed beforehand is unaffected.

Can more than two restaurants share one food court through this model?

Yes, though it's structured as several separate pairwise collaborations rather than one group arrangement — restaurant A collaborates with B, with C, with D, and so on, each with its own independent invite, sharing, and commission setup.

Is a written contract still necessary if the software tracks the commission?

The software provides a real, mutual record of the agreed rate and the resulting payouts — it's not a legal substitute for whatever formal agreement the businesses want between themselves, but it does remove the ambiguity that otherwise makes those agreements hard to enforce in practice.

How is this different from just giving a partner restaurant a login to your own POS?

Sharing a login would expose your entire account — every table, every report, every setting. This model shares only the specific, deliberately chosen resources (particular tables, particular menu items) while keeping every other part of your account, and your billing, completely private and separate.

Does a shared table show up mixed in with a restaurant's own tables?

No — a properly built version keeps shared tables in their own clearly separate section on the tables screen, distinct from a restaurant's own floor layout, so staff never confuse a shared table with one they fully own.

If two independent stalls both sell drinks, does sharing a menu force them to compete on the same listing?

No — each restaurant keeps its own separate menu. Menu sharing only ever exposes items the owning restaurant explicitly chose to share, to a specific partner they chose to share them with — it doesn't merge or combine two restaurants' menus into one shared catalogue.

Can a vendor leave a food-court arrangement without the operator's permission?

Yes, for the collaboration itself — either side can end a collaboration at any point. The one thing a vendor (payer) specifically cannot do unilaterally is walk away from an already-accepted commission rate; only the side receiving the commission can end that specific arrangement, which is a deliberate protection against a vendor agreeing to a rate and then simply ignoring it once it's inconvenient.

Does every restaurant in a shared space need to use the same POS software?

In practice, this kind of deep table/menu/commission sharing requires both sides to be on the same platform, since the sharing mechanics depend on both restaurants' data living in the same system. A restaurant on different software could still physically share a space, just without this specific level of integrated sharing.

Is there a limit to how many tables or menu items can be shared?

No fixed limit on either — the table-owning or menu-owning restaurant decides how much or how little to share, from a single table or item up to nearly everything, entirely at their own discretion.

The Bottom Line

Most food-court software gets built around the assumption that one operator is really running the show, with vendors as sub-tenants of a single till. That model has its place, but it's the wrong fit for the increasingly common situation of genuinely independent restaurants sharing physical space — where each business needs to keep its own billing, its own GST filing, and its own customer relationship intact, while still gaining the real benefits of sharing tables, cross-selling menus, and running a fair, trackable commission arrangement.

billzova's Collaboration feature is built specifically around that independent-businesses model — pairwise trust, deliberate table and menu sharing, occupancy-only visibility by default, and consent-gated commission settlement — included standard at ₹399/month per restaurant, with no separate food-court module fee.