Document type: Functional Product Specification Version: 1.0 Date: 8 October 2026 Scope: Functional behavior only

This document defines the functional model of the Hotel OS / PMS, from property foundation through the AI + MCP layer.

It intentionally does not define database schemas, APIs, RBAC implementation, deployment architecture, code structure, or infrastructure. Those are implementation concerns to be addressed only after the functional model is locked.

Visual flows, lifecycles and sequence diagrams for the main modules are in Appendix A — Functional Diagrams.

How to read this document

The specification is organized in Parts (I–XII). Each Part contains numbered chapters; references such as §12 or §10.2 link to them.

Core chapters follow the same pattern where it applies:

1. Definition and core question — what the module is for

2. Owns / does not own — its responsibility boundary

3. Lifecycle — its states

4. Rules and workflows — how it behaves

5. Additional capabilities — further behaviour of the same module

6. Acceptance criteria and defaults — testable scenarios and starting configuration

7. Phasing — which release each capability belongs to

Conventions:

• Diagrams are listed at the top of the chapters they illustrate and collected in Appendix A (D.1–D.84). Where a diagram and the text differ, the text is authoritative.

• Phase tags: MVP, V1, V2, Later — defined in §60.

• Part IX (Hotel OS Extensions) covers domains beyond the core PMS. They are fully specified, but most are scheduled for V2 or Later (see each chapter's Phasing table).

• MCP capabilities are named domain.verb_noun (§35.5).

Contents

• Part I — Foundations

  • 1. Product Vision

  • 2. Core Principles

  • 3. Functional Architecture

  • 4. Cross-Module Rules

  • 5. Functional UI Principles

• Part II — Property Foundation

  • 6. Organization

  • 7. Property

  • 8. Room Types

  • 9. Physical Rooms

• Part III — Commercial Selling

  • 10. Inventory and Availability

  • 11. Rate Management

  • 12. Reservations

  • 13. Groups and Corporate

  • 14. Distribution and Channel Management

  • 15. Travel Agent and Partner Commission

• Part IV — Hotel Operations

  • 16. Front Desk

  • 17. Guest Management

  • 18. Stay Management

  • 19. Housekeeping

  • 20. Maintenance and Engineering

  • 21. Service Orders and Task Management

  • 22. Checkout and Departure

• Part V — Financial Control

  • 23. Folio and Billing

  • 24. Payments

  • 25. Accounting and Ledgers

  • 26. Night Audit and Business Day

  • 27. Tax Management

  • 28. Currency and Foreign Exchange

• Part VI — Reports and Analytics

  • 29. Reports and Analytics

• Part VII — Platform and Governance

  • 30. Functional Authority, Approvals and Audit Trail

  • 31. Compliance and Jurisdiction

  • 32. Configuration, Resilience, Migration and Interfaces

• Part VIII — AI and MCP

  • 33. AI and Automation

  • 34. AI Agents

  • 35. MCP Capability Model

  • 36. AI Safety, Security and Governance

  • 37. AI Use Cases and Examples

• Part IX — Hotel OS Extensions

  • 38. Sales CRM

  • 39. Events and Banqueting

  • 40. Services, Products and Upsells

  • 41. Guest Journey and Digital Experience

  • 42. POS and Food and Beverage

  • 43. Leisure, Spa and Activities

  • 44. Loyalty and Membership

  • 45. Marketing and Guest Engagement

  • 46. Guest Experience and Service Recovery

  • 47. Central Reservations (CRS)

  • 48. Revenue Management System (RMS)

  • 49. Procurement and Stores

  • 50. Workforce and Staff Operations

  • 51. Security and Incident Management

  • 52. Access and Digital Key

  • 53. Guest Identity and Registration

  • 54. Transport, Parking and Valet

  • 55. Communication Center

  • 56. Documents, Contracts and E-signature

  • 57. Content and Merchandising

• Part X — End-to-End View

  • 58. End-to-End Lifecycles

  • 59. Cross-Module Scenarios

• Part XI — Scope and Phasing

  • 60. Phasing Model

  • 61. Release Plan by Phase

• Part XII — Quality Requirements

  • 62. Non-Functional Requirements

• Appendix A — Functional Diagrams

Part I — Foundations

1. Product Vision

The product is not just a reservation system. It is an AI-native Hotel Operating System that manages the complete hotel lifecycle:

flowchart TD
    n1["Organization"]
    n2["Property"]
    n3["Rooms / Inventory / Availability / Rates"]
    n4["Reservations / Groups / Distribution"]
    n5["Guests / Front Desk / Stays"]
    n6["Folio / Payments"]
    n7["Housekeeping / Maintenance"]
    n8["Checkout"]
    n9["Night Audit"]
    n10["Reports / Analytics"]
    n11["Automation"]
    n12["AI Agents"]
    n13["MCP Business Capabilities"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7
    n7 --> n8
    n8 --> n9
    n9 --> n10
    n10 --> n11
    n11 --> n12
    n12 --> n13

The core product principle is:

Every module owns a clear business responsibility, while all modules operate on one shared hotel reality.

Product definition

The Hotel OS is a unified hotel operations platform where:

flowchart TD
    n1["Commercial demand"]
    n2["Inventory + Rates"]
    n3["Reservations"]
    n4["Guest arrival"]
    n5["Stay operations"]
    n6["Financial operations"]
    n7["Room recovery"]
    n8["Daily business control"]
    n9["Performance analytics"]
    n10["AI-driven intelligence"]
    n11["Controlled action through business capabilities"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7
    n7 --> n8
    n8 --> n9
    n9 --> n10
    n10 --> n11

The system is designed so that the same hotel truth drives:

• PMS

• Front Desk

• Booking Engine

• OTAs

• Housekeeping

• Maintenance

• Finance

• Groups

• Analytics

• AI Agents

No AI agent should need to create its own alternate interpretation of inventory, rates, reservations, payments, or room status.

The agent asks the Hotel OS.

The Hotel OS applies its rules.

The Hotel OS returns the authoritative result.

The agent explains or acts based on that result.

2. Core Principles

Diagrams: D.7

2.1 Organization vs Property

Organization = manages the HOTEL BUSINESS
Property     = operates the actual HOTEL

An organization may have multiple properties:

Otonomiq Hospitality
├── Otonomiq Delhi
├── Otonomiq Goa
└── Otonomiq Jaipur

Organization-level data and settings can be shared by all of its properties. Property-level functionality runs the day-to-day operation of one physical hotel.

A common functional pattern is:

flowchart TD
    n1["Organization Default"]
    n2["Property Override"]
    n3["Actual Property Behavior"]
    n1 --> n2
    n2 --> n3

2.2 Category vs Physical Unit

Room Type    = what is being sold
Physical Room = which actual room exists

Example:

Deluxe King
├── 201
├── 202
├── 203
└── 204

2.3 Capacity vs Bookability

Inventory   = how much accommodation capacity exists
Availability = whether a specific request can actually be sold

A room may belong to sellable inventory but still not be immediately assignable because it is dirty, unavailable operationally, under maintenance, or restricted by booking rules.

2.4 Booking vs Stay

Reservation = commercial booking / promise
Stay        = actual accommodation lifecycle

A reservation may never become a stay — for example, when it is cancelled or the guest does not arrive (no-show).

2.5 Account vs Money

Folio   = account of charges / credits / balance
Payment = actual money movement or payment attempt

2.6 Readiness vs Functionality

Housekeeping = room cleanliness / readiness
Maintenance  = physical functionality / engineering condition

A room can be clean but broken, or working but dirty.

2.7 Deterministic Automation vs AI

Use deterministic automation when the outcome is known.

Examples:

Checkout completed → Create departure housekeeping task

Maintenance completed → Create post-maintenance cleaning task

Use AI when reasoning is needed:

• Which rooms should housekeeping clean first?

• Why did revenue fall?

• Should BAR increase?

• Which maintenance issue is most urgent?

2.8 Explainability Principle

Every important hotel number or state should be explainable.

Examples:

• Why unavailable?

• Why this rate?

• Why room not ready?

• Why payment pending?

• Why audit blocked?

• Why revenue changed?

• Why channel mismatch?

• Why guest is high priority?

The Hotel OS should prefer:

State + Reason + Evidence + Next Action

over:

Status only

2.9 Exception-First Design

Exceptions are not edge cases in a PMS. They are a core part of hotel operations.

Major exception families:

• Inventory Exception

• Rate Exception

• Reservation Exception

• Room Assignment Exception

• Guest Exception

• Payment Exception

• Folio Exception

• Housekeeping Exception

• Maintenance Exception

• Checkout Exception

• Group Exception

• Distribution Exception

• Audit Exception

Every exception should ideally expose:

• What happened

• Why

• Impact

• Owner

• Recommended action

• Status

• History

2.10 Hotel Operational Readiness Model

A property is operationally healthy only when several domains agree.

flowchart TD
    n1["ROOM EXISTS"]
    n2["ROOM FUNCTIONAL"]
    n3["ROOM CLEAN"]
    n4["ROOM INSPECTED"]
    n5["ROOM ASSIGNABLE"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5

Separately:

INVENTORY SELLABLE

These concepts must not be merged into one status.

2.11 Hotel Business Truth Model

The Hotel OS should always be able to answer these seven questions:

1. What room/category exists?

2. How much capacity exists?

3. Can I sell it for this request?

4. What rate/terms apply?

5. Who booked it / who is staying?

6. What happened operationally?

7. What money was charged/paid?

Then:

8. Is the business day reconciled?

9. What is hotel performance?

10. What should we do next?

3. Functional Architecture

Diagrams: D.1, D.2, D.3

3.1 Five functional layers

Layer 1 — Property Foundation

• Organization

• Property

• Room Types

• Physical Rooms

Question:

What hotel/business exists?

Layer 2 — Commercial Selling

• Inventory

• Availability

• Rate Management

• Reservations

• Groups

• Distribution

Question:

What can we sell, when, to whom, through which channel, and at what price?

Layer 3 — Hotel Operations

• Front Desk

• Guest

• Stay

• Housekeeping

• Maintenance

• Checkout

Question:

What is happening to guests and rooms right now?

Layer 4 — Financial Control

• Folio

• Payments

• Accounting and Ledgers

• Night Audit

• Tax

• Currency and FX

Question:

What is owed, how did money move, and is the business day reconciled?

Layer 5 — Intelligence

• Reports

• Analytics

• Automation

• AI Agents

• MCP

Question:

What happened, why did it happen, what is likely to happen, and what should we do?

3.2 Functional hierarchy

flowchart TD
    n1["Organization"] --> n2["Property"] --> n3["Room Types"] --> n4["Physical Rooms"]
    n4 --> n5["Inventory"] --> n6["Availability"] --> n7["Rate Management"] --> n8["Reservations"]
    n18["Groups / Corporate"] --> n8
    n19["OTA / Distribution"] --> n8
    n8 --> n9["Front Desk"] --> n10["Guest Management"] --> n11["Stay Management"]
    n11 --> n14["Housekeeping"]
    n11 --> n15["Maintenance"]
    n11 --> n12["Folio / Billing"] --> n13["Payments"]
    n11 --> n16["Checkout"]
    n13 --> n17["Night Audit"]
    n16 --> n17
    n17 --> n20["Reports & Analytics"] --> n21["AI / Automation"]

Additional cross-cutting layer:

flowchart TD
    n1["AI Agents"]
    n2["Agent Skills / Context / Policies"]
    n3["MCP Business Capabilities"]
    n4["Hotel Business Logic"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

3.3 Module ownership matrix

3.4 Module Definitions

Organization
= business-wide control plane

Property
= actual hotel operational plane

Room Type
= sellable accommodation category

Physical Room
= real hotel unit

Inventory
= capacity

Availability
= bookability

Rate Management
= pricing + commercial rules

Reservation
= commercial booking agreement

Guest
= permanent person identity

Front Desk
= real-time hotel operations workspace

Stay
= actual guest accommodation

Folio
= financial account

Payment
= actual money movement

Housekeeping
= cleanliness / readiness

Maintenance
= engineering / functionality

Checkout
= departure completion

Night Audit
= business-day control / close

Group
= related commercial / operational collection

Distribution
= external sales channel control

Reports
= facts / data

Analytics
= interpretation / comparison / trends

Automation
= deterministic workflows

AI
= reasoning / prediction / prioritization / orchestration

MCP
= business capability interface for agents

3.5 Module dependencies

flowchart LR
    RT["Room Types"] --> PR["Physical Rooms"]
    RT --> INV["Inventory"]
    RT --> RM["Rate Management"]
    PR --> HK["Housekeeping"]
    PR --> MT["Maintenance"]
    PR --> RA["Room Assignment"]
    INV --> AV["Availability"]
    INV --> RES["Reservations"]
    INV --> DIST["Distribution"]
    INV --> GRP["Groups"]
    RM --> AV
    RM --> RES
    RM --> DIST
    RM --> ANA["Analytics"]
    RES --> FD["Front Desk"]
    RES --> ST["Stay"]
    RES --> FO["Folio"]
    RES --> GU["Guest"]
    GU --> RES
    ST --> HK
    ST --> MT
    ST --> FO
    ST --> CO["Checkout"]
    FO --> PAY["Payments"]
    PAY --> FO
    FO --> ACC["Accounting / Ledgers"]
    PAY --> ACC
    ACC --> NA["Night Audit"]
    HK --> FD
    MT --> HK
    MT --> INV
    CO --> HK
    CO --> GU
    NA --> ANA
    GRP --> RES
    GRP --> FO
    DIST --> RES
    ANA --> AI["AI / Automation"]

3.6 Master Mental Model

flowchart TD
    ORG["ORGANIZATION"] --> PROP["PROPERTY"]
    PROP --> RT["ROOM TYPES"]
    PROP --> PR["PHYSICAL ROOMS"]
    PROP --> POL["POLICIES"]
    RT --> INV["INVENTORY"]
    PR --> INV
    INV --> AV["AVAILABILITY"]
    AV --> RM["RATE MANAGEMENT"]
    RM --> RES["RESERVATIONS"]
    RM --> GRP["GROUPS"]
    RM --> DIST["DISTRIBUTION"]
    RES --> GU["GUEST"]
    GRP --> GU
    DIST --> GU
    GU --> FD["FRONT DESK"]
    FD --> ST["STAY"]
    ST --> FO["FOLIO"]
    ST --> HK["HOUSEKEEPING"]
    ST --> MT["MAINTENANCE"]
    FO --> PAY["PAYMENTS"]
    HK --> RR["ROOM READY"]
    MT --> RR
    PAY --> CO["CHECKOUT"]
    RR --> CO
    CO --> NA["NIGHT AUDIT"]
    NA --> BD["BUSINESS DATE"]
    BD --> AN["ANALYTICS"]
    AN --> AI["AI / AUTOMATION"]
    AI --> SK["AGENT SKILLS"]
    SK --> MCP["MCP TOOLS"]

3.7 Scope Classification

Core PMS

• Organization

• Property

• Rooms

• Inventory

• Availability

• Rates

• Reservations

• Guest

• Front Desk

• Stay

• Folio

• Accounting

• Payments

• Housekeeping

• Maintenance

• Checkout

• Night Audit

• Groups

• Distribution

• Reports

Hotel OS extensions

• Sales CRM

• Events / Banqueting

• POS / F&B

• Guest Journey

• Leisure / Spa / Activities

• Loyalty

• Marketing / Guest Engagement

• Guest Experience

• Services / Upsells

• Central Reservations

• Revenue Management

• Procurement / Stores

• Workforce

• Security / Incidents

• Access / Digital Key

• Guest Identity / Registration

• Transport / Parking / Valet

• Communication Center

• Documents / Contracts / E-signature

• Content / Merchandising

External / adjacent systems (integrated, not built)

• Full Accounting / General Ledger

• Payroll

• HRIS

• Banking

• Enterprise Procurement

• Legal Document Systems

• Government Filing Platforms

• Enterprise CRM

• Identity Provider

• Data Warehouse

Optional vertical packs

• Casino / Gaming

• Golf

• Marina / Water Sports

• Ski / Mountain

• Medical / Wellness

• Serviced Apartments

• Hostel / Dormitory

• Cruise / Floating Accommodation

• Other Specialized Models

Each vertical is added only when the target property type requires it.

3.8 Cross-cutting Capabilities

These are reusable business capabilities rather than isolated modules:

• Tax / Charge Rules

• Currency / FX

• Resource Scheduling

• Service Order Management

• Task / Work Management

• Notification / Communication

• Document Management

• Business Rules / Policy Engine

• Promotion / Voucher Engine

• Product / Service Catalog

• Approval Workflow

• Exception Management

• Global Search

• Timeline / Activity Feed

• Identity / Registration

• Audit Trail / History

Resource scheduling

Rooms are resources, but so are:

• Function Spaces

• Spa Rooms

• Therapists

• Vehicles

• Cabanas

• Equipment

• Conference Equipment

• Maintenance Technicians

• Housekeeping Attendants

Resource scheduling is a shared capability used by Events, Leisure, Transport, Maintenance and Operations.

3.9 Feature definition standard

Every feature is defined by:

• Purpose

• Owner

• Actor

• Trigger

• Lifecycle

• States

• Inputs

• Validation

• Decision points

• Exceptions

• Financial effect

• Inventory effect

• Guest effect

• Operational effect

• Cross-module effect

• Notifications

• History / audit

• Automation opportunity

• AI opportunity

• MCP capability

4. Cross-Module Rules

Diagrams: D.48

4.1 General consistency rules

These rules should apply across the entire Hotel OS.

Rule G1 — One concept, one owner

Example:

flowchart TD
    n1["Guest identity"]
    n2["Guest Management"]
    n3["Reservation"]
    n4["Reservations"]
    n5["Stay"]
    n6["Stay Management"]
    n7["Money movement"]
    n8["Payments"]
    n1 --> n2
    n3 --> n4
    n5 --> n6
    n7 --> n8

Rule G2 — Don't duplicate business truth

Example:

• Rate Management owns rate logic.

• Distribution does not create another rate engine.

Rule G3 — Preserve historical reality

Confirmed bookings, posted financial events, completed stays and audit results should not silently change because today's configuration changed.

Rule G4 — Every important state has an explanation

• Unavailable because...

• Payment pending because...

• Room blocked because...

• Audit blocked because...

Rule G5 — Physical reality and commercial reality are separate

Physical Room ≠ Inventory ≠ Reservation

Rule G6 — Operational completion and financial completion are separate where required

Checkout ≠ Folio closure in every scenario

Rule G7 — Automation should replace deterministic manual work

Do not use an LLM where a fixed business rule is sufficient.

4.2 Domain rules

Rule D1 — Room Move

Same room type move → Inventory usually unchanged

However, the room assignment history changes and the old room usually becomes dirty.

Rule D2 — Dirty room

Dirty ≠ Inventory Removed

Rule D3 — Maintenance complete

Maintenance complete ≠ Guest-ready

Housekeeping and inspection may still be required.

Rule D4 — Checkout

Checkout ≠ Room Ready

Checkout normally produces:

Vacant + Dirty

Rule D5 — Reservation price

Confirmed historical price should not silently change because current rates changed.

Rule D6 — Payment

A payment browser result is not the authoritative payment outcome.

Rule D7 — Folio correction

Never silently delete posted financial history.

Rule D8 — Guest identity

Do not create duplicate guest profiles when an existing profile can be matched.

Rule D9 — Distribution

External channel failure must be visible; internal success does not mean channel sync succeeded.

Rule D10 — Night Audit

Night Audit detects domain exceptions; the owning domain resolves them.

Rule D11 — AI

AI never becomes the final source of truth for hotel state.

Rule D12 — MCP

MCP exposes business capabilities to agents, not raw database changes.

5. Functional UI Principles

Every major domain should have:

• Dashboard

• List / Board

• Search

• Filter

• Detail

• Timeline / History

• Actions

• Exceptions

• Reports

For operational modules, prioritize action-oriented views over static data tables.

Examples:

flowchart TD
    n1["Front Desk"]
    n2["Today / Arrival Board"]
    n3["Housekeeping"]
    n4["Housekeeping Board"]
    n5["Maintenance"]
    n6["Work Board"]
    n7["Distribution"]
    n8["Channel Command Center"]
    n9["Night Audit"]
    n10["Audit Control Center"]
    n11["Groups"]
    n12["Group Command Center"]
    n1 --> n2
    n3 --> n4
    n5 --> n6
    n7 --> n8
    n9 --> n10
    n11 --> n12

Part II — Property Foundation

6. Organization

Related: central reservations across properties (§47).

Definition

The organization is the hotel company/group that owns or manages one or more properties.

Example:

Otonomiq Hospitality
├── Otonomiq Delhi
├── Otonomiq Goa
└── Otonomiq Jaipur

Organization functionality

• Organization Profile

• Properties

• Property Switching

• People / Users

• Brand

• Central Guest Data

• Corporate Accounts

• Travel / Business Partners

• Central Policies

• Shared Configuration

• Integrations

• Notifications / Templates

• Central Reporting

• Administration

Functional capabilities

Organization Profile

• Legal/business identity

• Company information

• Contact information

• Branding context

• Organization-level business information

Property Management

• Create

• View

• Activate

• Deactivate

• Archive

• Switch Property

Central Guest Data

One guest identity can be reused across multiple properties.

Guest Rahul
├── Delhi stay
├── Goa stay
└── Jaipur stay

Corporate Accounts

A corporate account can do business with several properties of the organization.

Shared Policies

Organization Default Policy → Property Override

Central Reporting

flowchart LR
    i0["Property A"] --> OUT
    i1["Property B"] --> OUT
    i2["Property C"] --> OUT
    OUT["Organization View"]

Key principle

Organization owns business-wide identity and centralized relationships.

It does not run day-to-day room operations; those belong to each property.

Phasing

7. Property

Diagrams: D.5, D.6, D.54

Definition

A property is one physical accommodation business, such as a hotel or resort.

Property owns

• Hotel Identity

• Location

• Contact

• Legal Context

• Timezone

• Currency

• Business Date

• Buildings

• Floors

• Sections

• Amenities

• Property Policies

• Tax Context

• Content

• Property Integrations

• Notifications

• Inventory

• Reservations

• Operations

Property dashboard

The dashboard is action-oriented and shows:

• Occupancy

• ADR

• RevPAR

• Arrivals

• Departures

• In-House

• Ready Rooms

• Dirty Rooms

• Maintenance

• Payment Issues

• VIP Arrivals

Property lifecycle

stateDiagram-v2
    [*] --> Draft
    Draft --> Setup : configuration started
    Setup --> Ready : readiness checks pass
    Ready --> Open : opening date
    Open --> TemporarilyClosed : closure
    TemporarilyClosed --> Open : reopened
    Open --> Archived : permanent closure, no future reservations
    TemporarilyClosed --> Archived : permanent closure, no future reservations
    Archived --> [*]
    state "Temporarily closed" as TemporarilyClosed

Property readiness

Before a property can open, these must be in place:

• Room Types configured

• Physical Rooms configured

• Inventory configured

• Active Rate Plan

• Tax configured

• Payment capability

• Property operating information

Business Date

Each property has its own business date, which can differ from the calendar date — for example, shortly after midnight.

Example:

Calendar:
Oct 9, 01:30

Property Business Date:
Oct 8

Time unit and day boundary

The property defines its supported time units (night, day-use window, hour block, month), default check-in / check-out times and the business-day boundary. Inventory, restrictions and rates are evaluated per time unit. See §32.

Configuration / feature controls

Property behaviour is driven by configurable controls (Organization Default → Property Override). Every configuration change is audited and effective-dated. See §30.

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

8. Room Types

Definition

Room Type is the sellable accommodation category.

Example:

• Deluxe King

• Standard Twin

• Executive Suite

Room Type owns

• Name

• Code

• Status

• Description

• Guest-facing content

• Capacity

• Adult capacity

• Child capacity

• Bed configuration

• Default room size

• Default view

• Smoking classification

• Accessibility features

• Amenities

• Images

• Sellable/internal classification

• Upgrade/downgrade relationships

Room Type does NOT own

• Daily pricing

• Seasonal pricing

• MinLOS / MaxLOS

• CTA / CTD

• Stop Sell

• Reservations

• Guests

• Folio

• Payments

• Housekeeping status

• Maintenance status

Guest-facing representative images

Room Type images represent the category, not necessarily the exact physical room assigned.

Room Type and Physical Room

Room Type:
Deluxe King

Physical:
201
202
203
204

A physical room can override some of its room type's defaults, such as actual size, view or bed.

Advanced future concepts

• Virtual / Derived Room Types

• Equivalent Room Types

• Connecting Room Relationships

• Room Type Consumption Rules

Phasing

9. Physical Rooms

Diagrams: D.7, D.8, D.9, D.10

Definition

A Physical Room is an actual hotel accommodation unit.

Owns

• Room Number / Name

• Room Type

• Building

• Floor

• Wing / Section

• Actual Size

• Actual View

• Actual Bed

• Balcony

• Accessibility

• Special Features

• Operational State

• Housekeeping State

• Occupancy State

• Blocks

• Current Assignment

• Assignment History

• Connecting / Adjoining Relationships

• Maintenance Relationship

Room lifecycle

• Draft

• Active

• Inactive (temporarily outside inventory, e.g. long renovation)

• Retired

Out of Order and Out of Service are not lifecycle states. They are dated operational blocks on an Active room — see "Operational blocks" below.

Room status is multi-dimensional

Do not use one generic room status for everything.

• Occupancy

• Housekeeping Condition

• Operational Condition

• Maintenance

• Assignment

Example:

Room 204

Occupancy: VACANT
Housekeeping: INSPECTED
Operational: SELLABLE
Maintenance: NONE

Result: READY

Another:

Room 205

Occupancy: VACANT
Housekeeping: DIRTY
Operational: SELLABLE

Result: NOT READY

Another:

Room 206

Occupancy: VACANT
Housekeeping: INSPECTED
Operational: OUT OF ORDER

Result: NOT AVAILABLE

Room moves

Room moves are first-class operations and must preserve history.

Upgrade/downgrade

Preserve:

Booked Room Type

separately from:

Actual Assigned Room Type

Room retirement

Room retirement must preserve historical identity and prior stays.

Operational blocks — OOO / OOS / House Use

Each block is a dated record:

• Room

• From / Through

• Reason Code

• Expected Return Time

• Return Housekeeping Status

• Linked Work Order

• Created By

Effect on selling and KPIs:

• The room returns automatically at the end of the block with its return housekeeping status.

Room flags

Do Not Move = assigned room is locked; only authorized users can reassign
Room Condition = temporary marker (show room, connecting door open, minibar removed) that can hide the room from assignment search

Room readiness lifecycle

flowchart TD
    n1["Occupied"]
    n2["Checkout"]
    n3["Vacant + Dirty"]
    n4["Cleaning"]
    n5["Clean"]
    n6["Inspection"]
    n7["Inspected"]
    n8["Ready"]
    n9["Assignment"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7
    n7 --> n8
    n8 --> n9
    n9 --> n1

Maintenance side path:

flowchart TD
    n1["Maintenance Issue"]
    n2["OOO / OOS"]
    n3["Repair"]
    n4["Housekeeping"]
    n5["Inspection"]
    n6["Ready"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Phasing

Part III — Commercial Selling

10. Inventory and Availability

Diagrams: D.11, D.12, D.13, D.14, D.15, D.22

10.1 Inventory

Inventory is the accommodation capacity for each room type on each date.

Example:

10 Deluxe rooms

Date-based inventory should account for:

• Physical Capacity

• Operational Capacity

• Reservations

• Group Allocations

• Blocks

• OOO

• OOS

• Overbooking allowance

• Manual adjustments

• Remaining inventory

• Available-to-sell

Nightly consumption

For a stay:

Arrival: Oct 12
Departure: Oct 15

Inventory consumption nights:

• Oct 12

• Oct 13

• Oct 14

The departure date is not consumed, because the guest does not stay that night.

For day-use and hourly products the consumed unit is the configured time unit, not a night (§32).

Inventory explanation

Every availability number should be explainable.

Example:

Deluxe — Oct 12

Physical:       10
Reservations:    8
OOO:              1
Block:             1
Remaining:         0

Availability decomposition

Physical rooms
− Out of Order
= Rooms in inventory
− House Use (operational blocks and house-use reservations, counted once)
− Confirmed reservations that deduct (excluding house use)
− Optional / held reservations and active booking holds
− Unpicked group block (deducting statuses)
− Protected / allocated inventory
+ Overbooking allowance (sell limit)
= Available to sell

Non-deducting records (waitlist, tentative/prospect, inquiry) are shown but do not consume inventory.

10.2 Availability

Availability asks:

Can this guest request actually be sold?

It combines:

• Inventory

• Stay Dates

• Occupancy

• Rate

• Restrictions

• Channel

• Promotion

• Commercial Rules

Restrictions

• MinLOS

• MaxLOS

• CTA

• CTD

• Stop Sell

• Advance Booking

• Cutoff

Date-range logic

A multi-night stay is available only if all required nights are available and compatible with restrictions.

Restriction semantics

Both "on arrival" and "stay-through" variants must exist; they produce different answers for the same stay.

Restriction levels, from broad to narrow:

• House

• Room Class

• Room Type

• Rate Category

• Rate Plan

• Channel

• The most restrictive applicable restriction wins.

• Restrictions are not inherited by derived rate plans unless explicitly configured.

• Overlapping restrictions merge; clearing part of a range splits it.

• Automatic rate strategies (open / close by occupancy) may set restrictions; the explanation must show whether a restriction is manual or automatic.

Temporary booking hold

Conceptual flow:

flowchart TD
    n1["Search"]
    n2["Temporary Hold"]
    n3["Payment / Confirmation"]
    n4["Confirmed"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

If hold expires:

flowchart TD
    n1["Hold"]
    n2["Expired"]
    n3["Inventory Released"]
    n1 --> n2
    n2 --> n3

Availability explanation

Example:

No availability because:

Inventory: 2 rooms
Minimum stay: 4 nights
Guest requested: 3 nights

Turnaways

When a request cannot be booked, record a turnaway:

Denial = hotel could not offer (no availability / restriction)
Regret = guest declined the offer (price / product)

Turnaways feed demand analytics and RMS.

Overbooking and walking

flowchart TD
    n1["Arrival day: confirmed arrivals exceed assignable rooms"] --> n0{"Out of Service last-resort room or upgrade absorbs it?"}
    n0 -->|Yes| ok["Assign and record"]
    n0 -->|No| n2["Identify walk candidate (rules: not VIP, not loyalty, short stay, rate)"]
    n2 --> n3["Arrange alternative property"]
    n3 --> n4["Transport / compensation"]
    n4 --> n5["Reservation marked WALKED (not cancelled, not no-show)"]
    n5 --> n6["Costs posted to an internal account"]

Inventory lifecycle

flowchart TD
    n1["Physical Capacity"]
    n2["Operational Capacity"]
    n3["Group / Other Allocations"]
    n4["Reservations"]
    n5["Cancellations / Changes"]
    n6["Checkout / Releases"]
    n7["Current Sellable Capacity"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7

Overbooking can deliberately sell beyond capacity within the approved sell limit; selling beyond the sell limit needs overbooking authority (§30).

Additional capabilities

Inventory and availability also support:

• Waitlist Demand

• Inventory Pools

• Equivalent Room Types

• Virtual / Derived Room Types

• Inventory Protection

• Availability Alerts

• Overbooking Optimization

Equivalent room type example

Guest booked:
Deluxe King

Property rule:
Deluxe King ≈ Deluxe Twin

Assignment may use equivalent type
if guest/product rules permit.

Inventory protection

Revenue Manager can reserve some capacity for:

• High-value demand

• Corporate

• Groups

• Direct channel

• Last-room availability

The reason for the protection should be visible.

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

11. Rate Management

Diagrams: D.16, D.17, D.18, D.19, D.20, D.22, D.24

Related: revenue management recommendations and autopilot (§48), loyalty qualifying rates (§44).

Rate Management is pricing + commercial selling rules, not a static price table.

Core question:

For this guest, dates, room type, channel, and conditions, what price and booking terms should be offered?

Rate calculation flow

flowchart LR
    i0["Room Type"] --> OUT
    i1["Rate Plan"] --> OUT
    i2["Stay Dates"] --> OUT
    i3["Occupancy"] --> OUT
    i4["Inventory"] --> OUT
    i5["Restrictions"] --> OUT
    i6["Market / Guest Segment"] --> OUT
    i7["Channel"] --> OUT
    i8["Promotions"] --> OUT
    i9["Packages"] --> OUT
    i10["Business Rules"] --> OUT
    OUT["Final Offer"]

Rate concepts

• Rate Plan / Rate Code

• Rate Group / Category

• Sell Window

• Stay Window

• Pricing Schedule

• Daily Rates

• Seasons

• Day-of-Week Pricing

• Daily Overrides

• Occupancy Pricing

• Additional Adult Pricing

• Child Pricing / Age Buckets

• Derived Rates

• BAR

• Dynamic Pricing

• Rate Floor

• Rate Ceiling

• MinLOS

• MaxLOS

• CTA

• CTD

• Cutoff

• Advance Purchase

• Stop Sell

• Promotions

• Packages

• Negotiated Rates

• Corporate Rates

• Public / Private / Confidential Access

• Distribution Mapping

• Approval

• Publishing

• History / Audit

• Why this rate?

• Why unavailable?

Rate hierarchy

flowchart TD
    n1["Rate Plan"]
    n2["Pricing Schedule"]
    n3["Season / Date Range"]
    n4["Day of Week"]
    n5["Daily Override"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5

Rate structure

flowchart TD
    n1["Rate Class (e.g. Negotiated)"]
    n2["Rate Category (e.g. Government)"]
    n3["Rate Plan (e.g. GOV-BB)"]
    n1 --> n2
    n2 --> n3

Sell window = dates the rate may be booked
Stay window = dates the rate may be stayed

Pricing models

• Per room

• Per person

• Occupancy-based (adjustment below / above base occupancy)

• Extra adult / extra child / extra bed

• Age categories (configurable age bands)

• Length-of-stay / tiered pricing

Derived rates

Example:

BAR = ₹10,000

Corporate = BAR - 15%
         = ₹8,500

Breakfast = BAR + ₹1,000
          = ₹11,000

Derived rates should support:

• Percentage Adjustment

• Flat Adjustment

• Rounding

• Minimum

• Maximum

A rate must never derive from itself, directly or through a chain of derived rates.

Derived-rate rules:

• The derived rate's daily prices are read-only; they follow the base rate.

• Whether extra-person amounts are also derived must be configured.

• Restrictions are not inherited from the base rate (see §10.2).

• Chain depth is limited and configured.

Promotions

A promotion is a separate commercial layer applied on top of rate plans; a promotion does not need its own rate plan.

Package vs add-on

Package = part of the commercial offer
Add-on  = optional purchase later

Board basis / meal plan

• Room Only

• Bed & Breakfast

• Half Board

• Full Board

• All Inclusive

Board basis is a standard package attached to a rate plan and must be mapped to every channel.

Package posting

Posting type     = included in rate / separate line / combined line
Calculation rule = flat / per person / per adult / per child / per room
Posting rhythm   = every night / arrival night / last night / selected weekdays / once per stay
Allowance        = value available to consume (e.g. breakfast ₹600 per adult)

• Unconsumed allowance → package profit; consumption above allowance → overage charged to the guest.

• Allowances are tracked in the Package Ledger (§25).

Rate policies

Rate plans may carry:

• Cancellation

• Deposit

• Payment Terms

Guarantee and payment policy

Guarantee types:

• Held until a release time (e.g. 6 PM)

• Card guarantee (tokenized payment account)

• Prepayment

• Company / direct bill

Payment policy schedule:

Amount   = percentage / fixed / number of nights
Trigger  = confirmation / days before arrival / check-in / departure
Action   = charge / pre-authorize / request payment link

Policy precedence when several apply:

flowchart LR
    n3["Manual rule on the reservation"] --> n1["Rate Plan rule"] --> n2["Reservation Type rule"]

The first rule found in this order applies (manual first). Only one deposit rule and one cancellation rule are active on a reservation at a time.

Tax separation

flowchart TD
    n1["Rate Engine"]
    n2["Tax Engine"]
    n3["Final Total"]
    n1 --> n2
    n2 --> n3

Rate snapshot

When a reservation is confirmed, the agreed prices are stored as a snapshot.

Later rate changes must not change the price of an already confirmed reservation.

Modification

flowchart TD
    n1["Quote / Recalculate"]
    n2["Show Difference"]
    n3["Confirm"]
    n4["Commit"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Rate governance

Lifecycle:

stateDiagram-v2
    [*] --> Draft
    Draft --> PendingApproval : submit, approval required by rule
    Draft --> Published : approval not required by rule
    PendingApproval --> Approved : approver accepts
    PendingApproval --> Draft : rejected with reason
    Approved --> Published : publish to PMS and channels
    Published --> Draft : new version
    Published --> Retired : end of sell window
    Retired --> [*]
    state "Pending approval" as PendingApproval
    note right of PendingApproval : default, public BAR changes need approval

Revenue Management

In a later phase, revenue management uses these inputs:

flowchart LR
    i0["Occupancy"] --> OUT
    i1["Pickup"] --> OUT
    i2["Pace"] --> OUT
    i3["Forecast"] --> OUT
    i4["Competitor / Market"] --> OUT
    i5["Events"] --> OUT
    OUT["Recommended BAR"]
    OUT --> o0["Rate Strategy"]

Advanced capabilities:

• Dynamic BAR

• Hurdle Rates

• AI Pricing Recommendations

• Automated Pricing

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

12. Reservations

Diagrams: D.3, D.21, D.23, D.24, D.25, D.26

Definition

A reservation is the commercial booking / promise to provide accommodation.

Lifecycle

Canonical lifecycle:

stateDiagram-v2
    [*] --> Draft
    Draft --> Optional : hold
    Draft --> Confirmed : book with guarantee
    Draft --> Waitlisted : no availability
    Draft --> [*] : quote discarded
    Optional --> Confirmed : confirmed
    Optional --> Expired : release time passed
    Optional --> Cancelled
    Waitlisted --> Confirmed : offer accepted (see Waitlist)
    Waitlisted --> Expired
    Waitlisted --> Cancelled
    Confirmed --> InHouse : check-in
    Confirmed --> Cancelled
    Confirmed --> NoShow : not arrived by business-date close
    Confirmed --> Walked : relocated by hotel
    InHouse --> CheckedOut : checkout
    Cancelled --> Confirmed : reinstate, arrival ≥ business date
    NoShow --> Confirmed : reinstate, departure ≥ business date, arrival reset
    CheckedOut --> InHouse : checkout reinstatement with authority
    CheckedOut --> [*]
    state "Optional / Held" as Optional
    state "In-House" as InHouse
    state "Checked-Out" as CheckedOut
    state "No-show" as NoShow
    note right of Draft : quote, does not consume inventory
    note right of Confirmed : Due In / Due Out are views, not statuses

Notes:

• Due In and Due Out are operational views (arrival or departure on the business date), not statuses.

• Financial completion is folio closure (§23), not a reservation status.

Reservation owns

• Confirmation Number

• Stay Dates

• Room Counts

• Guest Counts

• Room Type

• Rate Plan

• Booked Pricing Snapshot

• Channel

• Source

• Market

• Reservation Type

• Expected Arrival

• Policies Applied

• Deposit Requirement

• Special Requests

• Alerts

• Notes

• Traces / Tasks

• Guests / Contacts

• Linked Reservations

• History

• Documents

Reservation relationships

• Guest

• Property

• Room Type

• Physical Room

• Rate Plan

• Inventory

• Folio

• Payments

• Company

• Travel Agent

• Group

• Channel

Important distinctions

• Reservation ≠ Guest

• Reservation ≠ Room Assignment

• Reservation ≠ Folio

• Reservation ≠ Stay

• Reservation ≠ Payment

Reservation types and inventory deduction

Every reservation has a reservation type that defines:

• Deducts inventory? (yes / no)

• Guarantee required

• Required fields (address, phone, arrival time, payment method)

• Auto-release / auto-cancel rule

Examples:

flowchart TD
    n1["Guaranteed (card / prepaid / company)"]
    n2["deducts"]
    n3["Non-guaranteed, held until 6 PM"]
    n4["deducts until release time"]
    n5["Tentative / Prospect"]
    n6["does not deduct"]
    n7["Waitlist"]
    n1 --> n2
    n3 --> n4
    n5 --> n6
    n7 --> n6

Day-use and hourly reservations

A day-use reservation is a zero-night stay inside one business date. Hourly products use the property's hour time unit (§32). Both use the same reservation model.

Complimentary and house-use reservations

Complimentary = free stay for a guest (marketing / goodwill); needs comp authorization
House Use     = room used by the hotel itself (staff, manager on duty)

Both are flagged on the rate plan and excluded from paid-room KPIs (§29).

Multi-room reservations

One booking can contain several rooms; each room is its own reservation, managed together under the booking.

Linked reservations

Allow related reservations to be connected without forcing them into one reservation.

Sharers

Support:

• Primary Guest

• Accompanying Guest

• Sharer

Distinction:

Accompanying Guest = additional person on the same reservation and folio
Sharer             = own reservation and own folio, same room

Sharer rate split options:

Entire = one sharer pays the full rate
Split  = rate divided equally
Full   = each sharer pays a full rate
Custom = manual split

Contact vs staying guest

The person who makes or manages the booking (the contact) may be different from the person who stays.

Special request vs preference vs requirement

Preference = guest pattern / desire
Request    = specific stay request
Requirement = must satisfy

Notes / alerts / traces

Keep these concepts separate:

Note = information
Alert = attention warning
Trace / Task = action that needs to happen

Modification

flowchart TD
    n1["Current Reservation"]
    n2["Quote Change"]
    n3["Availability / Rate Validation"]
    n4["Show Impact"]
    n5["Confirm"]
    n6["Commit"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6

Cancellation

flowchart TD
    n1["Calculate Penalty / Refund"]
    n2["Show Inventory Impact"]
    n3["Confirm"]
    n4["Cancel"]
    n5["Release Inventory"]
    n6["Apply Financial Consequences"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6

No-show

A no-show is handled separately from both cancellation and checkout.

Reinstatement

A cancelled, no-show or checked-out reservation can be reinstated through a controlled workflow when property rules allow it.

Rules:

flowchart LR
    n1["Cancelled"]
    n2["reinstate only if arrival ≥ current business date"]
    n3["No-show"]
    n4["reinstate only if departure ≥ current business date; arrival resets to today"]
    n5["Checked-out"]
    n6["reinstate to In-House only on the same business date, if the room is not reassigned; folio reopened with authority"]
    n1 --> n2
    n3 --> n4
    n5 --> n6

Reinstatement re-checks availability and may require overbooking authority (§30).

Reservation timeline

Maintain an event history:

• Created

• Modified

• Room Assigned

• Payment Received

• Check-in

• Room Move

• Charges

• Checkout

• Cancellation / Reinstatement

Additional capabilities

Additional reservation capabilities:

Waitlist

stateDiagram-v2
    [*] --> Waitlisted
    Waitlisted --> Offered : inventory available
    Offered --> Accepted : guest accepts
    Accepted --> Converted : reservation confirmed
    Offered --> Declined : guest declines
    Offered --> Expired : offer validity ends (default 24 h)
    Waitlisted --> Expired : waitlist expiry date
    Waitlisted --> Cancelled
    Converted --> [*]
    Declined --> [*]
    Expired --> [*]
    Cancelled --> [*]

A waitlist record should capture:

• Guest

• Requested Dates

• Room Type

• Occupancy

• Rate Preferences

• Priority

• Contact Method

• Expiry

On-request reservation

flowchart LR
    n1["REQUESTED"]
    n2["REVIEWING"]
    n3["ACCEPTED"]
    n4["CONFIRMED"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Used when inventory cannot be confirmed immediately.

Partial cancellation

For multi-room or multi-segment bookings:

flowchart LR
    r["Reservation"] --> a["Room A: Keep"]
    r --> b["Room B: Cancel"]
    r --> c["Room C: Keep"]

The reservation history should preserve what changed.

Split / recombine

A reservation may be split when:

• Different dates

• Different room types

• Different billing responsibilities

• Different commercial terms

Related reservations should remain linked.

Rebook after cancellation

flowchart LR
    n1["Cancelled Reservation"]
    n2["Find alternative dates / property / room type"]
    n3["Quote"]
    n4["Create replacement reservation"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

The original cancellation remains part of history.

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

13. Groups and Corporate

Diagrams: D.3, D.55, D.56, D.57, D.58

Related: sales pipeline and opportunities (§38), events and function space (§39), group displacement (§48).

Core distinction

Company = who is doing business with the hotel?
Group   = what collection/event/business occasion are we managing?
Reservation = what did an individual/party actually book?

Example:

flowchart TD
    n1["ABC Corporation"]
    n2["ABC Annual Conference"]
    n3["Individual reservations"]
    n4["Individual stays"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Group types

• Corporate

• Wedding

• Conference

• Meeting

• Tour Group

• Sports Team

• Government

• School / University

• Crew

• Religious Group

• Social Event

• Family Group

• Leisure Group

Company profile

• Legal Name

• Display Name

• Tax Information

• Billing Address

• Contacts

• Payment Terms

• Credit Terms

• Negotiated Rates

• Booking Rules

• Preferred Properties

• Travel Policy

• Documents

• Revenue History

• Stay History

Group profile

• Group Name

• Group Code

• Type

• Company

• Primary Contact

• Event Dates

• Arrival / Departure

• Expected Guests

• Expected Rooms

• Status

• Notes

• Documents

• Billing Rules

• Rate

• Block

• Pickup

• Reservations

Group lifecycle

stateDiagram-v2
    [*] --> Lead
    Lead --> Tentative : rooms pencilled in, non-deducting
    Tentative --> Definite : contract signed, inventory deducted
    Definite --> Actual : group arrives
    Actual --> Completed : group departed
    Lead --> Lost : client declines, reason required
    Tentative --> Lost : decision date passed or client declines
    Lead --> Refused : hotel declines, reason required
    Tentative --> Refused : hotel declines
    Tentative --> Cancelled
    Definite --> Cancelled : inventory returned, contract terms apply
    Completed --> [*]
    Lost --> [*]
    Refused --> [*]
    Cancelled --> [*]
    state "Arrived / Actual" as Actual
    note right of Tentative : does not deduct, pickup not allowed by default
    note right of Definite : deducts, pickup allowed

Lead

A sales inquiry is not yet a reservation.

Tentative

Rooms are pencilled in — shown in the block grid and forecasts but not deducted from house availability — while terms are negotiated; the group is not yet committed.

Definite

The contract is signed and the group is committed.

Block / Allotment

Example:

• Standard 10

• Deluxe 20

• Suite 5

• Total 35

Block vs reservation

Block = reserved group capacity
Reservation = actual guest booking

Rate-only group

A group can have a special rate without necessarily holding hard inventory.

Block status and inventory behaviour

Block status codes are configurable, but each maps to one inventory behaviour:

Allowed transitions are configured as a status flow. LOST, REFUSED and CANCELLED are statuses of the Cancel behaviour: inventory is returned and a reason is required.

Block inventory control

Non-elastic = reservations only inside block dates / room types
Elastic     = reservations may extend beyond block dates / room types
Sell limit  = block may borrow a set number of rooms from house inventory

Cutoff and wash

Cutoff date      = fixed date when unpicked rooms return to house
Rolling cutoff   = rooms return N days before each stay date
Wash schedule    = planned percentage / count reductions before cutoff
Shoulder dates   = optional dates before / after the core block

Block grids:

• Original

• Current

• Contract

• Forecast

Group master account

The group master account (posting master) is both:

Billing master = receives routed group charges
Rooming template = default rate, packages and routing copied to member reservations

Pickup

Block: 35
Picked up: 28
Remaining: 7
Pickup: 80%

Track by:

• Room Type

• Date

• Total Group

Pickup pace

Track pickup at multiple points before arrival:

30 days: 20
14 days: 25
7 days: 31
2 days: 34
Today: 35

Cutoff

At cutoff, unused group inventory can be released back to house inventory.

Partial cutoff

Do not assume all unused rooms must be released at once.

Example:

• Standard release 3

• Deluxe release 8

• Suite retain all

Attrition

Compare contracted commitment with actual pickup.

Example:

Contracted: 100 room nights
Minimum:     80
Actual:      65
Shortfall:   15

Attrition penalties depend on the actual commercial contract.

Rooming List

The organizer provides, for each guest:

• Guest

• Room Type

• Arrival

• Departure

System validates:

• Dates

• Room Type

• Block Capacity

• Required Data

• Duplicates

Group code / booking link

Guest can book using a group-specific code/link and automatically become associated with the group.

Group reservations

A group reservation is still a normal reservation plus group context.

Group contact

The organizer or contact may not stay at the hotel.

Group instructions

Example:

Breakfast before 8 AM
Bus parking north entrance
Welcome desk in lobby
Master billing for room + breakfast

Group billing

Master Folio
+
Individual Folios

Example:

Master:
Room
Breakfast
Conference

Individual:
Minibar
Spa
Personal Dining

Group deposits

Support:

• Required

• Paid

• Remaining

• Overdue

Payment schedule

Example:

• 25% at confirmation

• 25% 60 days before

• 25% 30 days before

• 25% before arrival

Group check-in

The group check-in view shows:

• Expected

• Arrived

• Checked In

• Waiting

• Not Arrived

• Rooms Assigned

• Rooms Pending

Group arrival waves

Example:

Bus 1 — 08:00
Bus 2 — 12:00
Bus 3 — 16:00

Group departure

Departures are tracked in waves, while each guest's actual departure time is still recorded.

Group cancellation

Group cancellation can affect:

• Block

• Reservations

• Deposits

• Cancellation Fees

• Inventory

• Master Folio

• Company Relationship

Group modification

Group modification supports changes to:

• Room count change

• Dates

• Room types

• Rate

• Pickup

• Contract terms

Corporate analytics

• Room Nights

• Room Revenue

• Total Revenue

• ADR

• Property Production

Event separation

A Group is not the same as an Event.

Group = commercial/accommodation relationship
Event = specific event/banquet activity

Group process view

This is the commercial process for a group. The group status lifecycle is defined under Group lifecycle above and in D.55; process steps such as Quote, Contract, Block and Pickup are activities, not statuses.

flowchart TD
    n1["LEAD"] --> n2["QUOTE / PROPOSAL"] --> n3["TENTATIVE BLOCK"] --> n4["CONTRACT"] --> n5["DEFINITE BLOCK"]
    n5 --> n7["PICKUP"] --> n8["ROOMING LIST"] --> n9["GROUP ARRIVAL"] --> n10["IN-HOUSE"]
    n10 --> n11["MASTER FOLIO"] --> n12["GROUP DEPARTURE"] --> n13["COMPLETED"]

Additional capabilities

Groups also cover:

• Group Quote

• Contract

• Attrition

• Payment Schedule

• Corporate Credit

• Arrival Waves

• Departure Waves

• Advanced Pickup / Pace

• Group Risk

• Event Link

Group vs Event

Group
=
commercial / accommodation relationship

Event
=
function / event operation

One group can contain several events.

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

14. Distribution and Channel Management

Diagrams: D.22, D.59, D.60, D.61

Core definition

Distribution is the external selling layer.

flowchart TD
    p["PMS / Hotel Inventory"] --> d["Distribution"]
    d --> c1["Booking.com"]
    d --> c2["Expedia"]
    d --> c3["Direct"]
    d --> c4["Other Channels"]

Core principle:

The hotel/PMS owns the underlying sellable hotel reality. OTAs are sales channels.

Distribution owns

• Channels

• OTA Connections

• Room Mapping

• Rate Mapping

• Availability Distribution

• Rate Distribution

• Restriction Distribution

• Reservation Import

• Reservation Modification

• Cancellation Import

• Channel State

• Sync Monitoring

• Sync Exceptions

• Overbooking Protection

• Channel Performance

• Reports

Mapping

Internal room types may have different channel names.

flowchart LR
    n1["PMS Deluxe King"] --> n2["Booking.com Deluxe Double"]
    n1 --> n3["Expedia Deluxe King Room"]
    n1 --> n4["Direct Deluxe King"]

Mapping must also cover

• Rate Plans

• Occupancy

• Meal Plans

• Cancellation Policies

• Payment Models

• Promotions

• Channel Content

Sellable product

Conceptually:

Room Type + Rate Plan = Sellable Room/Rate Product

Outbound distribution

• Availability

• Rates

• Restrictions

• Promotions / Commercial Products

Inbound distribution

• Reservations

• Modifications

• Cancellations

• Guest Information

• Payment Context

Shared pool vs allocation

Default concept:

Central sellable inventory

Optional strategy:

• Direct allocation

• OTA allocation

• Corporate allocation

Allocation is a commercial strategy, not the fundamental physical inventory truth.

Stop sell

A stop sell can close a channel/product without cancelling existing reservations.

Channel pause

Channel connection states:

• CONNECTED

• PAUSED

• DEGRADED

• DISCONNECTED

• ERROR

Channel reservation

Every OTA reservation should become a normal PMS reservation with context:

Source = OTA
Channel = Booking.com
External Confirmation = BK-XXXX
Internal Confirmation = RES-XXXX

OTA reservation must remain compatible with normal lifecycle

• Reservation

• Guest

• Stay

• Room

• Folio

• Payment

• Housekeeping

• Checkout

External confirmation

The external (channel) confirmation number must be searchable, separately from the internal one.

Payment models

An OTA reservation uses one of these payment models:

• Pay at Property

• OTA Collected

• Virtual Card

• Prepaid

• Other Channel-Specific Model

OTA commission

Analytics should separate:

• Gross Booking Value

• Commission / Margin

• Net Revenue

Rate parity

Monitor rate differences across channels, but do not treat every difference as an error — some are legitimate channel-specific promotions.

Sync discrepancy

Example:

PMS availability = 0
OTA availability = 2

System should show:

DISTRIBUTION DISCREPANCY

Sync error

Example:

PMS BAR = ₹12,000
Booking.com = ₹10,000
Status = SYNC ERROR

Resync

Support controlled resync for:

• One date

• Date range

• One room type

• One rate

• Whole channel

Resync preview

Show:

• Availability differences

• Rate differences

• Restriction differences

Mapping error

Never silently map unknown external room/rate types to a wrong internal item.

Reservation reconciliation

Compare:

External reservation vs PMS reservation

and route unmatched records for controlled resolution.

Distribution exceptions

• Reservation not matched

• Availability mismatch

• Rate sync failed

• Mapping incomplete

• Cancellation mismatch

• Unknown update

Channel capability

Channels differ in what commercial structures they support. The distribution model should represent compatibility rather than assuming every channel supports every feature.

ARI update modes

Delta push   = only changed availability / rates / restrictions
Full push    = full state for a date range
Full sync    = channel requests complete state (recovery)

Reservation delivery

flowchart LR
    n1["Channel sends reservation"]
    n2["PMS acknowledges"]
    n3["If not acknowledged, channel retries"]
    n4["Duplicate deliveries are ignored (same external reference)"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

• An OTA modification that cannot be satisfied (no availability) is accepted as an overbooking exception, never silently rejected.

• Webhooks / notifications are reconciled periodically (§32).

Virtual cards

• Activation date

• Expiry date

• Authorized amount

• Charge rules (earliest charge date)

Price display

Each channel defines whether prices are sent tax-inclusive or tax-exclusive, and which fees are included.

Direct Booking Engine

The hotel's own booking website uses the same authoritative:

• Availability

• Rate Engine

• Reservation Engine

Distribution reporting

• Reservations by Channel

• Room Nights

• Revenue

• ADR

• Cancellation

• No-show

• Commission

• Net Revenue

• Pickup

• Booking Window

• Channel Share

Distribution lifecycle

Outbound:

flowchart TD
    n1["Inventory"]
    n2["Availability"]
    n3["Rates"]
    n4["Restrictions"]
    n5["Distribution"]
    n6["OTA / Direct"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6

Inbound:

flowchart TD
    n1["OTA"]
    n2["Reservation"]
    n3["Inventory Consumption"]
    n4["Distribution Update"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Modification:

flowchart TD
    n1["OTA Modification"]
    n2["PMS Modification"]
    n3["Recalculate"]
    n4["Distribution Update"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Cancellation:

flowchart TD
    n1["OTA Cancellation"]
    n2["PMS Cancellation"]
    n3["Release Inventory"]
    n4["Distribution Update"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Additional capabilities

Distribution also covers:

• GDS

• Wholesale

• Bedbank

• Metasearch

• B2B

• Agency Networks

• Advanced Channel Mapping

• Channel Capability Matrix

• Channel Reconciliation

• Reservation Matching

• Channel Commission

• Channel Net Revenue

Channel capability principle

Every channel can expose:

• SUPPORTED

• SUPPORTED WITH LIMITATIONS

• NOT SUPPORTED

for rate, restriction, promotion and payment concepts.

The hotel should never silently lose a commercial rule because the channel cannot represent it.

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

15. Travel Agent and Partner Commission

Travel agents, wholesalers and business partners have their own commercial terms.

Partner profile

Partner
├── Company
├── Contacts
├── Partner Type
├── Contract
├── Commission Terms
├── Net / Gross Model
├── Billing Arrangement
├── Preferred Properties
├── Production
└── Status

Commission model

flowchart TD
    n1["Booking"]
    n2["Identify Commission Rule"]
    n3["Calculate Commission"]
    n4["Finalize Commission Eligibility"]
    n5["Record Commission"]
    n6["Pay / Reconcile"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6

Commission can depend on

• Room Type

• Rate Plan

• Revenue Category

• Stay Date

• Booking Channel

• Contract

• Production Tier

• Cancellation / No-show

Commission states

• Expected

• Eligible

• Disputed

• Approved

• Payable

• Paid

• Rejected

Partner statement

• Bookings

• Room Nights

• Gross Revenue

• Commission

• Net Revenue

• Outstanding

This should remain distinct from OTA commission because direct travel-agent relationships can have different commercial rules.

Phasing

Part IV — Hotel Operations

16. Front Desk

Diagrams: D.27, D.28, D.29, D.30, D.31

Related: registration rules (§53), room keys (§52), early check-in and late checkout requests (§40).

Front Desk is a first-class PMS operational module, not a separate business system.

Core question:

What is happening at the hotel right now?

Navigation

• Today

• Arrivals

• In-House

• Departures

• Walk-ins

• Room Rack

• Guest Search

• Guest Requests

• Front Desk Tasks

Today workspace

• Arrivals

• Departures

• In-House

• Room Readiness

• Payment Issues

• VIPs

• Room Assignments

• Alerts

Check-in workflow

flowchart TD
    n1["Reservation Review"]
    n2["Guest Verification"]
    n3["Room Verification"]
    n4["Payment"]
    n5["Registration / Signature"]
    n6["Final Review"]
    n7["Complete Check-in"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7

After check-in:

flowchart TD
    n1["Reservation"]
    n2["In House"]
    n3["Stay"]
    n4["Active"]
    n5["Room"]
    n6["Occupied"]
    n7["Housekeeping"]
    n8["Updated"]
    n1 --> n2
    n3 --> n4
    n5 --> n6
    n7 --> n8

Room assignment

Filter candidates by:

• Room Type

• Availability

• Readiness

• OOO / OOS

• Guest Requirements

• Other Hotel Rules

AI may rank the candidates, but rules and staff decide the assignment.

Early check-in

Check:

• Room readiness

• Availability

• Payment

• Property rules

• Fee / approval

Queue rooms

When the guest has arrived but the room is not ready:

flowchart TD
    n1["Guest Waiting"]
    n2["Room Queue"]
    n3["Housekeeping / Maintenance"]
    n4["Room Ready"]
    n5["Front Desk Notification"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5

Walk-in

A walk-in uses the same reservation model, with the source set to:

Walk-in

In-house workspace

Guest-centric actions:

• View Reservation

• View Folio

• Add Payment

• Room Move

• Extension

• Upgrade

• Add Guest

• Request

• Checkout

Room Move

flowchart TD
    n1["Validate Destination"]
    n2["Check Readiness"]
    n3["Check Availability"]
    n4["Move Guest"]
    n5["Preserve History"]
    n6["Update Old Room"]
    n7["Update New Room"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7

The old room usually becomes:

Vacant + Dirty

Upgrade / Downgrade

Preserve:

Booked Room Type

and separately record:

Actual Room Type

Late checkout

Evaluate:

• Next Arrival

• Availability

• Policy

• Fee

Guest requests

Lifecycle:

stateDiagram-v2
    [*] --> Open
    Open --> Assigned
    Assigned --> Assigned : reassigned
    Assigned --> InProgress
    InProgress --> Completed
    Completed --> InProgress : reopened
    Completed --> Closed
    Open --> Cancelled
    Assigned --> Cancelled
    Closed --> [*]
    Cancelled --> [*]
    state "In progress" as InProgress

Front Desk should consume, not own, configuration from:

• Rate Engine

• Inventory

• Payment

• Housekeeping

• Maintenance

Additional capabilities

Front Desk also supports these workflows:

• Key / Access

• Left Luggage

• Wake-up Call

• Cashier Shift

• Queue Management

• Guest Communication Inbox

• Service Recovery

• Registration Completion

• Digital Check-in Completion

Left luggage

flowchart TD
    n1["Receive Bag"]
    n2["Tag"]
    n3["Store"]
    n4["Guest Retrieval Request"]
    n5["Handover"]
    n6["Closed"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6

Wake-up call

flowchart LR
    n1["Requested"]
    n2["Scheduled"]
    n3["Attempted"]
    n4["Answered / Missed"]
    n5["Closed"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

17. Guest Management

Diagrams: D.3, D.32

Related: messaging consent and opt-out (§55), complaint case history (§46).

Definition

A guest is the permanent identity of a person, held at organization level.

Guest is NOT:

• Reservation

• Stay

• Folio

One guest may have many stays across properties.

Guest profile

• Overview

• Personal Info

• Contact

• Address

• Identification

• Preferences

• Relationships

• Stays

• Reservations

• Financial Insights

• Loyalty

• Requests

• Notes

• Tags

• Communication

• Consent / Privacy

• Documents

• Merged Profiles

• Activity / History

Guest owns

• Name

• Preferred Name

• Contact Info

• Address

• Nationality

• Language

• Identity Fields

• Preferences

• Tags

• Loyalty membership link (programme owned by §44)

• Guest Insights

• Stay Statistics

• Lifetime Revenue

• Relationships

• Communication Preferences

• Privacy / Consent

• ID Metadata

• Duplicate / Merge History

Preference model

Distinguish:

• Explicit Preference

• Observed Preference

• Inferred Preference

Also distinguish:

• Preference

• Hard Requirement

• Stay-specific Request

Guest vs reservation note

Guest Note
= long-term context

Reservation Note
= booking-specific context

Loyalty vs VIP

Loyalty membership and VIP status are different concepts (see §44).

Communication

Distinguish:

• Operational Communication

• Marketing Communication

Duplicate detection

Match guests on several identity signals (name, email, phone, ID document, loyalty number), not on name alone.

Possible workflow:

flowchart TD
    n1["High confidence"] --> n2["Strong merge suggestion (merge needs an authorized user, §30)"]
    n3["Medium confidence"] --> n4["Review"]
    n5["Low confidence"] --> n6["Do not auto-merge"]

Merge / Unmerge

A merge keeps all stays, reservations and folios of both profiles. A controlled unmerge should be possible.

Privacy

The guest module supports protected profiles, consent per purpose and anonymization. Data-protection rules are defined in §31.

Guest 360

Guest 360 is a contextual view that combines:

• Guest

• Reservations

• Stays

• Requests

• Folio summaries

• Payments

• Communication

• Preferences

without taking ownership away from the original domains.

Key rule

Search/match existing guest before creating a new profile.

Additional capabilities

Guest Management also includes:

• Household / Relationship

• Loyalty

• Feedback

• Marketing Consent

• Communication History

• Identity Verification

• Guest Journey

• Guest Service Case

Observed vs explicit vs inferred

Always distinguish:

• Explicit Preference

• Observed Preference

• Inferred Preference

AI-generated preferences should not automatically become confirmed guest preferences.

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Phasing

18. Stay Management

Diagrams: D.30, D.33

Definition

Stay is the actual guest accommodation lifecycle after check-in.

Stay owns

• Current Status

• Actual Arrival

• Actual Departure

• Current Room

• Room Assignment History

• Stay Segments

• Room Moves

• Upgrades / Downgrades

• Extensions

• Early Check-in

• Early Departure

• Late Checkout

• Additional Occupants

• In-stay Requests

• DND / Privacy

• Alerts

• Notes

• Service Recovery Context

• In-stay Communication

It does not own:

• Folio

• Payment

Stay vs reservation

Reservation = intended / sold stay
Stay = actual operational reality

Stay segments

A stay is split into segments when conditions change during one continuous visit:

• Room changes

• Rate/company changes

• Billing changes

Early departure

flowchart TD
    n1["Original Departure"]
    n2["Actual Earlier Departure"]
    n3["Recalculate Appropriate Financial Impact"]
    n4["Checkout"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Extension

Added nights are priced at the rules that apply today; the nights already agreed keep their original price.

Room move

Must preserve:

• Reason

• Old Room

• New Room

• Time

• History

Stay timeline

Aggregate operational events from:

• Reservation

• Front Desk

• Housekeeping

• Maintenance

• Folio

• Payment

• Communication

AI can summarize the timeline, but must separate confirmed facts from inferred information.

Stay lifecycle

stateDiagram-v2
    [*] --> NotStarted
    NotStarted --> InHouse : check-in
    state InHouse {
        [*] --> Staying
        Staying --> Staying : room move / upgrade / downgrade
        Staying --> Staying : extension, availability checked, new nights at current rules
        Staying --> Staying : add occupant
        Staying --> LateCheckoutApproved : late checkout, same date
        LateCheckoutApproved --> Staying : late checkout cancelled
    }
    InHouse --> Departing : scheduled or early departure
    InHouse --> Overstay : still in room after departure time
    Overstay --> InHouse : extension recorded
    Overstay --> Departing : guest leaves
    Departing --> CheckedOut : checkout
    CheckedOut --> [*]
    state "Not started" as NotStarted
    state "In-House" as InHouse
    state "Checked-Out" as CheckedOut
    state "Late checkout approved" as LateCheckoutApproved

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Phasing

19. Housekeeping

Diagrams: D.7, D.29, D.43, D.44, D.45, D.46

Related: fulfilment tasks from purchased products (§40), attendants and credits (§50).

Definition

Housekeeping manages physical room cleaning, service, inspection and readiness.

Core question:

Is this room clean, serviced, inspected, and ready for the next operational need?

Housekeeping owns

• Room Cleaning

• Room Condition

• Daily Housekeeping Work

• Attendant Assignments

• Priorities

• Inspections

• Stayover Service

• Departure Service

• Turndown

• Pickup / Touch-up

• Special Cleaning

• DND Handling

• Make-up-room Requests

• Room Readiness

• Discrepancies

• Forecast

• Cleaning History

• Tasks

• Lost & Found

• Linen / Supplies (V2)

Core condition states

• DIRTY

• CLEAN

• INSPECTED

Optional advanced condition:

PICKUP

Condition ≠ Occupancy

Occupancy: VACANT / OCCUPIED
Housekeeping: DIRTY / CLEAN / INSPECTED
Operational: SELLABLE / OOO / OOS / HOUSE USE

Normal departure flow

flowchart TD
    n1["OCCUPIED"]
    n2["CHECKOUT"]
    n3["VACANT + DIRTY"]
    n4["Cleaning Task"]
    n5["CLEAN"]
    n6["Inspection"]
    n7["INSPECTED"]
    n8["READY"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7
    n7 --> n8

Task types

• Departure Clean

• Stayover Clean

• Pickup / Touch-up

• Deep Clean

• Inspection

• Turndown

• Special Cleaning

• VIP Preparation

• Post-Maintenance Clean

• Amenity Setup

Stayover

The guest stays another night and housekeeping provides the configured daily service.

No-service

A guest may skip service for a specific day/service while remaining eligible for future service.

DND

Do Not Disturb applies to a specific time or service; it does not permanently exclude the room from housekeeping.

Make-up room

A guest can ask for cleaning even when regular service is not due.

Turndown

Turndown is a separate evening service workflow.

Priority

Suggested levels (the service-order scale of §21, without Emergency):

• CRITICAL

• HIGH

• NORMAL

• LOW

Factors:

• Next arrival

• VIP

• Guest waiting

• Requested arrival

• Room scarcity

• Special request

Attendant assignment

Supervisors assign rooms and tasks to attendants.

Workload

Do not divide work only by number of rooms. Weight each task by effort (credits), because a suite takes longer than a standard room.

Example:

Standard room = 1 credit
Suite = 2 credits
Deep clean = additional effort

Housekeeping Board

Example:

Room | Guest | Condition | Task | Attendant | Priority
201  | —     | Dirty     | Departure | Neha | High
202  | —     | Clean     | Inspection | Amit | Normal
203  | Rahul | Dirty     | Stayover | Priya | Normal

Inspection

flowchart LR
    a["Cleaning Complete"] --> b["Inspection"]
    b -->|PASS| c["INSPECTED"]
    b -->|FAIL| d["Re-clean"]
    d --> a

Failed inspection must preserve history.

DND / Make-up workflow

The task board should make service constraints visible to attendants and supervisors.

Discrepancy

Key occupancy discrepancy concepts:

SLEEP = system says vacant, room appears occupied
SKIP  = system says occupied, room appears vacant
PERSON = system and housekeeping report different guest counts

Discrepancies are resolved by Front Desk (check in / check out / correct occupants), not by housekeeping. Front office status is re-synchronized from reservations at business-date close.

Housekeeping → Maintenance

If a housekeeper discovers a fault:

flowchart TD
    n1["Housekeeper"]
    n2["Maintenance Request"]
    n3["Maintenance"]
    n1 --> n2
    n2 --> n3

Maintenance → Housekeeping

After repair:

flowchart TD
    n1["Maintenance Complete"]
    n2["Post-Maintenance Cleaning"]
    n3["Inspection"]
    n4["Ready"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Lost & Found

Lifecycle:

stateDiagram-v2
    [*] --> Found
    Found --> Registered
    Registered --> Stored
    Stored --> GuestContacted
    GuestContacted --> Claimed
    Claimed --> Returned
    Stored --> Unclaimed : retention period ends
    GuestContacted --> Unclaimed : no response
    Unclaimed --> Disposed
    Returned --> [*]
    Disposed --> [*]
    state "Guest contacted" as GuestContacted

Housekeeping and Inventory

Important rule:

Dirty ≠ Inventory removed

A dirty room may remain part of sellable inventory while not being immediately assignable.

Housekeeping Forecast

Forecast:

• Arrivals

• Departures

• Stayovers

• Task counts

• Credits / workload

• Supplies

Mobile attendant workflow

flowchart TD
    n1["My Tasks"]
    n2["Open Room"]
    n3["Start"]
    n4["Work"]
    n5["Report Issue / Assistance"]
    n6["Complete"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6

Guest service status

• Make Up Room

• Do Not Disturb

• Service Declined

• No Status

Queue priority

A queued room (guest waiting) has a queue priority and wait time, appears first on the attendant's list, and triggers a "room ready" notification to front desk and guest.

Return status after blocks

When an OOO / OOS block ends, the room returns with the block's configured return housekeeping status (§9).

Additional capabilities

Housekeeping also covers:

• Room Rotation

• Service Frequency

• DND handling

• No-service / guest refusal

• Re-clean

• Inspection Failure

• Lost & Found

• Linen

• Supplies

• Room Attendant Workload

• Turnaround SLA

• Ready-by time

Room rotation

The hotel may intentionally distribute room usage or avoid repeatedly assigning the same room when alternatives exist.

This is a policy/revenue/operations concept, not an inventory rule.

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

20. Maintenance and Engineering

Diagrams: D.47, D.48, D.49

Related: parts and stores (§49), technician skills and schedules (§50).

Definition

Maintenance manages physical functionality, repairs, equipment, engineering operations and preventive maintenance.

Core question:

Is the room/facility physically functioning, safe, and available for operation?

Maintenance owns

• Issues / Requests

• Work Orders

• Preventive Maintenance

• Assets / Equipment

• Technicians

• Assignments

• Priority / SLA

• Room Blocking

• Inspections

• Recurring Work

• Parts / Materials

• Vendors

• History

• Reports

Reactive vs preventive

Reactive = fix a current problem
Preventive = avoid future failure

Request vs work order

Maintenance Request
= someone reports a problem

Work Order
= structured engineering work

Maintenance targets

• Guest Room

• Public Area

• Equipment

• Building

• Floor

• Facility

• Vehicle

• Kitchen

• Laundry

• Pool

• Back Office

Work order lifecycle

stateDiagram-v2
    [*] --> Open
    Open --> Acknowledged
    Acknowledged --> Assigned
    Assigned --> InProgress
    InProgress --> OnHold : waiting for part, vendor or access
    OnHold --> InProgress : resumed
    InProgress --> Completed
    Completed --> Verified : test passed
    Completed --> InProgress : verification failed
    Verified --> Closed
    Closed --> [*]
    state "In progress" as InProgress
    state "On hold" as OnHold

Possible waiting states:

• WAITING FOR PART

• WAITING FOR VENDOR

• WAITING FOR ACCESS

Priority

• EMERGENCY

• CRITICAL

• HIGH

• NORMAL

• LOW

Priority considers:

• Severity

• Guest impact

• Safety

• Occupancy

• VIP

• Upcoming arrival

• Alternative room availability

• Operational dependency

Technician assignment

Consider:

• Skill

• Availability

• Workload

• Location

Mobile technician workflow

flowchart TD
    n1["My Work"]
    n2["Work Order"]
    n3["Start"]
    n4["Diagnose"]
    n5["Repair"]
    n6["Test"]
    n7["Complete"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7

Diagnosis and action

Each work order records:

• Diagnosis

• Action Taken

• Parts Used

• Photos

• Testing Result

Asset management

Example:

flowchart LR
    r["Room 204"] --> u["AC Unit AC-204-01"]
    u --> m["Model"]
    u --> i["Install Date"]
    u --> w["Warranty"]
    u --> h["Maintenance History"]

Asset lifecycle

flowchart TD
    n1["PLANNED"]
    n2["INSTALLED"]
    n3["ACTIVE"]
    n4["UNDER MAINTENANCE"]
    n5["RETIRED"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n3
    n3 --> n5

Asset history

Track:

• Failures

• Repairs

• Parts

• Labor

• Preventive work

• Warranty

• Downtime

Preventive maintenance

Schedules may be:

• Daily

• Weekly

• Monthly

• Quarterly

• Biannual

• Every X days

• Usage-based

Examples:

• Generator inspection

• AC filter cleaning

• Elevator service

• Boiler inspection

• Water pump maintenance

• Fire safety inspection

Preventive maintenance checklist

Example:

• Oil level

• Battery

• Coolant

• Belts

• Leakage

• Test start

• Load test

A failed PM task may create a corrective work order.

Room block

Serious maintenance may require blocking the room as:

• Out of Service

• Out of Order

A room block is separate from the room's housekeeping condition.

OOO / OOS distinction

They are separate operational concepts and should not be collapsed into a generic "maintenance" status.

Maintenance completion ≠ Room Ready

Correct flow:

flowchart TD
    n1["Repair Complete"]
    n2["Housekeeping"]
    n3["Inspection"]
    n4["Ready"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Repeated failure detection

Example:

• AC-204-01

• 6 failures in 12 months

Potential recommendation:

Consider replacement

Maintenance SLA

Track:

• Response Time

• Time to Start

• Repair Time

• Resolution Time

• SLA Compliance

Downtime

For blocked rooms, track:

• OOO Start

• OOO End

• Total Downtime

• Cause

Incident vs maintenance issue

Maintenance Issue = one technical problem
Incident           = broader event affecting multiple systems/assets/guests

An incident may contain multiple work orders.

Additional capabilities

Maintenance also covers:

• Warranty

• Contracted Vendor

• Parts

• Labor

• Preventive Maintenance

• Usage-based Maintenance

• Follow-up Work

• Asset Replacement

• Failure Frequency

• Cost of Ownership

Asset replacement trigger

Possible functional recommendation:

flowchart LR
    i0["Repeated failure"] --> OUT
    i1["High repair cost"] --> OUT
    i2["High downtime"] --> OUT
    i3["Old asset"] --> OUT
    OUT["Replacement Candidate"]

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

21. Service Orders and Task Management

Diagrams: D.31, D.50

Related: product fulfilment (§40), complaint cases (§46), staff routing by department and skill (§50).

Definition

A Service Order is the common operational unit for work requested, assigned, executed, and resolved across departments.

Service Order
├── Requester
├── Context
├── Property
├── Location
├── Department
├── Service Type
├── Priority
├── SLA
├── Assigned Person / Team
├── Required Skill
├── Due Time
├── Status
├── Instructions
├── Attachments / Photos
├── Related Guest / Stay / Reservation / Room / Group
├── Follow-up
└── Resolution

Why this is needed

The product has separate work items:

• Guest Request

• Housekeeping Task

• Maintenance Work Order

• Front Desk Task

Each keeps its own domain meaning and lifecycle; each domain state maps onto the common service-order lifecycle below (for example Open → Requested, Acknowledged → Triaged), so cross-department reporting and SLA tracking use one model.

Common lifecycle

stateDiagram-v2
    [*] --> Requested
    Requested --> Triaged
    Triaged --> Assigned
    Assigned --> Assigned : reassigned
    Assigned --> Accepted
    Accepted --> InProgress
    InProgress --> OnHold
    OnHold --> InProgress
    InProgress --> Completed
    Completed --> Verified
    Completed --> InProgress : reopened
    Verified --> Closed
    Requested --> Cancelled
    Triaged --> Cancelled
    Assigned --> Cancelled
    Closed --> [*]
    Cancelled --> [*]
    state "In progress" as InProgress
    state "On hold" as OnHold

Priority

• Emergency

• Critical

• High

• Normal

• Low

Examples

flowchart LR
    g["Guest: Please bring two extra towels"] --> so["Service Order"] --> d["Housekeeping"]

flowchart LR
    g["Housekeeper: AC is not cooling"] --> so["Service Order"] --> d["Maintenance"]

flowchart LR
    g["Front Desk: Prepare room for VIP arrival"] --> so["Service Order"] --> d["Operations / Housekeeping"]

Cross-module behavior

flowchart TD
    n1["Guest / Reservation / Stay"]
    n2["Service Order"]
    n3["Department"]
    n4["Task / Work"]
    n5["Resolution"]
    n6["Folio / Notification / Analytics where relevant"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6

Functional principle

A Service Order represents the work. The destination department owns the execution.

Phasing

22. Checkout and Departure

Diagrams: D.51

Definition

Checkout is the controlled operational process that finishes a guest departure.

Core question:

Are the guest, account, payment, stay and room ready to be closed/released correctly?

Scheduled departure vs actual departure vs checkout

Scheduled Departure = planned time/date
Actual Departure    = when guest really leaves
Checkout            = process that finalizes the departure

Checkout workflow

flowchart TD
    n1["Departure"]
    n2["Review Stay"]
    n3["Capture Final Charges"]
    n4["Review Folio"]
    n5["Settlement"]
    n6["Receipt / Folio"]
    n7["Checkout Complete"]
    n8["Room Release"]
    n9["Housekeeping"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7
    n7 --> n8
    n8 --> n9

Pre-checkout validation

• Guest

• Room

• Folio

• Pending Charges

• Payment

• Billing Details

• Open Requests

• Exceptions

Pending final charges

Example:

• Minibar pending

• Spa pending

• Room Service pending

Pending charges must be reviewed and posted before the folio is settled.

Checkout validation levels

• Informational

• Warning

• Blocking

Not every issue needs to block checkout.

Zero-balance checkout

Charges = Payments
Balance = 0

Outstanding balance

Possible resolution:

• Collect Now

• Direct Bill

• Open Folio

• Corporate Billing

• Manager Review

Open Folio

flowchart TD
    n1["Physical room closes"]
    n2["Room Vacant"]
    n3["Financial account remains open"]
    n4["Additional charges"]
    n5["Final settlement"]
    n6["Folio closes"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6

Quick Checkout

For guests already settled:

flowchart LR
    n1["Review"]
    n2["Confirm"]
    n3["Checkout"]
    n4["Folio / Receipt"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Scheduled checkout

Scheduled checkout lets the guest arrange checkout in advance — for example, automatic checkout at departure time — when property rules allow.

Early departure

• Booked Oct 8–12

• Actual departure Oct 10

This is:

Early Departure

not cancellation.

Any early-departure fee comes from the applicable policy.

Late checkout

• Same departure date

• Later time

Late checkout is different from an extension:

Extension = departure date changes

Overstay

If guest remains after scheduled departure:

OVERSTAY

Do not silently check out an occupied guest unless explicit property rules support that workflow.

Sharer departure

One guest can leave while another remains.

Therefore support:

• Guest-level departure

• Room-level departure

• Reservation-level departure

Group / multi-room departure

Staff can see the departure status of a whole group, while each guest is still checked out individually.

Post-stay charges

A completed stay may still produce controlled post-stay financial activity, such as late minibar discovery.

Reinstatement

If checkout was accidental or reversal is operationally justified:

flowchart TD
    n1["Checkout Complete"]
    n2["Reinstatement Request"]
    n3["Reason / Review"]
    n4["Reinstate"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Never erase the historical checkout event.

Room transition

flowchart TD
    n1["Checked Out"]
    n2["Vacant"]
    n3["Dirty"]
    n4["Housekeeping"]
    n5["Clean"]
    n6["Inspection"]
    n7["Ready"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7

Additional capabilities

Checkout also supports:

• Scheduled Checkout

• Open Folio

• Self Checkout

• Partial / Sharer Departure

• Post-stay Charges

• Reinstatement

• Auto-checkout where policy allows

Sharer example

• Room 204

• Rahul leaves

• Amit remains

Rahul's departure must not automatically check out Amit or release the room.

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

Part V — Financial Control

23. Folio and Billing

Diagrams: D.34, D.36

Related: POS room charges (§42), loyalty redemptions (§44), event postings (§39), parking and transfer charges (§54).

Definition

Folio is the financial account containing charges, payments, credits, adjustments and balance.

Folio ≠ Invoice

Folio   = account
Invoice = formal document

Folio owns

• Folio

• Billing Windows

• Transactions

• Balance

• Payer

• Routing

• Split

• Transfer

• Interim Folio

• Advance Billing

• Open Folio

• Receipts / Folio Documents

Transaction types

• Charge

• Payment

• Refund

• Adjustment

• Discount

• Tax

• Transfer

• Split

• Deposit

• Credit

• Cancellation Fee

• No-show Fee

Posting concepts

Keep distinct:

• Service Date

• Posting Date

• Business Date

Revenue transaction coding

Examples:

• Accommodation

• Breakfast

• Restaurant

• Spa

• Laundry

• Minibar

• Parking

• Taxes

Package posting

A package can be posted as separate components (for example, room and breakfast) according to its posting rules (§11).

External POS

Restaurant, spa and other systems can post charges to the guest's folio.

Billing windows

Each billing window has its own payer and its own payment method.

Examples:

• Guest

• Company

• Travel Agent

• Group Master

Routing

Example:

flowchart LR
    n1["Room + Breakfast + Tax"]
    n2["Company"]
    n3["Minibar + Spa"]
    n4["Guest"]
    n1 --> n2
    n3 --> n4

Split vs transfer

Transfer = move whole/partial charge elsewhere
Split    = divide a charge

Adjustment

Adjustment corrects a posted financial item without silently deleting history.

Refund

A refund returns money to the payer; it is different from correcting a wrong charge on the folio.

Deposit

Deposit Requirement = commercial condition
Deposit Payment    = financial event

Overpayment

An overpayment can become:

Refund or Guest Credit

No-post restriction

A no-post flag blocks new charges on a folio, for example when the guest has no approved credit.

Credit limits

A credit limit caps how much a folio, billing window or corporate / direct-bill account may owe; postings above it are refused or need authority.

Multi-currency

For multi-currency, distinguish:

• Transaction Currency

• Settlement Currency

• Exchange Rate

Open folio

The guest can leave while the financial account stays open.

Direct Bill / City Ledger

Unpaid corporate receivables can move to Accounts Receivable / City Ledger.

Important financial principle

Posted financial events should never silently disappear.

Corrections should remain traceable.

Ledgers, transaction codes, posting dates, void vs adjustment, correction documents, invoice lifecycle and Accounts Receivable are defined in §25.

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Phasing

24. Payments

Diagrams: D.3, D.22, D.39, D.40, D.41, D.42

Related: booking-engine payments and holds (§41), service-recovery compensation (§46).

Definition

Payment is the actual money movement or payment attempt.

Payment vs folio

Folio = amount owed / account
Payment = money movement

Payment lifecycle

Typical card/gateway flow:

flowchart TD
    n1["Payment Intent"]
    n2["Payment Attempt"]
    n3["Authentication"]
    n4["Authorization"]
    n5["Capture"]
    n6["Payment Recorded"]
    n7["Folio Allocation"]
    n8["Settlement"]
    n9["Reconciliation"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7
    n7 --> n8
    n8 --> n9

Not every payment method uses all stages.

Authorization

Authorization ≠ Payment

An authorization reserves funds on the guest's card or account; it is not yet collected money.

Capture

Capture ≠ Settlement

Capture is the actual charge; settlement is when the provider or bank later transfers the money to the hotel.

Void

Void cancels an authorization, or a capture not yet settled where the provider supports it; once settled, money is returned only by refund.

Refund

Refund returns captured money while the original payment remains historically recorded.

Reversal

A reversal undoes a payment step, where the provider supports it.

Failed attempt

Failed attempts remain in history. Retries should create new attempts rather than rewriting the old attempt.

Timeout

A timeout does not necessarily mean payment failed. Actual provider status must be confirmed.

Payment verification

Do not trust browser success alone. Confirm with the authoritative payment provider state.

Idempotency

Retrying the same payment action must never charge the guest twice.

Payment methods

• Cash

• Credit / Debit Card

• UPI

• Bank Transfer

• Online Payment

• Wallet

• Payment Link

• Virtual Card

• Cheque

• Direct Bill

Payment source

• Front Desk

• Booking Engine

• Payment Link

• OTA

• POS

• API / External System

• Automatic Collection

• Night Audit

Payment purpose

• Reservation Deposit

• Room Stay

• Incidentals

• Cancellation Fee

• No-show Fee

• Group Deposit

• Additional Charge

Payment responsibility

Separate:

Who pays?

from:

How do they pay?

Example:

Payer = Company
Method = Card

Payment link

A payment link includes:

• Amount

• Currency

• Purpose

• Expiry

• Message / Context

Scheduled payments

Payments can be scheduled around events such as booking, arrival or checkout (see payment policies in §11).

Payment reconciliation

Compare:

• PMS payment records

• Gateway

• Bank settlement

• Fees

• Refunds

• Chargebacks

VCC / OTA virtual cards

OTA virtual cards are a separate payment context, with their own activation date, amount and charge rules (§14).

Cashier shift

MVP capability. Night Audit's cashier reconciliation depends on it. Opening float, attributed postings, paid-outs, declared vs expected, variance and closure are defined in §25.

Card data

The PMS never stores card numbers, security codes or other sensitive authentication data. It keeps only provider tokens and references.

Payment account / card on file

flowchart LR
    n1["Guest enters card on the payment provider's hosted page / component"]
    n2["Provider returns a token"]
    n3["Token stored as the reservation's payment account"]
    n4["Used for guarantee, deposits, incidentals, no-show and cancellation fees"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

The PMS never receives or stores the full card number.

Authorization lifecycle

stateDiagram-v2
    [*] --> Authorized
    Authorized --> Adjusted : incremental authorization
    Adjusted --> Captured
    Authorized --> Captured : capture
    Authorized --> Voided : released before capture
    Authorized --> Expired : authorization expires
    Expired --> Authorized : re-authorize (new linked authorization)
    Captured --> Settled : provider settlement
    Captured --> Refunded : full / partial refund
    Settled --> Refunded
    Captured --> Disputed : chargeback raised
    Settled --> Disputed : chargeback raised
    Disputed --> ChargebackLost : lost
    Disputed --> Won : evidence accepted
    Voided --> [*]
    Refunded --> [*]
    Won --> [*]
    ChargebackLost --> [*]
    state "Chargeback lost" as ChargebackLost

Authorization expiry differs by provider and card scheme; the PMS must track expiry and re-authorize long stays. Virtual cards and card details from channels reach the PMS only as tokens, through a PCI-compliant channel manager or token vault.

Payment policy automation

Payment policies on the rate plan (§11) create scheduled payment actions. Each scheduled action has its own status and appears as an exception if it fails.

Additional capabilities

Folio and Payments also handle:

• Chargeback

• Payment Dispute

• Virtual Card Lifecycle

• Settlement Mismatch

• Unallocated Payment

• Guest Credit

• Post-stay Collection

• Partial Refund

• Refund Failure

• Payment Reversal

Important distinction

Recorded Refund ≠ Gateway Refund Confirmed

and:

Payment Captured ≠ Settlement Completed

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

25. Accounting and Ledgers

Diagrams: D.3, D.20, D.35, D.36, D.37, D.38, D.39

Definition

Accounting is the financial truth layer underneath Folio, Payments, Accounts Receivable and Night Audit.

Core question:

Where does every unit of money sit right now, and does the business day balance?

Folio (§23) is the guest-facing account. Accounting defines how those accounts roll up into ledgers that must balance every business day.

Ledgers

Deposit Ledger    = money received before the service is delivered (a liability)
Guest Ledger      = balances of open / in-house accounts (including house accounts)
City Ledger / AR  = balances transferred to companies, agents and direct-bill accounts
Package Ledger    = package allowances posted but not yet consumed

Every money movement is a pair of entries. A balance never disappears; it moves between ledgers.

Typical movements

Deposit consumption timing

Each property chooses one rule:

• At check-in (default)

• At first room-charge posting

• At checkout

Tax treatment of prepayments (tax due on receipt or on consumption) comes from the jurisdiction pack (§31).

Trial balance

For each ledger and each business date:

Opening + Debits − Credits = Closing
Closing (day N) = Opening (day N+1)

The day balances when, for each ledger, the computed Closing equals the sum of the individual balances in that ledger (folios, deposits, AR accounts, package allowances), and total debits equal total credits across ledgers, revenue, tax and payment accounts for the business date. Balances are signed debit-positive; the Deposit and Package ledgers normally carry credit (negative) balances.

The trial balance of a closed business date is immutable. A later correction is posted on the current business date and references the original item.

Transaction codes

flowchart TD
    n1["Transaction Group"]
    n2["Transaction Subgroup"]
    n3["Transaction Code"]
    n1 --> n2
    n2 --> n3

Code types:

• Revenue

• Payment

• Tax

• Non-revenue (paid-out, transfer, deposit transfer)

• Wrapper (package container)

Each code defines:

• Department / revenue category

• Tax rule

• Accounting (GL) mapping

• Adjustment code

• Allowed ledgers

• Manual posting allowed?

• Minimum / maximum amount

A code that has been used can be deactivated but never deleted or redefined.

Dates

Service Date   = when the service is consumed (drives revenue reporting)
Posting Date   = when the entry was recorded (cannot be changed)
Business Date  = hotel day the entry belongs to (drives ledgers / trial balance)

Immutability and correction

flowchart TD
    n1["Posted today, not on a final document"]
    n2["may be voided with a reason"]
    n3["Posted on a closed business date"]
    n4["corrected only by an adjustment / reversal dated today"]
    n5["On a final invoice / fiscal document"]
    n6["corrected only by a correction document"]
    n1 --> n2
    n3 --> n4
    n5 --> n6

Correction document types:

• Cancellation

• Credit Note (full / partial)

• Corrective Invoice / Rebill

• Reinstatement

Every correction references the original, carries a reason code and records the actor (§30).

Invoice lifecycle

flowchart TD
    n1["Folio (open account)"]
    n2["Pro-forma (optional)"]
    n3["Final Invoice / Receipt (numbered, immutable)"]
    n4["Correction document (if needed)"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

• Numbering and mandatory content follow the jurisdiction pack (§31).

• By default a folio cannot be finalized while it contains future-dated, unconsumed items.

• An invoice may be issued to a payer different from the staying guest (billing window payer).

Accounts Receivable

AR Account
├── Company / Agent / Individual
├── Credit Limit
├── Payment Terms
├── Invoices
├── Payments
├── Unallocated Credit
├── Statements
├── Aging
├── Reminders
├── Disputes
└── Write-off

Invoice lifecycle in AR:

stateDiagram-v2
    [*] --> Open
    Open --> PartiallyPaid : partial payment applied
    PartiallyPaid --> Paid : remaining paid
    Open --> Paid : full payment applied
    Open --> Disputed : company disputes
    PartiallyPaid --> Disputed
    Disputed --> Open : resolved
    Disputed --> Credited : credit note
    Open --> WrittenOff : approved write-off
    Paid --> [*]
    Credited --> [*]
    WrittenOff --> [*]
    state "Partially paid" as PartiallyPaid
    state "Written off" as WrittenOff

Aging buckets (configurable), e.g. 0–30 / 31–60 / 61–90 / 90+, with an explicit aging basis (invoice date or due date).

Payments can be applied to specific invoices, partially, or held as unallocated credit.

Cashier shift

flowchart TD
    n1["Open Shift (starting float)"]
    n2["Postings / payments attributed to cashier"]
    n3["Paid-outs (coded cash out)"]
    n4["Close Shift: declared vs expected"]
    n5["Variance + reason"]
    n6["Shift Closed"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6

• One open shift per cashier per workstation.

• Optional blind drop (cashier declares without seeing the expected amount).

• At close, Night Audit auto-closes open shifts with a variance flag by default, or blocks the close when auto-close is disabled (§26).

Accounting export

Closed business dates export to the external accounting / ERP system through the GL mapping. Open dates are never exported.

Rules

• Night Audit cannot close a business date whose trial balance does not balance.

• Transfers move balances between ledgers; nothing is deleted.

• Revenue reports use service date; ledgers use business date. Both bases must be labelled.

Financial lifecycle

flowchart TD
    n1["Reservation / Stay"]
    n2["Folio Charges"]
    n3["Payment"]
    n4["Balance"]
    n5["Settlement"]
    n6["Checkout"]
    n7["Night Audit"]
    n8["Reconciliation"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7
    n7 --> n8

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

26. Night Audit and Business Day

Diagrams: D.24, D.52, D.53, D.54

Definition

Night Audit is the hotel's business-day closing and control process.

It is much more than posting room charges.

Closing model

Default model:

Scheduled automatic close at the business-day boundary
+ Idempotent room / package / fixed-charge posting
+ Exception queue (non-blocking by default)
+ Configurable blocking conditions
+ Income-audit review of the previous business date (corrections post on the current date as linked adjustments; the closed date never changes)
+ Immutable daily trial balance (§25)
+ BUSINESS_DATE_CLOSED event

Default blocking conditions (configurable):

• Trial balance does not balance

• Open cashier shifts (unless auto-close enabled)

• Room-charge posting failed

Default non-blocking exceptions:

• Arrivals not checked in (no-show rule applied)

• Departures not checked out

• Open folios

• Unsubmitted authority reports (§31)

• Failed scheduled payments

When room revenue posts

Room, tax, package and fixed charges post once per night for each in-house stay at business-date close. Re-running posting never creates duplicates.

Business Date

The hotel business day may extend past midnight.

Example:

Calendar:
Oct 9, 01:30

Business Date:
Oct 8

Night Audit responsibilities

• Preparation

• Validation

• Arrival Checks

• Departure Checks

• No-show Handling

• Recurring Posting

• Tax / Package Posting

• Payment Checks

• Cashier Reconciliation

• Revenue Reconciliation

• Room Reconciliation

• Exception Resolution

• Reporting

• Finalization

• Business Date Close

• Business Date Advance

• Next-Day Preparation

Audit readiness

The readiness view shows:

• Business Date

• Arrivals

• Departures

• In-house

• Open Folios

• Outstanding Balances

• Pending Payments

• Unposted Charges

• Open Cashiers

• OOO Rooms

• Audit Exceptions

Arrival audit

Find:

Arrivals not checked in

Then determine:

• No-show

• Late Arrival

• Confirmed Late Guest

• Other Operational Condition

No-show flow

flowchart TD
    n1["Arrival not checked in"]
    n2["Review reservation"]
    n3["Apply No-show rule"]
    n4["Apply financial consequence"]
    n5["Release inventory"]
    n6["Update reservation"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6

Departure audit

Find:

Departures not checked out

Determine:

• Overstay

• Late Checkout

• Forgotten Checkout

• Extension Needed

• Other Exception

Room charge posting

Post appropriate nightly accommodation charges and other recurring configured charges.

Posting is idempotent: re-running the step never duplicates a charge.

Tax / package posting

Taxes and packages are posted according to the package posting rules (§11) and tax rules (§31).

Financial reconciliation

Compare:

• Expected revenue

• Posted revenue

• Payments

• Adjustments

• Refunds

• Taxes

• Deposits

• Receivables

The financial reconciliation is the per-ledger trial balance defined in §25.

Cashier reconciliation

Example:

Opening:              ₹10,000
Cash Received:        ₹25,000
Cash Drops / Payouts: ₹2,000
Expected Drawer:      ₹33,000
Actual Drawer:        ₹32,500
Variance:                ₹500

Variance should remain visible and explainable.

Payment reconciliation

Compare:

• Captured

• Settled

• Pending

• Refunded

• Failed

Revenue reconciliation

Example:

Rooms        ₹8.50L
F&B          ₹2.40L
Spa          ₹0.70L
Other        ₹0.40L
Total       ₹12.00L

Audit exceptions

Severity:

• Critical

• High

• Warning

• Informational

Exceptions need:

• Owner

• Status

• Reason

• Resolution

• History

Important rule

Night Audit detects and controls exceptions; the original domain module owns the underlying issue.

Example:

flowchart TD
    n1["Payment Failure"]
    n2["Payments owns payment resolution"]
    n3["Room Discrepancy"]
    n4["Front Desk / Operations owns resolution"]
    n5["Revenue Variance"]
    n6["Finance / Audit owns resolution"]
    n1 --> n2
    n3 --> n4
    n5 --> n6

Interim vs final audit

A property can separate:

• Interim / operational advance

• Final financial close

This lets finance review the previous date and post controlled, linked corrections on the current date; the closed date's trial balance is never changed.

Business Date close

flowchart TD
    n1["Oct 8"]
    n2["Finalize"]
    n3["Close"]
    n4["Advance"]
    n5["Oct 9"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5

Next-day preparation

At the start of the new business date, prepare:

• Arrivals

• Departures

• In-house

• Housekeeping

• Maintenance

• Payment obligations

• Groups

• Forecasts

Audit step sequence

flowchart TD
    n1["BUSINESS DATE"] --> n2["PREPARE"] --> n3["READINESS CHECK"] --> n4["ARRIVAL CHECK"]
    n4 --> n5["DEPARTURE CHECK"] --> n6["NO-SHOW / OVERSTAY"] --> n7["ROOM CHARGES"]
    n7 --> n8["TAX / PACKAGE POSTING"] --> n9["PAYMENT / CASHIER RECONCILIATION"] --> n10["REVENUE RECONCILIATION"]
    n10 --> n11["ROOM / OPERATIONAL RECONCILIATION"] --> n18["TRIAL BALANCE CHECK"] --> n12["EXCEPTION REVIEW"]
    n12 --> n13["REPORTS"] --> n14["FINALIZE"] --> n15["CLOSE BUSINESS DATE"] --> n16["ADVANCE"] --> n17["OPEN NEXT BUSINESS DATE"]

Additional capabilities

Night Audit also covers:

• Interim Audit

• Income Audit

• Final Audit

• Trial Balance

• Accounting Export

• Advanced Cashier Reconciliation

• Payment Settlement Reconciliation

• Room / Housekeeping Reconciliation

• Audit Resume

• Partial Failure Recovery

Audit state

stateDiagram-v2
    [*] --> NotReady
    NotReady --> Ready : prerequisites met
    Ready --> Running : scheduled or manual start
    Running --> Blocked : trial balance, posting failure, open shift without auto-close
    Blocked --> Running : resumed after fix
    Running --> ExceptionReview : non-blocking exceptions found
    ExceptionReview --> Complete
    Running --> Complete : no exceptions
    Complete --> Finalized : trial balance locked
    Finalized --> Closed : date advanced
    Closed --> [*]
    state "Not ready" as NotReady
    state "Exception review" as ExceptionReview

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Defaults

Defaults are proposed starting values. All are configurable per property unless stated.

Phasing

27. Tax Management

Tax rules are used by Rate Management, Folio and Night Audit.

Price-bracket taxes, per-night evaluation, fiscal documents and jurisdiction packs are defined in §31.

Definition

Tax Management determines which taxes apply, to which taxable items, under what conditions, and how they are displayed and posted.

Tax domain

• Tax Profile

• Tax Rule

• Tax Rate

• Tax Category

• Tax Component

• Tax Exemption

• Tax Inclusion

• Tax Effective Date

• Tax Jurisdiction

• Tax Rounding

• Tax Reporting

Tax calculation flow

flowchart TD
    n1["Charge / Price"]
    n2["Determine Taxability"]
    n3["Identify Applicable Tax Rules"]
    n4["Apply Tax Rate(s)"]
    n5["Rounding"]
    n6["Tax Breakdown"]
    n7["Folio Posting"]
    n8["Tax Reporting"]
    n1 --> n2
    n2 --> n3
    n3 --> n4
    n4 --> n5
    n5 --> n6
    n6 --> n7
    n7 --> n8

Tax can depend on

• Property

• Location / Jurisdiction

• Product / Service

• Room Type / Accommodation

• Rate Plan

• Guest / Company Category

• Market / Channel

• Date

• Tax Exemption

• Package Structure

Tax-inclusive vs tax-exclusive pricing

The PMS should support both:

₹10,000 + tax

and:

₹10,000 tax-inclusive

The system must clearly show the underlying tax amount.

Tax exemption

Example:

flowchart LR
    n1["Eligible organization"]
    n2["Tax exemption"]
    n3["Required evidence"]
    n4["Tax excluded / reduced according to rule"]
    n1 --> n2
    n2 --> n3
    n3 --> n4

Exemptions should have validity and supporting documentation where required.

Tax correction

Historical taxes must be corrected through traceable adjustment/reversal behavior rather than silently rewriting prior financial history.

Acceptance criteria

Each criterion is a testable scenario. IDs are stable references for test cases.

Phasing

28. Currency and Foreign Exchange

Definition

Currency Management handles multi-currency presentation, transaction, settlement and reporting behavior.

Distinguish

• Property Base Currency

• Transaction Currency

• Guest Display Currency

• Payment / Settlement Currency

• Reporting Currency

• Exchange Rate

Example

Property currency:
INR

Guest views:
USD

Charge:
₹10,000

Displayed estimate (illustrative rate):
≈ $113

The PMS must preserve the actual transaction currency and applicable exchange rate used for settlement/reporting.

Functional capabilities

• Currency support

• Exchange-rate source

• Exchange-rate date

• Manual FX rate override where permitted

• Rounding

• Currency conversion

• Multi-currency folio

• Settlement currency

• Foreign-currency payment

• Refund conversion behavior

• FX variance

Important principle

Currency conversion for display is not the same as changing the financial currency of a transaction.

Phasing

Part VI — Reports and Analytics

29. Reports and Analytics

Diagrams: D.9, D.62, D.63

Definition

Reports show the data. Analytics interprets it.

Report = what happened
Analytics = what it means / why / trend / comparison / forecast

Executive Dashboard

• Occupancy

• ADR

• RevPAR

• Room Revenue

• Total Revenue

• Arrivals

• Departures

• In-House

• Rooms Ready

• Rooms Dirty

• Maintenance

• Payments

• Audit Exceptions

Core hotel KPIs

• Occupancy

• ADR

• RevPAR

• Revenue

Occupancy

Conceptually:

Rooms Sold ÷ Rooms Available

Occupancy can be calculated in different ways, so every occupancy report states its denominator and scope (see the KPI counting rules below).

ADR

Room Revenue ÷ Rooms Sold

RevPAR

Room Revenue ÷ Rooms Available

KPI counting rules

Default rules (USALI-based; each is configurable and printed with the metric):