Restaurant GST compliance starts with correct item-level HSN codes and tax slabs locked in your menu master data — errors here propagate to every receipt. The POS formats the bill; your chartered accountant determines the compliance posture. Before going live with any new POS system, walk through B2C receipts, B2B corporate invoices, and the reconciliation report with your CA, not just the sales team.
How should restaurants set up menu master data for GST compliance?
Menu master data is the foundation of every receipt your restaurant prints. A misconfigured tax slab on a single item does not produce one wrong bill — it produces thousands of wrong bills, all of which eventually need to be explained to your CA and potentially to the department.
Each sellable item in your menu should carry three tax-relevant fields set correctly before the first order is taken:
- HSN/SAC code where applicable. Your CA will advise on the correct code per category; your POS records it. Do not leave this blank and assume it does not matter.
- Tax slab. Confirm with your CA whether your establishment falls under the composition scheme or the regular rate for restaurants, and which rate applies to food items versus beverages versus packaged goods. These are not decisions the software makes; the software enforces the decision you made with your CA.
- Explicit bundle rules. If you offer combo meals, happy-hour pricing, or set menus, each discounted component still needs defensible tax treatment. Discounting the selling price is not the same as discounting the tax base in every jurisdiction and circumstance. Ask your CA before you build the bundle in the POS.
Lock these fields centrally and require manager-level access to change them. A waiter who adjusts a price to accommodate a guest should not be able to inadvertently change the tax category in the process.
Run a spot audit of your master data every quarter: pull a tax category report and compare it to the list your CA approved. New items added during the quarter are the most common source of silent errors — someone added the item to the menu, estimated the tax category, and moved on.
What is the difference between B2C and B2B restaurant invoices?
A B2C bill — the receipt handed to a table of friends after dinner — and a B2B invoice for a corporate client claiming input tax credit are legally different documents, and your POS needs to handle both cleanly.
The most important difference is the information a B2B invoice must carry that a standard receipt does not: the buyer’s GSTIN, their registered address, and in some cases their legal name as it appears on their GST certificate. A corporate finance team cannot file a claim on an invoice that has the right amount but the wrong entity name.
Decide early where the B2B invoice flow lives. Two common approaches:
- At the POS during order creation: the host or cashier captures the GSTIN at the time the order is placed. The invoice prints with all required fields populated. This is cleaner but requires training front-of-house staff to capture the information consistently.
- As a back-office export: the bill is settled normally and a formal invoice is generated from the back-office system, emailed to the accounts contact. This separates the operational flow from the compliance flow, which suits restaurants where corporate billing is a minority of covers.
Whichever approach you choose, the critical moment is GSTIN capture. Train hosts and reservation staff to collect it when the booking is confirmed — not at checkout when the queue is stacked behind a departing party and someone is already asking for the card machine.
For email delivery of B2B invoices, confirm with your CA whether the invoice needs a digital signature or a specific format for GSTR reconciliation. The details vary; the principle is that your accountant needs to approve the template before you send the first one.
How do you reconcile POS sales reports with payment gateway settlements?
POS sales and payment gateway settlements are two different views of the same money, and they will rarely match exactly in real time. The goal is not zero variance — it is understanding why the variance exists and whether it is within acceptable tolerances.
The daily Z-report from the POS records gross sales, voids, comps, discounts, and net sales by tender type. The payment gateway settlement records what actually landed in your bank account: net of gateway fees, refunds, and any holds. These two numbers will differ by at least the gateway fee and sometimes by timing differences when a batch from the previous day settles the following morning.
Set a reconciliation tolerance with your finance team — a percentage or an absolute rupee amount — and investigate any daily variance outside that band before it carries forward. Small drifts are not always small in cause: a ‘200 unreconciled difference that repeats daily for a month is a ‘6,000 problem at month end, and the root cause is far harder to reconstruct four weeks later.
Common sources of reconciliation drift that are worth checking before assuming software error:
- A refund processed at the gateway that was not recorded as a return in the POS.
- A card transaction that was approved at the terminal but appears as pending or declined in the gateway settlement export.
- Cash sales rung through the POS with a drawer opening but counted differently at close.
- Tip amounts added by the card holder post-authorisation that change the settlement total after the Z-report was printed.
GetRestro’s reporting is built for operational clarity, giving you the daily sales view in a format designed for review. Pair it with your accounting package’s chart of accounts mapping to create the reconciliation bridge. Your CA should define what each line in the POS report maps to in your books — that mapping is the reconciliation logic, and it needs to be documented, not assumed.
Build this reconciliation into a weekly finance routine rather than a monthly one. Monthly closes with unresolved daily drifts are the most common source of last-minute scrambles before statutory filings. Weekly reviews keep the problem manageable and the audit trail fresh.