Skip to content
[ / ]  What your staff cannot do

Some things aren't
a permission.
They're impossible.

Most hotel software protects your money with a settings page — a checkbox that says this role may not edit a bill. A checkbox can be un-ticked by whoever holds the admin login, usually at 11pm, usually by someone you trust. These are enforced one layer below that, by the database, where there is no checkbox to find.

A room cannot be sold twice

INV-1

Not "the software checks first" — the room-night itself can only exist once. The second person to assign room 203 for the 14th is refused by the database and told which booking they clashed with.

UNIQUE (room_id, stay_date) WHERE active

A hall cannot be sold twice

EXCLUDE

Function space is booked by the hour, and a hall can be two halves. Selling the whole hall closes both halves, selling either half closes the whole, and two overlapping holds cannot both exist.

EXCLUDE USING gist (space_id WITH =, during WITH &&) WHERE (active)

A balance cannot drift

INV-2/3

What a guest owes is never stored anywhere. It is computed from the charges and payments every time you look, so there is no number sitting in a column for anyone to correct by hand.

folio_balance · reservation_balance — views, not columns

Receipt numbers cannot skip

INV-5

Every GST receipt takes its serial from a counter under a row lock, so two clerks printing at once get consecutive numbers and a cancelled transaction leaves no hole. Your auditor gets an unbroken run.

next_receipt_serial() — row-locked. Never a SEQUENCE, never MAX()+1

Money history cannot be rewritten

INV-9

The permission to change or delete a financial row is revoked from every account, ours included, and a trigger refuses it even if the permission came back. A correction is a new row that says what it corrects.

REVOKE UPDATE, DELETE + triggers on ledger_entry, payment, receipt
[ 02 ]  And around those

The ordinary things, done properly.

  • Every action is attributed — who, when, from which device, in a log where each entry is sealed against the one before it. A removed entry breaks the seal visibly.
  • Your data is yours, on demand — a full export of bookings, folios, guests and ledger whenever you ask, without a support ticket or a notice period.
  • One hotel cannot read another — row-level security in the database, per request, so a mistake in our code cannot show your numbers to someone else's staff.
  • Staff see only their own work — housekeeping doesn't see rates, F&B doesn't see the guest diary, and a waiter cannot open the tape chart to read who is staying where.
  • Our own staff need your permission — support access is granted by you, time-limited, and every action taken under it is logged to the same sealed trail.
  • The AI never sees your guests — PropertyAI's model only chooses which question to run. The answer is computed inside your own database and the model never sees a row — no guest name or phone number ever reaches it. It also cannot change anything.
  • Passwords are never stored — only a salted, slow hash of them. Our own platform console requires a second factor with no way to turn it off.
Book a 30-minute demo Get the one-pager