Tax invoice or bill of supply? GST billing for restaurants, decided by law

Most restaurant billing software asks you to pick an invoice template. That is the wrong question. Which document you must issue is not a design choice — it follows from how you are registered, and getting it wrong is a compliance problem that surfaces months later, in an assessment, when it is expensive.

Here is the rule, and what a point of sale has to do about it.

The registration decides the document

If you are a regular registered supplier, you issue a tax invoice. It shows the taxable value and the tax charged, split by head — CGST and SGST for a supply inside your state, IGST across state lines.

If you are registered under the composition scheme, you do not collect GST from the customer at all, so you must not print a document that says you did. You issue a bill of supply, and it carries the declaration that you are a composition taxpayer not eligible to collect tax on supplies.

If you are unregistered, there is no GST to show, and again the document is not a tax invoice.

The failure mode is the obvious one: a composition restaurant printing something labelled "Tax Invoice" with a tax column on it. It looks professional. It is a misstatement of tax collected.

Rounding happens per head, at the invoice level

This is the detail that quietly breaks spreadsheets and homegrown tills. Tax is rounded per head, on the invoice total — not per line item, and not once on the combined tax.

Round each line's CGST and each line's SGST separately and add them up, and your totals will drift from what the return expects by a paisa here and a paisa there. Sum the taxable value first, compute each head on the total, round each head, and the invoice ties. Section 170 of the CGST Act is where this lands; the practical version is that the arithmetic order is not yours to choose.

Aggregator orders are tagged, not taxed

If you sell through Swiggy or Zomato, Section 9(5) makes the platform liable to pay the tax on those supplies, not you. The order is still yours, it still comes out of your kitchen, and it still belongs in your sales reports — but you do not charge GST on it and it does not go into your outward tax liability.

So a report that simply adds up "all sales × rate" is wrong for any restaurant with a delivery channel. The aggregator orders have to be identifiable and excluded from the liability, while staying present in the revenue picture. That is a data-shape requirement, not a filter you remember to apply.

What this means for a POS

Three things, none of them optional:

- The document type follows the registration, set once and then enforced — not a template the counter staff can pick from. - Rates are dated data, because they change, and a bill re-printed next year must still show the rate that applied on the day it was rung. - Every figure traces back to its source rows, so when a number is questioned you can show where it came from rather than recomputing it and hoping.

Keystonne OS treats all three as engineering, not settings. The registration type decides the document, per-head rounding is applied at the invoice level, Section 9(5) orders are tagged at the point they arrive, and rates live as dated rows. It is tested against fixtures rather than trusted to a preference screen — because tax correctness is the one part of a restaurant's software that has to be right on a day nobody is watching.