Product
Operation types
Pricing
Compare
Resources
Log in See a 15-minute demo ESEN
Article · 7 min

All inclusive: consumption that has value even when nobody pays for it, and the premium bar that does get charged

In an all-inclusive hotel the restaurant serves hundreds of plates a day that nobody pays for at the table. Here is how to record that consumption with an allocation value, how to post the extras to the guest folio and what the per-room report tells you.

In an all-inclusive hotel, the restaurant serves hundreds of plates a day that nobody pays for at the table. The guest already paid for everything in the rate, so the temptation is to record nothing: serve, clear, forget. The problem is that this consumption has a cost, a trend and a guest behind it, and if you do not record it, the only thing that knows what happened in your hotel restaurant is the kitchen bin.

Included does not mean free

The fact that the guest does not pay at the table does not mean the consumption has no value. Every buffet breakfast, every domestic beer at the pool bar and every club sandwich from room service has an ingredient cost, a server hour and a slot in the kitchen. The front desk collected the price when it sold the room on an all-inclusive plan. What the restaurant delivers afterwards is the part of the service that backs up that price.

If you do not record that consumption, you lose three things at once. You lose the real food and beverage cost per occupied room, because you do not know what was served. You lose the link between what is consumed and what is purchased, so inventory becomes guesswork. And you lose the trail of who consumed what, which is exactly what you need to tell the included guest apart from the outside customer who walked in through the lobby and ate without a wristband.

The rule is simple: everything that leaves the kitchen or the bar is recorded as an order, with its guest or its table, even when the amount to collect is zero. The record is what separates an operated restaurant from a dining room that just serves.

Allocation value: what a plate that is already paid for is worth

When consumption is included in the rate, the question that lands on the controller’s desk is what that consumption is worth in the books. There are two bad answers and one good one. The first bad answer is to record it at zero, because then the hotel restaurant looks like it generates nothing and the rooms department looks like it generates everything. The second bad answer is to record it at menu price, because then you inflate food and beverage revenue with money that never came in twice.

The good answer is the allocation value. The property decides what share of the all-inclusive rate belongs to food and beverage, and that value is assigned to each included item as an internal price. The hospitality accounting standard, USALI, provides for exactly this allocation: the rate is split between rooms and food and beverage using a fixed rule, documented and applied the same way every time.

The allocation value does not have to be perfect. It has to be consistent. If an included breakfast is worth 120 in January, it is worth 120 in July, and if it changes, it changes with a note from the controller and a date. What kills the report is not the wrong value: it is the value that changes without anyone knowing when.

One value per type of consumption

  • Buffet breakfast: a fixed value per registered person, regardless of how much they eat.
  • Lunch and dinner at the buffet restaurant: a fixed value per cover.
  • Domestic drinks at the bar and the pool: a value per drink served, even if small.
  • Included room service: a value per dish, because the delivery cost is higher than in the dining room.
  • Specialty restaurant with reservation: a higher value per cover, because the ingredients are different.

What does get charged: the premium bar, the specialty dinner and the minibar

Modern all inclusive is almost never all. There is a premium spirits list that is charged, a dinner at the specialty restaurant with a surcharge, a bottle of wine with a label, a treatment or an excursion billed separately. That is the property’s incremental revenue, and it is where the restaurant stops being a cost center and goes back to being a revenue center.

Here the problem changes its nature. It is no longer what my service is worth, but how I charge for it without the guest reaching for a wallet. In an all-inclusive resort nobody carries cash at the pool, and the guest who bought a plan with no extra charges gets annoyed when asked to pay. The answer is the same as in any hotel: room charge, verified against the folio, with the guest identified and the consumption itemized. The guest says "To my room, please." and the server confirms on screen that the stay exists and that the plan does not cover that product.

The menu has to state clearly what is included and what is not. And the point of sale has to know it too: if the server keys in a twelve-year whisky as if it were a domestic rum, the hotel gave away a premium drink and nobody noticed. The catalog separates the two groups, tags them with an allocation price or a real price, and the system makes the distinction without the server having to remember.

The wristband is not a folio

In many all-inclusive properties, the guest’s identification is the wristband. The server sees the color and knows whether the plan covers premium drinks or not. That works for serving, but it does not work for recording. The wristband has no room number, no name of the primary guest, and it does not say how many adults and children are on the booking.

The folio does. When the point of sale looks up the stay at the front desk, it knows which room it is, which plan was purchased, how many people are registered and until what day they stay. With that, included consumption is recorded against the folio at allocation value and extras are posted to the same folio at real price. The guest sees a single statement at check-out, and the controller sees a single source for both kinds of consumption.

The room charge page (Room charge) explains why a text field with the room number is not enough. In all inclusive this matters twice as much: without a folio, you cannot know whether the four breakfasts at table 12 came from one room with four guests or from two rooms with two, and that difference is what turns into leakage.

