Choosing a POS is the most expensive technology decision a restaurant makes, and it is almost always made during a 40-minute demo. The system that records the orders ends up deciding how long a server takes to work a table, whether the kitchen receives dishes in the right order, and whether at month end you can tell what margin each dish leaves. This guide covers the criteria that genuinely separate a POS that holds up from one that gets in the way.
In short: a restaurant POS records orders, tracks the status of every table, sends dishes to the kitchen and settles the bill. Unlike a retail POS, it works on a tab that stays open over time — edited, split and moved between tables — rather than on a sale that starts and ends at the counter.
Why a retail POS doesn’t work in hospitality
This is the confusion that costs the most money. A shop POS models a transaction: a customer walks in, products are scanned, they pay and they leave. A restaurant models a relationship that lasts an hour and a half and changes constantly.
The differences you notice on the first day of service:
| Real situation | Retail POS | Hospitality POS |
|---|---|---|
| Tab open throughout the service | Doesn’t exist | Native |
| Adding dishes across several rounds | New ticket every time | Same tab |
| Moving guests to another table | Manual | Tab transfer |
| Splitting a bill six ways | Unworkable | Per guest or per item |
| Sending to kitchen and bar separately | No | Printing or KDS per station |
| Voiding a dish already sent | No audit trail | Logged and auditable |
If the system you are shown can’t handle these six situations without workarounds, it isn’t a hospitality POS no matter what the vendor calls it.
The six criteria that actually matter
1. A real floor plan
The POS has to understand your room: tables, zones, terrace, bar. It sounds obvious, and yet plenty of systems treat a table as a text label. The test: in the demo, ask them to move a tab from table 4 to terrace 2 with the order already fired to the kitchen. If the only way is to void it and start again, your staff will be doing exactly that every night.
2. Ordering at the table
Letting the server take the order on a phone next to the table, and fire it to the kitchen from there, removes the walk back to the station. In a high-turnover site that is the difference between serving three sittings and two. Check that it works with the Wi-Fi down: serious systems queue the order on the device and sync it when signal returns.
3. Flexible payment
Splitting bills is the operation that most often jams up a close. You need to split by guest, by item and by free amount, with several payment methods against the same tab. Add QR codes and mobile wallet payments so guests can settle from their own phone, which clears the queue at the till on the way out.
4. A connected kitchen
A KDS (kitchen display system) sequences dishes by prep time and flags delays. Against a printed ticket it wins on two counts: no paper gets lost, and you get a record of how long each dish takes from the moment it goes in to the moment it leaves. That data is the basis for fixing the bottlenecks in your service.
5. Integrations that already exist
Ask about specific integrations and ask to see them running, not on the “coming soon” list:
- Delivery: platform orders should land as an order in the POS, with nobody keying them in twice
- Accounting: export to the finance system you already use
- Time and attendance: crossing sales by hour with staff hours is what lets you size the rota
- Inventory: automatic depletion of recipe quantities when a dish is sold
6. Data ownership and an open API
The question almost nobody asks in the demo: if I leave tomorrow, what do I take with me? You need to be able to export sales history, tickets and recipes in a readable format. A POS without an open API becomes a bottleneck the moment you open a second site and want to consolidate data. We have seen this enough times to put it among the disqualifying criteria, not the nice-to-haves.
Compliance: the part that isn’t negotiable
Fiscalisation rules vary a lot by country, and this is where an international buyer gets caught out. Depending on the market you operate in, a POS may have to keep chained, unalterable sales records; run on certified or registered software; write every transaction to a secure recording module; issue a receipt for every sale; transmit daily sales data to the tax authority; or produce a standardised audit file on demand.
A few examples of how different the regimes look: Germany requires a certified technical security device on the till plus a defined export format for tax audits, Italy requires daily electronic transmission of takings to the tax authority, Portugal requires invoicing software certified by the tax authority together with a standard audit file, and Spain requires unalterable invoicing records under its anti-fraud rules. Compliance calendars in several of these countries have shifted more than once, so confirm the dates currently in force with your own tax authority or accountant before signing anything.
What you can demand today, whatever the deadline turns out to be:
- A written compliance statement from the vendor, naming the country or countries you operate in
- Chained sales records, with no way to delete a ticket without leaving a trace
- The official audit export demonstrated live in the demo, not promised in a slide
- Regulatory updates included in the subscription, not sold as a separately billed module
That last point is where the surprises show up: older systems that reach compliance through an add-on with its own price tag. Ask explicitly and get it in the contract.
Hardware: proprietary vs standard
Many vendors sell the terminal alongside the software. It is convenient on day one and expensive in year three.
Proprietary hardware: the vendor supplies and maintains the equipment. Upside: a single point of support when something fails. Downside: replacing a broken tablet happens at their price and on their timeline, and contract renewal ends up tied to the life cycle of the equipment.
Standard hardware: off-the-shelf tablets and phones, generic network printers, a compatible cash drawer. Upside: if a tablet breaks on a Saturday you replace it in any shop. Downside: the site’s network is your responsibility.
For a single site with little technical staff, managed hardware makes sense. From three sites up, standard hardware usually works out considerably cheaper and leaves you free to change software without throwing away the devices.
What it really costs
Indicative ranges in the European market, so you arrive at the negotiation with references:
| Profile | Software cost | What it includes |
|---|---|---|
| Single site, 1 terminal | 50-100 EUR/month | Orders, payment, basic reporting |
| Site with several terminals | 100-250 EUR/month | Mobile ordering, KDS, inventory |
| Multi-site chain | 250-500 EUR/month per site | Consolidation, analytics, API |
Line items that rarely appear in the first proposal and are worth asking about: setup and installation, staff training, migration of sales history, licence per additional terminal, the fiscal compliance module, and the cost of out-of-hours support. In hospitality, weekend support is not an optional extra: the weekend is when you take the money.
Four mistakes that keep repeating
- Choosing on the demo instead of on service. Ask for a trial in your own site on a Friday night. A system that flows with four tables can seize up with thirty.
- Not training the team. The best POS badly used performs worse than a simple one properly learned. Budget training hours and a second session two weeks in, once the real questions have surfaced.
- Ignoring the exit. Signing without knowing how to export your data is signing a lock-in you didn’t negotiate.
- Buying features you won’t use. The advanced loyalty module is worth nothing if nobody is going to run the campaigns.
When an off-the-shelf POS falls short
A standard product covers the standard case well. It stops covering it when the business has a flow of its own: mixed restaurant-and-shop formats, central production supplying several sites, different pricing by time slot or channel, or an in-house ERP that has to be talked to in real time.
The warning sign is measurable: when the team spends hours reconciling by hand what the system can’t do, that cost has already passed the cost of solving it properly. At Soamee we work on that point in two ways: integrating the existing POS with the rest of the stack through its API, or building the layer the off-the-shelf product doesn’t cover. Our experience in workforce management for hospitality came out of Orquest, and the premium food service side out of GOXO.
If you are deciding in the next few weeks, it is worth seeing first how the POS fits into the rest of the system: our guide to digitizing a restaurant sets out where to start, and restaurant software covers what we build for the sector, including our restaurant POS with floor plan.
Checklist before you sign
- Trial in real service, not in a demo
- Tab transfer between tables with the order already sent
- Bill splitting by guest, by item and by free amount
- Operation with the network down
- Written compliance statement for your country
- Regulatory updates included in the subscription
- Full history export in a readable format
- Weekend support cost confirmed
- Required integrations seen working
- Fixed price per additional terminal
Are you choosing a POS, or fighting with the one you already have? Tell us about it and we’ll say honestly whether you need to change systems or simply connect the one you have properly to everything else.