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

Beverage service in the hotel event room: open bar, actual consumption or tickets

The hotel event room sells more beverage in one night than the bar in a week, and almost always with less control. Here are the three billing models, how each is recorded in the system, and a worked example with numbers to compare them.

A hundred-person wedding in your hotel’s event room moves more bottles in five hours than the lobby bar in a full week. And yet the bar has tickets, shift closes and a bartender who answers for the counter, while the event room usually has a notebook, a contract signed three months ago and an argument with the client the next morning. This article is about running the event room like the bar.

Three ways to bill beverages and one way to record them

In banquets there are three beverage billing models that repeat in every hotel: open bar per person, actual consumption per drink served, and prepaid tickets. Each one distributes risk differently between the hotel and the event client. What should not change is the recording: in all three cases, every drink that leaves the event room bar is entered on a ticket, deducted from inventory and tied to the event account.

That is the central idea. The billing model defines how much the client pays. The recording defines how much you know. A hotel that only records what it charges records nothing on an open bar, and that is why it does not know what the event cost until Monday’s inventory count.

Open bar: price per person, risk on the hotel

In an open bar the client pays a rate per guest for a number of hours, and guests drink without limit within the agreed list. Revenue is defined from the contract: confirmed guests times the rate per block of hours. Cost, on the other hand, depends on how much the guests drink, and there the hotel carries the risk.

That is why in an open bar recording matters more, not less. Every drink served is entered to the event account at zero price or at a reference price, depending on how your controller prefers to see it, but always with the recipe that deducts inventory. At the end of the night you know how many drinks were served, what they cost and what the real margin of the event was. Without that record, an open bar is a known revenue with an unknown cost.

Overtime and the guest count

The two classic open-bar disputes are the extra hour and the real number of guests. The system can help with both: the event account has an agreed start and end time, and any drink entered after the end time is flagged as overtime so the client sees it with hour and minute. The guest count is agreed by contract and confirmed with the banquet captain at the start, and that figure is written on the account, not in anyone’s memory.

Actual consumption: every drink to the event account

With actual consumption the client pays for every drink served at the banquet menu price. Risk switches sides: the hotel charges what it served, and the client accepts that guests may drink more or less than expected. It is the fairest model and the hardest to defend if you have no tickets.

Here the event room bar works exactly like any other revenue center of the hotel, with its own register and its own close. Every drink is entered with the server who requested it, the time and the recipe. The event account is visible in real time and the client can ask for a partial close at midnight to know where things stand. At the end, the account is tied to the group master folio or settled directly, and the client signs a detailed consumption, not a total on a sheet.

If the event has rooms, the event account and the group’s lodging folio coexist without mixing: one is the event room, the other is the rooms. How that master account is built is explained on the groups and banquets page (Groups and banquets).

Tickets: the client decides how much to host

In the ticket model the client buys a number of drinks in advance and distributes them among guests as a courtesy. Each ticket is redeemed for one drink at the event room bar. Whatever is left over is not served; whatever is missing, the guest pays out of pocket or the client authorizes more tickets.

Control with tickets has two parts. The first is the numbered physical or digital ticket: the system records which ones were issued and which were redeemed, and at the end says how many were left unused. The second is the drink: every redemption is entered as a sale at the price the client paid, deducts inventory and appears on the event account. Without the second part, tickets become a count of paper slips that nobody reconciles with the bottles.

What happens to leftover tickets

This is agreed in the contract and the system respects it: some hotels refund unredeemed tickets, some convert them into credit for the next event and some consider them sold. What matters is that the number of unredeemed tickets is exact, because that conversation with the client happens after the party is over and only the record remains.

An illustrative example with numbers

The figures below are invented to show the calculation. They are not market rates and they are not from any property. They serve only to compare the three models on the same wedding: one hundred guests, five hours, and an ingredient cost of 20 per drink served.

ModelHow it is billedHotel net revenueDrinks servedIngredient costGross margin
Open bar100 people × 250 per person25,000450450 × 20 = 9,00016,000
Actual consumption400 drinks × 70 each28,000400400 × 20 = 8,00020,000
Tickets300 tickets × 80, 260 redeemed24,000260260 × 20 = 5,20018,800
Illustrative example with invented figures. For tickets, the 40 unredeemed are assumed sold as per contract.

In the example, the open bar had the best guaranteed revenue from the contract but the worst margin, because guests drank more than the rate assumed. Actual consumption gave the best margin because the hotel charged for every drink. Tickets landed in the middle, with one figure only the record can give you: 40 unredeemed tickets worth 3,200 that the client will ask about the next morning.

What none of the three models gives you without a system is the drinks served column. And without that column you cannot calculate cost or margin, which are the two figures the controller will ask for on Monday.

How each model is recorded in the system

The three models share the same base: the event room is a revenue center of the hotel, with its bar, its banquet list and its close. Every event opens an account with a name, date, guest count, start and end time, and billing model. What changes is how each drink entered is valued.

  1. Open bar: the account carries one revenue line for the contracted package and every drink is entered at zero price with its recipe, so it deducts inventory and is counted without adding to the bill.
  2. Actual consumption: every drink is entered at the banquet menu price and added to the event account; the client can see the running total at any time.
  3. Tickets: the account records the ticket sale at the start and every redemption is entered at the paid price, marking the ticket as used; at the close the unredeemed ones are listed.
  4. In all three cases, drinks outside the package, such as a special bottle a guest requested, are entered to a separate account with whoever pays for them, so they do not get lost in the event account.
  5. At the close, the event account is tied to the group master folio if there is lodging, or settled directly, and the event room close is done separately from the lobby bar.

What the controller wants to see the next day

Under the hospitality accounting standard, banquet beverage is reported as event room revenue, not bar revenue, with its own cost. The controller wants three things on Monday: event revenue by item, beverage cost calculated from recipes and not from an eyeballed bottle count, and comps approved with the name of whoever approved them.

If the event was recorded drink by drink, the three things come out of the system in one report. If it was recorded with a notebook and a contract, the three things come out of a two-hour meeting. You can see how that report is built by revenue center on the reports page (Reports).

Frequent mistakes in the event room

  • Not entering drinks on an open bar because “it is already paid”, and losing the real cost of the event.
  • Letting the event bartender write drinks on paper and enter them at the end, when memory is gone.
  • Mixing a guest’s special bottles into the event account.
  • Not setting the end time on the account and arguing the extra hour from memory.
  • Counting leftover tickets by hand and discovering they do not match the bottles.
  • Closing the event room together with the lobby bar and not knowing which of the two had the shortage.
In short

Open bar, actual consumption and tickets distribute risk differently between the hotel and the client, but all three are recorded the same way: every drink entered with its recipe to the event account. Without that record you know the revenue and not the cost, and the event room margin is a guess.

What to do this week

  1. Review the contracts of the next three events in the room and identify the billing model of each.
  2. Agree with the banquet captain that the event room bar opens as a revenue center with its own account per event, whatever the model.
  3. Load the banquet list with recipes so every drink served deducts inventory even when entered at zero price.
  4. Agree with the front desk how the event account is tied to the master folio when the group has rooms.
  5. Ask the controller for the beverage report of the last event and compare what you have against revenue, cost and comps.

Inn Restaurant records the event room as one more revenue center of the hotel, with accounts per event under the three billing models and a close tied to the group master folio. If you have an event on the calendar, the 15-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.