An illustrative example with numbers

The figures below are invented to show the calculation. They are not data from any property or from the industry. They only serve to follow the reasoning for a resort with 100 rooms, an all-inclusive plan and a fully booked weekend.

ItemValue (illustrative example)
Occupied rooms per night100
Registered guests per night220
Nights in the weekend2
Included covers served (breakfast, lunch and dinner)220 × 3 × 2 = 1,320
Allocation value per cover150
Included consumption at allocation value1,320 × 150 = 198,000
Extra charges (premium bar and specialty dinner)36,000
Total F&B consumption recorded198,000 + 36,000 = 234,000
Occupied room nights100 × 2 = 200
F&B consumption per occupied room234,000 ÷ 200 = 1,170
Illustrative example. Figures are invented to show the calculation; they are not data from any property.

In the example, included consumption at allocation value is the base, and the extras are what moves the real result. If next weekend included covers stay the same and extras rise to 50,000, consumption per occupied room rises to 1,240. If extras fall to 20,000, it drops to 1,090. That variation is what the food and beverage director can work on: the buffet is already paid for; the premium bar is not.

Now look at the other figure: 1,320 included covers for 220 guests over two days is exactly three meals per person per day. If the record shows 1,500, someone is serving covers to people who are not guests, or recording twice. If it shows 1,000, there are guests who are not eating at the hotel, and maybe the restaurant across the street knows why. Without a record of included consumption, neither signal exists.

The per-guest report: what every charge tells you

With all consumption tied to the folio, the per-guest report stops being a chain luxury and becomes a normal screen. For each room you see how many included covers it consumed, at which revenue centers, at what time, and which extras it posted. That answers questions that in an all-inclusive property are worth gold.

  • Which rooms have not had breakfast in three days: they may have a problem with the service and nobody has asked.
  • Which rooms post premium drinks every night: candidates for a specialty dinner offer.
  • Which revenue center concentrates the extras: if the pool bar sells more premium than the lobby bar, that is where the best bartender goes.
  • How many included covers were served without a folio: that is your leakage indicator for an open dining room.
  • Which group or corporate agreement consumes above the allocation value: a data point for the next negotiation.

The per-guest report also protects the hotel at check-out. When a guest disputes an extra charge, the detail shows the table, the time, the server and the dish. A charge with context is explained in twenty seconds; a charge without context gets voided to avoid an argument. The reports page (Reports) shows how this view is built without anyone having to cross-reference spreadsheets.

The mistakes that break the consolidated figure

After seeing several all-inclusive operations, the mistakes repeat. They are not system mistakes, they are judgment mistakes, and that is why it is worth naming them one by one.

  • Recording included consumption at zero. The restaurant disappears from the income statement and cost per cover becomes impossible to calculate.
  • Recording included consumption at menu price. Food and beverage revenue is inflated and the margin looks better than it is.
  • Changing the allocation value without a date or a note. Months stop being comparable with each other.
  • Letting the server decide what is premium. The menu and the catalog decide, and the server only picks the right product.
  • Closing the shift without separating included from extra. Cash from the premium bar gets mixed with covers at allocation value and no total reconciles.
  • Charging extras in cash at the pool. You lose the folio, you lose control and you lose the data for the per-guest report.

They all share the same root: treating included consumption as if it were not consumption. The fix is also the same: one order for everything that goes out, with a folio, a value and a revenue center.

In short

In all inclusive, included consumption is always recorded, at a fixed allocation value and tied to the guest folio; extras are posted to the same folio at real price. That way the hotel restaurant stops being invisible and the per-guest report tells you who eats, who does not and who pays more.

What to do this week

  1. Agree with the controller on an allocation value per type of included consumption and write it down with a date on a sheet everyone can see.
  2. Review the bar menu and tag in the catalog which products are premium with a charge and which are included, without relying on the server’s memory.
  3. Require that every included cover be recorded as an order against the guest folio, even when its total is zero.
  4. Close this week’s shift separating included consumption at allocation value, extra room charges and direct payments from outside customers.
  5. Pull the report of included covers served without a folio and compare it with the guests registered by the front desk.
  6. Pick the ten rooms with the most premium consumption and share the list with the food and beverage manager for the next offer.

Inn Restaurant records included consumption at allocation value and extras at real price, both against the guest folio, and builds the per-room report with no extra work for the server. You can see how a plan is set up on the all-inclusive page (All inclusive), and if you want to see it with your own menu, the fifteen-minute demo is booked on the contact page (contact).

Your hotel’s restaurant already sells well. Now the hotel needs to know it.

Fifteen minutes, with your menu and your tables. Nothing to install.

See a 15-minute demo
We use the minimum to make the site work and to know which pages are useful. You can reject the rest.