Skip to main content

DRAFT — not sent

For internal review before any of this reaches the package's author. Subject: one rule in docs/03-gst-statutory-compliance.md has been superseded.

The finding​

Doc 03 §1, under Specified premises (raises F&B GST), states:

If any room-night tariff in the property exceeds ₹7,500, the property is a specified premises. Restaurant / minibar F&B is then 18% (otherwise 5%). This is dynamic: charge types must read the specified-premises flag at post time.

That was correct until 31 March 2025. It is no longer.

Notification 05/2025-CTR replaced the value-derived test with a declaration regime effective 1 April 2025. "Specified premises" is now a status a supplier opts into or out of for a financial year:

  • Annexure VII — opt in for the next FY, filed between 1 Jan and 31 Mar.
  • Annexure VIII — a new registrant opts in within 15 days of its ARN.
  • Annexure IX — opt out.

The consequence is that the status no longer follows the price list at all. A property charging ₹9,000 a night is not a specified premises unless it has declared itself one, and a property charging ₹4,000 can be one if it has.

Why this matters more than a documentation nit​

Doc 03 opens by saying every figure the software shows is governed by these rules, and that getting one wrong makes the invoice legally wrong. This one is wrong in the direction that under-collects.

A property that has declared itself specified but prices below ₹7,500 would, under the doc-03 rule, bill F&B at 5% where 18% is due. Under §32/§76 the shortfall is the hotel's to remit, not the guest's to top up — so the error lands on the operator, after the period may already have been filed.

What we implement, and why it is stricter than the rule alone​

KeyNova resolves the status from a declared, per-financial-year, effective-dated record with maker-checker approval, never from the bill — hmp-frontdesk-service/src/folios/specified-premises-fy.ts. @hmp/tax states the same invariant at its own boundary: "isSpecifiedPremises comes from the FY status input, NEVER value > 7500."

Two details are worth passing on, because they are not obvious from the notification and both cost money if missed:

  1. Select by the FY of the supply date, not the newest declaration. A property can be 5% in one FY and 18% in the next. Rating a backdated stay or a late-posted F&B chit against today's declaration mis-rates a period that may already be filed.
  2. Honour effectiveFrom within that FY. A declaration effective part-way through its own year does not reach back over earlier supplies in it.

What we suggest​

Replace the value test in doc 03 §1 with the declaration model, and make the per-charge lookup read a declaration as at the supply date rather than a flag as at post time. The rest of doc 03 §1 — that the F&B rate is 18% for a specified premises and 5% otherwise — is unchanged and correct.

Scope of this note​

This is the only superseded rule we found. The remainder of doc 03 — the ≤₹7,500 5% / >₹7,500 18% accommodation slab tested per night, composite supply, place of supply, §13(2) advances, §15 discounts, the SAC table, §269ST, §34 credit notes, FRRO and DPDP — matches both current law and our implementation.

We are not offering legal advice; this is the ruleset we encode and the authority we encode it from. Worth confirming with your own advisor before amending the doc.

Reviewer notes (strip before sending)​

  • Tone. Deliberately not a defect report. They handed us a package in good faith and the rule changed under them; a correction reads better than a finding.
  • What is NOT in here, on purpose: the "group is derived from rooms.length > 1" conflict (C1). That is our SME's ruling about our product, not an error in their document, and mixing the two would make a correction look like a rebuttal.
  • Verify before sending. I have not had a lawyer or CA confirm the 05/2025-CTR reading — I read it from our own implementation and its cited authority. Worth an SME pass (AB#13148 is already routed to hospitality-sme for a different question).
  • Audit: 2026-08-30-group-folio-developer-package-gap-audit.md §4 C2.