A hotel POS gets judged on something a restaurant till never has to do: it has to put the charge on the right guest folio, in the right outlet's revenue centre, before the night audit closes the day. Miss that and the money does not vanish, it just turns into a reconciliation job for someone at 3am. Which is why the software running a lobby bistro, a pool bar and a banqueting suite is a different animal from the one running a high street cafe, and why hotel POS platform shortlists tend to collapse the moment somebody asks how room charges actually post.
Most properties do not arrive at this question because they want new tills. They arrive because the old ones have become a liability: a server in the basement nobody wants to touch, four outlets with four menu databases, and a support contract that means a Saturday night failure is Monday morning's problem. A modern restaurant POS system delivered from the cloud fixes a specific set of those problems and, honestly, leaves a few untouched. This is an attempt to be precise about which is which.
Be careful with what vendors call integration
Before any of the operational detail, one warning that will save you a procurement cycle. Nearly every POS vendor selling into hospitality will tell you they integrate with your property management system. The word covers a range from "certified two way interface, live in 400 hotels" to "we can export a CSV your night auditor keys in by hand." Both get described as integration on a slide.
There is no neutral registry you can check, so you are left doing the work yourself: ask for the name of the certification programme, the version number, and two reference properties on your exact PMS running your exact outlet mix. If the answer arrives as a partner logo rather than a version number, treat it as unbuilt. I have watched a resort discover in week three of a rollout that "Opera integration" meant a nightly batch file, which is a fine thing to have and a useless thing to have when a guest is standing at the bar wanting to sign to room 412.
The bill has to land on a folio, not just a card
In a restaurant, a check ends one of a few ways: card, cash, voucher, comp. In a hotel, there is a fifth ending that outnumbers the rest in most outlets, and it is the one that makes hotel POS hard. The guest signs, and the charge routes to their folio to settle at checkout.
Doing that properly means the POS has to answer questions it cannot answer alone. Is room 412 occupied tonight? Does the name the guest just gave match the registered guest? Is there a credit limit, and has this folio already blown through it? Should this charge route to the guest's own folio or to a company account paying room and breakfast only? Is this guest on a package where two breakfasts a day are already paid for?
Every one of those answers lives in the PMS. So the useful mental model is not "POS plus an integration." It is that your POS is a terminal onto the guest ledger, and the quality of that connection sets a ceiling on how well the outlets can run. A cloud POS is not automatically better at this. What it tends to be better at is being certified against the cloud PMS platforms that hotels are moving to anyway, and at getting fixes shipped without a site visit.
What cloud actually changes when you run six outlets
The single-outlet argument for cloud is mostly about not owning hardware. The multi-outlet argument is different and much stronger, and it comes down to one database.
Count the places a hotel duplicates work today. A price rise on draught lager has to be keyed into the bar, the restaurant, the pool point of sale and the in-room dining screens. A new allergen declaration has to be updated in each. A staff member who moves from the terrace to the lobby bar needs a second set of credentials. A discount policy signed off by the GM exists as four separately configured discount buttons that have quietly drifted apart, which is exactly how you end up unable to explain a variance. None of that is difficult. It is just endlessly repeated, and repetition is where properties leak margin without ever seeing a line item for it.
With one hosted configuration, an item exists once and appears everywhere it is authorised to appear. That also means a menu change made at 10am is live at the pool at 10am, not at whatever point somebody remembers to walk over. If you want the mechanics of the hosting model itself, we covered how cloud POS works separately. The hotel specific gain is that six outlets stop being six systems that happen to share a logo.
Reporting consolidates the same way, and that matters more than it sounds. Comparing covers and spend per head across outlets on one screen is how you notice the terrace is doing restaurant volume at bar spend, or that Sunday brunch cannibalised the room service breakfast you make better margin on. Those comparisons rely on the numbers being built the same way in every outlet, which is precisely what four separate databases stop you from doing. The capture rate and RevPASH side of that analysis is a longer subject in its own right.
Room charge posting, and the failure modes that annoy guests
Assume the interface works. There are still four ways this goes wrong on a busy night, and knowing them lets you interrogate a demo properly.
Lookup that is too slow or too dumb. A bartender with five people waiting needs to find a guest in about two seconds, by room number, by surname, ideally by scanning a key card. If the flow is room number then confirm surname then wait on a spinner, the bar will start writing room numbers on paper and posting them later. Every hotel that does this discovers the cost at checkout, when a guest disputes a charge nobody can evidence.
Posting at the wrong moment. Some systems post to the folio when the check is closed, others when the shift is closed, others in a batch at end of day. The later the posting, the more likely a guest checks out before their nightcap lands. That charge becomes an after departure bill, which is a polite name for money you will probably write off.
No handling of a rejected post. Room checked out, credit limit hit, folio closed. If the POS accepts the charge and only fails silently in the background, the check looks closed to the outlet and the revenue quietly does not exist. What you want is an immediate rejection at the terminal, while the guest is still standing there.
Routing that ignores the package. A guest on half board signing for dinner should consume their allowance, not create a new charge. Get this wrong and you have both an unhappy guest and a distorted view of which outlets are earning revenue versus absorbing internal transfers.
None of these are exotic. All of them show up in a properly adversarial demo, which is why the demo should be run by the bar supervisor who will live with it, not by the finance lead who will read reports from it.
When the POS and the PMS come from the same company
Worth declaring an interest, since everything above turns on the quality of an interface. Tableview is the sister company of Prostay, a purpose-built hotel PMS, and the two were built on a shared data model rather than joined by a connector after the fact. That removes the part of this problem that comes from two vendors agreeing to talk: no certification programme to wait for, no interface fee to negotiate, no version number to chase, and nobody to arbitrate when a posting fails and each side points at the other.
The difference shows up in the failure modes listed above. A guest lookup is a query against the same guest record rather than a round trip to another company's API, so it does not depend on someone else's uptime. A rejected post surfaces at the terminal while the guest is still standing there, because the folio state is not a copy that arrived a few seconds ago. Package allowances behave the way the PMS says they behave, since there is only one definition of half board to disagree about. How that pairing works across different outlet types is covered in our piece on hospitality point of sale systems.
None of this makes a certified third party interface the wrong answer. Plenty of properties run Opera or Mews across an estate perfectly well, and if that is you, the questions earlier in this article are the right ones to put to a vendor. The narrower point is that a real share of the risk in a hotel POS project lives in the seam between two suppliers, and that seam is not compulsory.
The night audit is a deadline you cannot move
Restaurants close their day when the last table leaves. Hotels close theirs on a hard cutoff, usually between 1am and 4am, and everything financial has to be settled by then. The audit rolls the business date, posts room and tax, and produces the numbers the next day is measured against.
An open check in an outlet blocks that. Not metaphorically: an unclosed check in the bar can hold up the roll, and the night auditor's options are to hunt down the duty manager or to force it and create a variance somebody explains later. Multiply that by a property where the terrace staff leave without cashing off and you have a recurring 2am argument that has nothing to do with hospitality.
What good software does here is unglamorous and worth paying for. It shows every outlet's open checks on one screen before the audit runs, flags outlets that have not cashed off, and pushes a clean total per revenue centre. The reconciliation logic is the same as the Z report a restaurant runs nightly, with the added constraint that another system is waiting on you. Cloud helps in a mundane way: the night auditor can see and resolve outlet state from the front desk, without walking to four terminals with four sets of keys.
Offline capability, because cloud does not mean internet or nothing
This is the objection that sinks cloud POS in hotel procurement, usually raised by an IT manager who has been burned. It deserves a straight answer rather than reassurance.
A well built cloud POS keeps working when the line drops, because the terminal holds a local copy of the menu, the staff list, the open checks and the pricing, and queues transactions to sync when connectivity returns. Taking orders, printing to the kitchen, splitting a check and closing to cash all keep working. That is table stakes, and you should verify it by asking someone to unplug the router mid demo. Any vendor who resists that test has told you something.
Two things genuinely degrade, and no architecture escapes them. Card authorisation needs a network, so terminals fall back to store and forward, which shifts the risk of a decline onto you. More specific to hotels: a guest lookup against the PMS cannot happen while the link is down, because the answer lives in another system. Better systems cache the in-house guest list so a room charge can still be taken against a known occupant and reconciled on reconnect. Weaker ones simply refuse room charges, which in a resort means the pool bar stops trading.
So the honest framing is that cloud moves the failure from total to partial. A legacy system with a dead local server loses everything until an engineer arrives, which on a Sunday means Monday. A cloud system on a dead line keeps selling and loses one capability. Ask precisely which capability, then decide whether your connectivity deserves a second line.
The pool bar that only exists for four months
Seasonality is where owning hardware and perpetual licences stops making sense, and it is the argument resorts respond to fastest.
A property that runs eight outlets in August and four in February has, under the old model, bought and licensed for August. Those terminals sit in a store room for five months, still depreciating, still in scope for patching, still counted in a licence audit. The beach kiosk that trades ninety days a year carries twelve months of cost.
Per terminal monthly pricing changes that arithmetic: you activate the kiosk in June and stand it down in September. There is a practical benefit too, which operators notice more than the saving. Spinning up a pop up outlet for a wedding weekend or a festival becomes a configuration job measured in minutes, using a tablet you already own, rather than a purchase order. That changes what you are willing to try, and trying things is how F&B revenue grows. If you are weighing the money side properly, the mechanics of POS system cost are worth reading with a seasonal calendar next to you.
Banquets bill differently, and plenty of systems fumble it
For a lot of properties, conference and events revenue rivals or beats all the restaurant outlets combined. It also bills in a way retail POS logic was never designed for.
A wedding is not a check. It is a contracted event with a deposit taken months earlier, a minimum spend, a per head price for a menu agreed in a function sheet, consumption bars that may or may not be capped, service charge treated differently from the restaurants, and a final invoice that goes to an organiser on credit terms rather than a card at a table. The kitchen needs numbers by course and dietary variations by table, not a stream of tickets.
What you need from the POS is narrower than vendors assume. It rarely needs to own the event, that belongs in the event or sales system. It needs to take extras cleanly on the night, the bar tab that runs past the contracted close, the upgraded wine, the late canapes, and post them against the event's master account so they land on the final invoice instead of dying in a paper note. Get that wrong and you lose the most profitable revenue in the building: the unplanned spend. The commercial side of running these properly sits in our piece on catering and private events.
Who owns the box in the basement
There is an IT and risk argument that finance directors tend to find more persuasive than any operational one, and it is mostly about what you stop being responsible for.
An on premise POS means a server you own, on a network you secure, running a database version somebody has to patch, backed up by a job somebody has to check. Card data flowing through your own network drags a large amount of it into PCI compliance scope, and scope is the expensive part of compliance. Hosted software with point to point encrypted terminals narrows that scope substantially, because the card data stops touching systems you own.
The other half is patching and version drift. A hosted platform updates centrally, so the version running in the bar is the version running in the restaurant, and a security fix does not wait for a site visit. Anyone who has run a property where one terminal sat three versions behind because the upgrade broke a printer driver knows what that drift costs. Worth saying plainly: this transfers responsibility, it does not delete it. You now depend on a vendor's uptime and their disclosure practices, so their status history and incident write ups become things you actually read before signing.
More than one property, and the estate view
Everything above compounds for groups, and this is where a hosted platform stops being a preference and starts being the only sane option.
Configure once, deploy to twelve hotels. Push a seasonal menu to every property on the same morning. Compare beverage gross margin across properties on numbers that were built identically, which is the only way that comparison means anything. Open a new hotel by cloning a configuration instead of commissioning a server. The management patterns are shared with any multi-location management problem, with the extra wrinkle that each property has its own PMS instance and its own night audit to satisfy.
One caution from experience, because central control has a failure mode. Groups that lock configuration down entirely produce a bar manager in Palma who cannot add a local vermouth without raising a ticket to head office. The properties that get this right centralise the things that must be comparable, the item structure, the revenue centres, the reporting hierarchy, and leave local teams room to sell what their guests actually want.
What it costs, without the gloss
Cloud POS is usually sold per terminal per month, and the headline figure is the smallest part of the decision. Budget for four things beyond it.
The PMS interface almost always carries its own charge, sometimes a one off certification fee, sometimes a monthly line, occasionally billed by the PMS vendor rather than the POS vendor. Ask who invoices what before you model anything. Hardware is yours to buy even when software is rented, and hotels underestimate the environmental spend: a pool bar terminal needs sealing against chlorine and sun, a terrace needs a printer that survives humidity. Data migration and configuration is real work, since somebody has to rebuild menus, modifiers, revenue centres and tax rules, and a property with six outlets and a banqueting operation is not a weekend. Training is the line most often cut and most often regretted, because a hotel has high seasonal turnover and needs the training to be repeatable rather than a one off launch event.
Against that, count what leaves. Server hardware on a refresh cycle, the maintenance contract, engineer call outs, the version upgrade project that eats a fortnight every few years, and the slow drag of maintaining four menu databases by hand. Properties running genuinely old estates often find the comparison closer than they expected, though I would be sceptical of any vendor model that shows a saving in year one. Year one has migration in it.
How to run the evaluation without a six month committee
Hotel software decisions bloat easily. A tighter sequence, ordered so the expensive discoveries happen first:
Start with the PMS, not the POS. Get the certified interface list from your PMS vendor, in writing, and let that be your longlist. This inverts how most properties shop and it removes the fantasy candidates on day one.
Then write down your outlet mix and the awkward cases, because the awkward cases decide this. Half board allowances, a members bar, staff meals, a spa cafe posting to treatment accounts, an events master account. Ask each vendor to demonstrate those specific flows rather than a generic table service demo, and have your bar supervisor and night auditor in the room. They will find in twenty minutes what a procurement document will not find in two months.
Pilot one outlet before the estate, and pick the second busiest rather than the quietest, since the quiet one proves nothing. Run it through a full night audit cycle, a weekend, and one deliberate connectivity failure. Then sequence the rollout so banqueting moves last, because it is the most contractual and the least forgiving. The general shape of a switching POS systems project holds here, extended by the audit and folio testing a hotel adds.
Where to start on Monday
Pull your last three months of after departure charges and unposted checks, and put a number on them. That single figure, the revenue that reached a guest but not a folio, is usually the most honest business case in the building, and it is one you can produce without a vendor's help.
Then call your PMS provider and ask for their certified POS interface list. Two hours of work, and it tells you whether this is a straightforward replacement or a project with an integration risk sitting in the middle of it. Everything else, the kitchen display system in the banqueting kitchen, the stock management tie in across outlets, the reporting hierarchy, is easier to specify once you know which platforms can actually talk to your guest ledger.
Read next: hotel room service, restaurant tech stack, and tableside ordering.
