"Hospitality EPOS" reads like a marketing upgrade on "restaurant EPOS": the same software with a grander word in front of it. It is not. There is a structural difference underneath, and it reduces to one awkward fact. In a hotel or a resort, the point of sale is frequently not the point of payment. A guest orders two negronis at the pool bar and settles them four days later at a desk two hundred metres away, possibly in a different currency, possibly on a company account, possibly not at all because the rate already covered them. Every hospitality EPOS worth shortlisting is designed around that gap. Most restaurant tills are designed as though it is not there.
The distinction gets lost because both products are sold off similar pages at similar prices. A capable restaurant POS system will run a hotel's lobby bistro perfectly well on day one and then produce a reconciliation problem by the end of the month, which is a much harder thing to spot in a demo than a missing feature. So this is not another feature list. It is about what changes when your guest is resident rather than passing through, which outlets a hotel and resort F&B platform has to cover beyond the ones with menus, and why the connection to the property management system is not an item on the requirements list but the thing the whole list hangs from.
The four assumptions underneath a restaurant till
A restaurant EPOS is usually a well built piece of software. It is built on four assumptions that hold almost everywhere in standalone hospitality:
- The customer is anonymous, and will pay before they leave.
- A check opens and closes inside a single service.
- There is one tax treatment, one currency and one revenue centre.
- The terminal is the system of record for the sale.
In a hotel, all four are wrong. The customer has a name, a room, a rate and a history, and the entire commercial model depends on knowing it. A banquet check can open when the contract is signed and close six weeks later. Accommodation, food and alcohol commonly carry different VAT rates, resorts quote in one currency and settle in another, and every outlet is its own revenue centre for reporting that finance will not compromise on. And the terminal is emphatically not the system of record, because the guest ledger is, and it lives somewhere else.
If you want the general definition of the category, where the letter E came from and the point at which a cash register stops being enough, what EPOS systems are covers that ground properly. Everything below assumes it and moves on to the ways hospitality breaks it.
Guest identity is a hard dependency, not a customer field
Before you can charge a resident guest anything, you have to establish who they are. Restaurant software treats this as a marketing convenience: a customer record you attach to a sale afterwards for loyalty purposes, blank most of the time, and nothing breaks when it is. Hospitality software cannot treat it that way. Guest identity is the thing the transaction depends on, and it has to be resolved at the terminal, in seconds, by someone carrying three plates.
Which makes the quality of one interaction disproportionately important: a server asks for a room number, and the system has to answer several questions at once. Is that room occupied tonight. Does the surname the guest just gave match the registered guest. Is there a credit limit, and has this folio already passed it. Should this route to the guest's own folio or to a company account settling room and breakfast only. Is this guest on a package that already includes what they just ordered.
In practice the lookup needs to be fast and forgiving. Room number plus surname is the normal path, but guests forget their room number constantly, so name search has to work too. And it has to fail safely. Refusing a charge and asking the guest to sign a card instead is a small annoyance. Posting to the wrong folio is discovered at checkout by someone who is already late for a flight, and it costs you the charge plus the goodwill.
The mechanics below that point, how folio posting behaves, what credit limits do, why the night audit is a deadline you cannot move, and how offline behaviour should work when the pool bar loses its connection, are covered in detail in why your hotel needs a cloud based POS system. There is no sense repeating them here.
Included is not the same as free, and most tills know only two states
This is the part that generic hospitality software gets wrong most often, and it is worth more attention than room charging, which at least everybody remembers to ask about.
Consider what a resident guest actually consumes. Breakfast included in the rate. Half board with dinner in one of three outlets. All inclusive, where nearly everything carries no price at the point of service. A conference package with two coffee breaks and a working lunch per delegate per day. A wedding with an open bar up to a value cap. In every case the guest consumes something they will not be charged for at the table, and in every case it is not free.
A restaurant till offers two outcomes for a line: charged, or comped. Comp means revenue forgone, and it lands in a bucket that managers look at once a month to check nobody is giving away steaks. Hospitality needs a third state that most systems simply do not have: consumed under an entitlement. That is neither revenue at the outlet nor a loss. It is an internal transfer, because the rooms department already sold that breakfast inside the rate, and the outlet that served it needs it recorded at a transfer price.
Collapse that third state into either of the other two and specific, expensive things break:
- Outlet profitability becomes fiction. The breakfast room serves three hundred covers and books a rounding error in revenue, so on paper it is the worst performing outlet in the property and someone eventually proposes closing it.
- Food cost percentage stops meaning anything, because the cost of goods is real and the revenue it is measured against is not there.
- Nobody can answer what the included breakfast costs per occupied room, which is precisely the number that tells you whether the rate is priced correctly.
- Entitlement drift is invisible. Two drinks per day per guest quietly becomes five, and because none of them were charged, nothing in the reporting reacts.
The reason this cannot be solved inside the EPOS alone is that entitlement does not live there. It lives in the rate code or the package attached to the booking, which is to say in the PMS. So the terminal has to read it: not just whether this guest can charge to a room, but what they are already entitled to and how much of it is left. All inclusive resorts push this hardest, because there is often no cash anywhere on the property and wristbands or room keys carry the entitlement. Consumption still has to be captured line by line for stock control and food cost even though every line has a zero value. That is the same posting pipe as a room charge, carrying full detail and no money.
The outlets that have no menu at all
Ask a hotelier to list their outlets and you will usually get the restaurants, the bars and room service. Then, on a second pass: the spa, the boutique in the lobby, the golf shop, the dive centre, the cabana rental, the minibar, the late checkout fee and the excursion desk. All of those take money from guests. All of them can post to a folio. Very few of them have a menu in any sense a restaurant EPOS understands.
A hospitality EPOS is the transaction layer for the property, not for the restaurants inside it. That has a practical consequence for how you evaluate one, because retail behaves differently from food. A boutique sells units with barcodes and sizes and no recipe, while the grill sells recipes with yields and wastage, and both need to work in the same stock and inventory model without one of them being a hack. Spa and activity outlets sell time slots and staff capacity rather than items at all.
The other consequence is that spinning up an outlet has to be cheap. Resorts open a beach kiosk for four months and a pop up for a wedding weekend. If adding an outlet means a configuration project and a licence negotiation, the outlets that only exist seasonally end up running on a spare terminal with a paper chit system, and everything above about folios and entitlements stops being true for exactly the outlets where guests are most relaxed about spending.
Tax, service charge and currency move per outlet, not per property
A single site restaurant configures tax once. A property cannot. Accommodation, food and alcohol sit at different VAT rates in most jurisdictions. Service charge is added automatically on a banquet contract and usually is not at the lobby bar. Tourist or city taxes attach to the room and not the meal. Resorts display prices in the currency guests booked in, settle in whatever card the guest presents, and report to the authorities in the local one, which means three currencies in a single transaction chain and an exchange difference that has to land somewhere sensible in the accounting export.
None of this is exotic. It is just that if your EPOS holds one tax profile and one currency per company rather than per outlet and per transaction, somebody maintains the difference manually every month, and the manual work is usually invisible until that person leaves. Worth checking the same question about payment processing: whether tips, service charge and multi currency settlement reconcile per outlet or arrive as one lump the finance team has to unpick.
Why the PMS connection is the product, not a feature
Every vendor selling into hospitality claims PMS integration, and the word covers a range from a certified two way interface live in hundreds of hotels to a nightly CSV that a night auditor keys in by hand. How to interrogate that claim, which certification programmes and version numbers to ask for, and which reference properties to insist on, is covered in the hotel cloud POS piece.
The point worth adding here is architectural, because it explains why two integrations that both pass a demo behave differently in year two. What separates them is whether guest identity and entitlement are one data model or two models mapped to each other.
Mapped models drift, and they drift through normal business activity rather than through anybody's mistake. Revenue management adds a rate code on a Tuesday and the POS knows nothing about it until a guest on the new package stands at the bar. Finance restructures department codes for a new financial year and postings land in the wrong revenue centre for a fortnight before anyone notices. A package changes from two drinks to a value allowance and the mapping still says two drinks. None of that is a defect in either system. It is the standing cost of two systems owning the same concept.
Tableview approaches this from both directions. There are certified two way integrations with Opera PMS, Mews, Cloudbeds and several other property management systems, pulling room status, guest profiles and rate codes and posting revenue to the correct department codes without manual mapping. And there is Prostay, a purpose built hotel PMS from the same company, which is a different proposition again: not an interface between two products but two products designed against the same model of a guest. A room charge signed on a handheld attaches to the folio and stays visible in Prostay, so when a guest disputes a line at checkout the front desk retrieves the signature in seconds instead of going through a drawer of paper chits.
It is worth being honest about what that buys, because "native integration" is a phrase that gets oversold. The sister company route removes a category of problem: middleware to license and monitor, sync delays, and the finger pointing between two vendors when a posting goes missing on a Saturday night. It does not remove the work of configuring outlets, deciding how entitlements should be recorded, or training staff on a new posting flow. Those are yours either way.
It still has to be a good restaurant EPOS
Here is the trap at the other end. Properties that take the folio requirements seriously sometimes buy a system that satisfies finance and hands the fine dining room a worse tool than it had before. That is a bad trade and an unnecessary one.
The rooftop grill in a hotel is a full service restaurant with all the attendant complexity: coursing, a floor plan, modifier trees, split bills, a twelve top with three courses and a dessert timed after the mains. The lobby bar has the same tab and round building problems as any bar or club. Several outlets often share one kitchen, so kitchen display routing has to separate tickets by outlet and destination rather than dumping everything on one screen. Room service has its own timing, tray tracking and delivery workflow, which in room dining goes into, and banqueting bills on a model that looks nothing like a table check.
So the hospitality requirement is additive. It is not a trade against restaurant capability, and any shortlist where it becomes one has the wrong systems on it. The same logic applies to guest facing ordering: QR and mobile ordering at the pool deck only helps if the order it produces can still resolve a guest and post to a folio, which is not true of every QR product sold to hotels.
Hardware follows the outlet
A property has far more physical contexts than a restaurant does, and this is where the choice of point of sale hardware stops being cosmetic. A pool deck has sun, water and no cabling. A beach service round happens fifty metres from the nearest power socket. A banquet floor is reconfigured weekly. A lobby bar has a counter someone chose for how it looks. A kitchen pass needs a screen that survives heat and wet hands.
Broadly, mobile service positions want a handheld, or a handheld with payment built in where you would rather not send a server back to a station to close a card. A lobby bar or a coffee counter is usually a compact counter unit. A high volume outlet earns a full station. The pass wants a kitchen screen rather than a printer, particularly where one kitchen serves several outlets.
One detail matters more in a hotel than anywhere else: signature capture on the handheld. A room charge signed on the device and attached to the folio is what makes the charge defensible three days later. A room charge signed on a paper chit is a promise that the chit will still be findable, and at checkout, in a dispute, it frequently is not.
When you do not need any of this
If you run a single restaurant or bar with no rooms attached, none of the above applies to you, and paying for it is a waste. Buy a restaurant POS that is excellent at the restaurant job and spend the difference on something that moves revenue.
The less obvious case is a small hotel with one outlet serving breakfast only, included in the rate, with no a la carte and no bar. There, folio posting is effectively a daily cover count, and a good restaurant EPOS with a sensible report will do. The line is roughly this: you need hospitality specific software once you have two or more outlets, or meaningful a la carte revenue from resident guests, or packages more complicated than bed and breakfast. Any one of the three is enough.
Where to start
The evaluation goes wrong when it starts from vendor feature lists, because every list contains "PMS integration" and the phrase does not discriminate. Start from your own operation instead.
- Count your outlets honestly, including the seasonal ones and the ones with no menu. The number is usually higher than the org chart suggests.
- Write down every way a line can end. Card, cash, room charge, entitlement, comp, company account, voucher, deposit against an event contract. That list is your real specification.
- Get the rate codes and package inclusions from revenue management as an actual list. This is the document that separates systems, and almost nobody brings it to a demo.
- Then make vendors demo your list on your PMS, with a package guest and a disputed charge at checkout. Not their scripted scenario.
- Pilot the hardest outlet, not the easiest. The pool bar or banqueting, not the lobby cafe. A pilot that only proves the easy case has proved nothing you were worried about.
Do that and the shortlist tends to sort itself out quickly, because the number of systems that handle an entitlement correctly is much smaller than the number that claim to charge a room. If you want the broader survey of hospitality systems and formats first, the guide to hospitality point of sale systems covers that, and hotel food and beverage management covers the operational side of running the outlets themselves. When you are ready to look at how this works in practice across a property, the hotel and resort F&B platform is the place to start.
Read next: hotel cloud POS systems, hotel room service, and what EPOS systems are.
