Most Nepali hotels above a certain size run two systems: a property management system for rooms and a separate POS for the restaurant. They meet at the front desk, where a human copies numbers from one screen to another. That meeting point is where revenue leaks.
The two-bill problem
A guest checks in for two nights with breakfast included, orders room service on the first evening, and brings four friends to the rooftop bar on the second. In a split setup:
- the room folio knows about the stay and the breakfast,
- the restaurant POS knows about the room service and the bar,
- nobody knows the guest's total without a manual reconciliation,
- and the "included breakfast" is either double-charged or given away.
One guest, one folio, many postings
MasterRMS models the stay as a folio: a running bill owned by the booking, to which any outlet can post. Restaurant orders post to the folio when the guest charges to the room; otherwise they settle at the table as normal.
That single decision removes three recurring errors:
- Double-charged breakfast. The package defines what is included; the POS checks the package before adding a charge.
- Lost room-service revenue. The posting is a row on the folio with an outlet tag, not a note in a book.
- Tax on the wrong base. Room revenue and restaurant revenue are taxed and reported separately, even when the guest pays once.
Stay packages, modelled properly
A package is not a discount code. It is a bundle with rules:
- Night component — room type, occupancy, extra-bed pricing.
- Inclusions — breakfast for two, airport pickup, one spa credit.
- Validity — seasons, minimum stay, blackout dates.
- Posting rules — which outlet absorbs the inclusion, and at what internal rate.
When a guest checks in on a package, the folio is pre-loaded with the inclusions. The restaurant sees "included" instead of a price, and the revenue still lands in the right ledger for accounting.
Front desk ergonomics matter more than features
The front desk is the highest-pressure screen in the building: a queue, a phone ringing, and a guest who wants a room now. Three details decide whether staff trust the system:
- Availability in one glance. A calendar with rooms as rows and nights as columns, not a search form.
- Check-in in under 30 seconds. Find booking, verify ID, assign room, hand over key. No wizard.
- A visible folio. The guest should be able to see the running total at any moment, on the same screen the receptionist is using.
Migration advice
If you are moving from two systems, do it in this order: rooms first (inventory, rates, bookings), then folio postings, then packages. Keep the old POS running for a week while the new one takes room charges in parallel, and reconcile nightly. The moment the two totals agree for seven consecutive days, switch the restaurant over.
The goal is not a single database for its own sake. It is that a guest never has to explain their own stay to two different people.