Hotel with a restaurant: one booking system for rooms and tables, or two separate ones

A hotel with a restaurant is better served by one shared booking system for rooms and tables when a large share of hotel guests eat in its own restaurant. Two separate systems make sense when the restaurant lives mainly on outside guests, or when the hotel or the restaurant needs features only a specialist offers. What decides it is how often your team carries data from one program to the other today.

What breaks with two separate systems?

• The table for hotel guests. Reception cannot see whether there is room tonight. It phones the restaurant or enters half-board guests in the reservation book by hand. If a guest extends or leaves early, nobody changes it in the restaurant.
• The bill. Dinner is to go on the room bill. Without a link, the waiter writes a slip and reception types the amount in the next morning. If the slip is missing, so is the revenue.
• The guest data. The same guest sits in two databases, with two spellings and two allergy notes, one of them out of date. Access and erasure requests under the GDPR have to be handled in two places.
• The rules. The room has a cancellation deadline and a deposit, the table a different one or none. The guest receives two confirmations in two designs and two links to cancel.
• The overview. How many hotel guests are eating in tonight, how many seats are left for outside guests: someone works that out in their head.
• The costs. Two subscriptions, two training sessions, two contacts. When something does not match between the systems, nobody is responsible.

A note from Austria on the rules: the trade association's general terms and conditions for hotels apply only if they were demonstrably agreed with the guest, and they are currently under legal revision (page dated 4 February 2026). That is one more reason for rooms and tables to show their terms in one place.

What must a shared system be able to do?

Hotel software with an extra field for dinner is not yet a shared system. Check these points in a demo using your own procedures:

1. One guest, one record. The stay, table reservations and spa appointments belong to the same person.
2. A table from the stay. Reception reserves the table right in the booking, for one evening or for every night, and the reservation lapses if the stay is cancelled.
3. A real table plan. The restaurant works with tables, areas, service periods and walk-ins, not with a list of names. Outside guests reserve online from the same inventory.
4. Restaurant charges to the room. The amount lands as its own line on the stay account and is paid at check-out.
5. Separate payment rules. Rooms with a deposit, tables for groups with a card guarantee, spa appointments with prepayment, each with its own cancellation deadline.
6. Roles. Waiting staff see the table plan and not the room rates. Reception sees both.
7. Honest limits. Ask what the system does not replace: till, channel manager, staff rota.

What does the difference cost?

Worked example for a hotel with 25 rooms, 60 seats and half board. Separate systems: reception spends around 15 minutes a day entering tables and posting restaurant amounts. That is 7.5 hours a month, or € 187.50 at an employer cost of € 25 an hour. Two subscriptions come on top. If, in addition, a slip for € 90 goes missing on two evenings a month, that is another € 180. The minutes and amounts are assumptions. Put in your own figures; the calculation stays the same.

Fees for online payments are the same in both variants as long as the same payment provider is behind them. For Austria, Stripe lists 1.5% + € 0.25 for standard EEA cards (as of 11 October 2026). Do check, though, whether one of the two systems adds its own markup.

When are two specialists the better choice?

The last point deserves a second look. An interface between two good systems can close most of the gaps. Ask the vendor exactly what it transfers: only the bill amount to the room, or guest data, half board and cancellations as well. And ask who looks after it when one of the two systems is updated.

What stays separate in both cases?

Booking software is not a till. In Austria, according to the Economic Chamber (as of 23 June 2026), the cash-register obligation applies once a business exceeds € 15,000 in annual turnover, of which more than € 7,500 is cash turnover. Payments by debit or credit card on site count as cash for this purpose, as do your own vouchers accepted in place of money. So the restaurant needs a till with order-taking in any case. Plan it as a third system and settle how amounts get from there to the room.

How do you decide?

1. Count for a week: how many hotel guests eat in, how often someone enters a reservation or an amount by hand, how often something goes wrong in the process.
2. Write down which features you really use every week. Nothing else should drive the decision.
3. Settle the hard requirements first: do you need a channel manager, a portal for the restaurant, a particular till?
4. Ask to be shown your most frequent procedure, not the vendor's standard demo: arrival with half board, a table on the first evening, dinner charged to the room, departure.
5. Add up subscriptions and working time, for both variants.

How this works in EachVisit

EachVisit keeps rooms, tables and appointments in one account. From a stay you create table reservations for single nights or all of them, and if the stay is cancelled, the future reservations lapse. A restaurant amount can be posted to the stay account and settled at check-out. The restaurant works with a floor plan, service periods, walk-ins and a waiting list, and outside guests reserve online. A hotel with 25 rooms pays € 189 a month on the Mittel plan, restaurant and appointments included, with 0% commission. Stripe's fees apply. What EachVisit does not have: a cash register with order-taking, a channel manager (calendar sync via iCal only), housekeeping and rota planning, or reporting across all areas. If you need any of these in the same program, EachVisit is not the right choice today.