Ask three hoteliers in the same city what GST rate they charge on a room and you can get three answers. They're often all telling the truth — because hotel GST isn't a rate, it's a rule that produces different rates for different rooms on different nights.
Quick answer (for the impatient)
Room GST is slab-based — the rate depends on the value the room actually sold for, not on your property's category or star rating.
Food and beverage is taxed on its own logic, separately from the room, and the rules interact with whether you claim input tax credit.
Rates and thresholds have changed more than once. Treat every number you read online — including in older articles — as needing confirmation for the current period.
The mistake almost everyone makes first
The common error is treating the slab as a property attribute. Hoteliers say "we're an 18% hotel" the way they'd say "we're a three-star." That isn't how it works. The slab attaches to the transaction, so the same room in the same hotel can fall into different slabs on different nights depending on what it actually sold for.
Which means a discounted room in a peak-season week and a full-price room in a lean month can be taxed differently. If your billing system holds one hardcoded rate per property, it is producing wrong invoices on some meaningful fraction of your nights, and nobody at the front desk will ever notice.
Where the value comes from matters
A recurring point of confusion is which number drives the slab — the rack rate, the published tariff, or what the guest actually paid. The concept the law works from has shifted over time, which is precisely why so much outdated guidance is still circulating. This is the single most important thing to confirm for your current period, because getting it wrong is systematic rather than occasional: it doesn't produce one bad invoice, it produces a bad invoice on every discounted booking.
Practical consequence: if you run promotional rates, corporate rates, or OTA rates that differ materially from your published tariff, this question decides your GST treatment on a large share of your revenue. Ask your CA specifically about discounted and OTA bookings rather than about your rate card in general.
Food and beverage runs on separate logic
Restaurant service inside a hotel has its own treatment, and it can depend on the room tariff the property charges — which is why a hotel restaurant and a standalone restaurant next door may legitimately tax the same dish differently. The input-tax-credit position is tied up in this too, so the rate you charge and the credit you can claim are one decision, not two.
This is genuinely worth a conversation with your accountant rather than a rule of thumb, because the option that produces the lower headline rate isn't automatically the one that leaves you better off once credit is accounted for.
What this means for your billing system
A single hardcoded GST rate is a red flag. If your software can't vary the rate by what the room sold for, it can't be correct across your full rate range.
Room and F&B need separate treatment on the same bill. A stay with a restaurant charge on the folio is two tax logics on one invoice.
Your HSN/SAC codes need to be right, not just present. A correct rate under a wrong code is still a defective invoice.
Where we're honest about the limits of this post
This is a structural explainer, not tax advice, and deliberately doesn't quote specific rates or thresholds. Hotel GST slabs, the basis for computing them, and the F&B treatment have all been revised more than once, and any specific figure published today has a real chance of being wrong within a year. Confirm current rates with your CA or the GST portal for your period — and be especially sceptical of undated articles.
A realistic hotel example: what the team sees during a working shift
Picture Lakeview Residency, an independent property where the same manager may answer a booking query, approve a rate, settle a guest account and help a new employee before lunch. The question behind GST on Hotel Rooms in India: How the Slab Logic Actually Works does not arrive as a neat software task. It arrives while somebody is waiting, another department needs an answer and the record must still make sense at the end of the day.
The first useful observation is this: Room GST is slab-based — the rate depends on the value the room actually sold for, not on your property's category or star rating. The manager should translate that statement into a visible hand-off. Who starts the action? Which record do they open? What information must already be present? Who checks the result? If any answer depends on one experienced employee remembering an exception, the process is not yet reliable.
The second observation is equally practical: Food and beverage is taxed on its own logic , separately from the room, and the rules interact with whether you claim input tax credit. At Lakeview Residency, the team would test this with one ordinary case and one awkward case. The ordinary case confirms the expected path. The awkward case exposes missing permissions, incomplete data, unclear ownership or a decision that still happens in a private message. Both tests matter because hotel operations rarely fail on the clean example shown in a demonstration.
The third observation is about the downstream record: Rates and thresholds have changed more than once. Treat every number you read online — including in older articles — as needing confirmation for the current period. A completed action should leave enough context for the next person to understand what happened without reconstructing the story from calls and chat messages. That does not mean collecting every possible field. It means keeping the few facts that change the decision, the status, the responsible role and the next action together.
Rollout checklist: move from a good idea to a repeatable process
Use this checklist before the team treats the workflow as normal operating procedure. It deliberately separates product reachability from management discipline: software can make a record available, but the property still decides who owns it and how exceptions are handled.
Name the owner. Choose the role responsible for starting and completing the process. "The office" or "the front desk" is too vague when several people share a shift.
Confirm access. Test with the real role and tenant configuration, not an unrestricted demonstration account. Check enabled modules, feature permissions and the property or outlet context.
Define the minimum input. Agree which guest, room, date, amount, document or operational detail must be present before somebody can act.
Run the normal case. Complete one realistic example from beginning to end and ask the next team member to explain the result using only the saved record.
Run the exception. Try a correction, cancellation, missing value, late change or disputed instruction that genuinely occurs at the property. Record the fallback if the product path does not cover it.
Check the hand-off. Make sure the relevant people in front desk, reservations, housekeeping and accounts can see the status they need without receiving unnecessary access to unrelated records.
Write the fallback. If the system is unavailable or the case sits outside the verified path, state who records the temporary decision and who reconciles it later.
Review after live use. Ask staff where they paused, duplicated work or returned to a spreadsheet. Fix the process before adding more fields or automation.
Decision table: evidence to collect before you approve the workflow
A manager does not need a large transformation project to evaluate this topic. A short evidence review is enough to distinguish a reachable workflow from an attractive claim. Use the table during a property review and write the answer in plain language.
Review point What to verify Evidence to keep Decision if it fails
Reachability The responsible role can open and complete the path in the correct tenant and property context. A completed test record and the role used. Do not announce the workflow; check provisioning and permissions.
Data quality The minimum information needed for the decision is present, understandable and current. The input checklist and one reviewed example. Fix the collection step before adding automation.
Ownership One role owns the next action and another can review where separation is appropriate. The operating owner and escalation path. Assign responsibility before rollout.
Exception handling A correction, cancellation or disputed case has a documented path. The tested exception and fallback note. Keep the process in controlled trial use.
Downstream hand-off The next department sees the status it needs without manual re-entry or excessive access. A hand-off check by the receiving role. Use a documented interim hand-off and reconcile it.
The honest AXOIX limit and what to review after the first live cycle
The first review should focus on behaviour, not vanity metrics. Ask the people who performed the work where they hesitated, what they entered twice and which decision still escaped into a phone call or personal message. Compare the saved record with what actually happened. If they differ, find the earliest point where context was lost.
Then separate a training problem from a product boundary. A training problem means the verified path exists but the team did not understand the trigger, required input or next action. A configuration problem means the module, property context or permission is not available to that role. A product boundary means the audited path does not support the case. Those three diagnoses require different responses; calling all of them "user error" guarantees a repeat.
Keep the limitation visible while reviewing this article: Verify the workflow and its applicability before relying on it. That boundary is part of the buying and rollout decision, not a footnote to remove from the sales conversation. Where the workflow is usable, test it honestly. Where it is partial, keep the manual control explicit. Where applicability depends on law, policy or professional judgement, confirm it with the appropriate adviser.
FAQ
Does my star rating determine my GST rate?
No. The slab follows the transaction value, not a category assigned to the property.
Do I charge different GST on a discounted room?
Possibly — this depends on the basis for computing value in the current period, which is exactly the question to put to your CA.
Is hotel restaurant GST the same as a standalone restaurant's?
Not necessarily. Hotel F&B treatment can depend on the property's room tariff, which standalone restaurants have no equivalent of.
How should a hotel test this before rolling it out?
Use the real tenant, property context and staff role. Complete one ordinary case and one exception from start to finish, then ask the receiving role to verify the saved result without relying on a private message.
What should the team do if the verified product path does not cover its case?
Keep a documented manual control, name the person responsible for reconciliation and avoid describing the unsupported step as automated. Recheck module provisioning and permissions before concluding that a capability is absent.
The bottom line
Hotel GST punishes systems that assume one rate and operators who assume their category decides it. The correct mental model is per-transaction, and the correct next step is a specific conversation with your accountant about discounted and OTA bookings.
See how GST-ready billing works in practice, how one folio per stay keeps invoices clean, or pricing.
Bill it right the first time. Start free →
Comments