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

How to set up a corporate agreement that keeps food and alcohol apart

The company pays for its traveler’s dinner, but not for the bottle of wine. This guide explains how to write that rule into your hotel restaurant so the check splits itself, without the server having to ask.

The agreement with the company contains a sentence that looks simple: meals covered, alcoholic drinks paid by the guest. In the hotel’s sales office that sentence gets signed in two minutes. At a restaurant table, at nine in the evening, with a guest who ordered a pasta, two glasses of wine and a coffee, the same sentence becomes a check somebody has to split by hand. This guide exists so that nobody has to.

What separating means in an agreement

A corporate agreement is a deal between the hotel and a company: the company sends its travelers, the hotel gives them a rate and certain consumption, and at the end of the month the hotel invoices the company for whatever the agreement covers. Everything else is paid by the guest at the front desk on check-out. Separating food from alcohol means the same restaurant check has two destinations: one part goes to the company account and the other to the guest’s personal account.

The key point is that the split is not a decision made by the server or by the front desk. It is a rule of the agreement and, like any rule, it has to be written somewhere the system reads every time a check is closed. If the rule lives in an email, in the manager’s memory or on a note taped to the register, it will be applied correctly on Monday and incorrectly on Saturday.

The company accounts page (Master accounts and agreements) explains the whole model. Here we focus on one part only: how to write the alcohol rule so the hotel’s point of sale applies it on its own.

The three levels where the rule can live

There are three ways to tell the system what the company pays for. They go from general to specific and they can be combined. Start with the simplest one and go down a level only when the agreement asks for it.

By category

This is the most common level. Every item on the menu belongs to a category: food, non-alcoholic drinks, beer, wine, spirits, tobacco. The agreement marks which categories it covers, and the typical combination is food plus non-alcoholic drinks. The server configures nothing: the pasta and the glasses are rung up as usual, and when the check is closed against the guest folio the system sends each line to the payer it belongs to.

The advantage is that it is set up once and works for the entire menu. The disadvantage is that the menu has to be categorized properly. A non-alcoholic cocktail created under the cocktails category will land on the wrong side, and nobody will notice until the company complains.

By product

Sometimes the company covers a category with exceptions. It covers food, but not the most expensive cut on the menu. Or it covers non-alcoholic drinks, but not energy drinks. There the rule goes down to product level: the specific item is flagged as excluded from the agreement even though its category is covered. It is the exception to the rule, rarely used, but when it is needed it is needed badly.

By time and by revenue center

The third level is time and place. The company covers breakfast and dinner, but not bar consumption after eleven at night. Or it covers food in the restaurant, but not at the pool bar. The agreement says from this hour to that hour, or in this revenue center, and the system applies the rule according to the time the check was opened and the place it was opened in.

A rule that depends on time is written as a rule, not as a field on the product. The eggs at eight in the morning and the eggs at eleven at night are the same product; what changes is who pays for them, and that is decided by the agreement rule together with the clock.

What it looks like at the table

Let us follow a full check. The numbers below are made up to show the calculation; they are not data from any hotel or any real agreement. A guest from a company with an agreement has dinner in the hotel restaurant. The agreement covers food and non-alcoholic drinks up to a cap of 450 per person per day, and excludes alcohol.

Line on the checkAmountPayer according to the rule
Salad120Company (food)
Pasta210Company (food)
Two glasses of wine180Guest (alcohol)
Sparkling water40Company (non-alcoholic drink)
Coffee45Company (food)
Check total595415 company + 180 guest
Illustrative example with invented figures. Amounts are shown before tax to keep the reading simple.

There is one check. The guest sees a single document for 595, says "To my room, please." and signs once. Underneath, the system opens two charges against her folio: 415 flagged as agreement, which the company will receive on its monthly invoice, and 180 on the personal account, which the guest will settle at the front desk on check-out. The 450 cap was not exceeded, because the 180 of wine never counted toward the cap: only covered items count.

Had the guest also ordered a dessert for 60, the covered subtotal would have reached 475. The first 450 go to the company and the remaining 25 move to the personal account. The rule does that too, not the server, and it is written on the folio with the reason: daily cap exceeded.

The cases that break the rule if you did not plan for them

Every configuration is tested by the odd cases. These are the ones that show up in the first week at any hotel that starts running agreements.

  • The shared bottle. Three travelers from the same company order a bottle of wine. It is alcohol and goes to a personal account, but whose? Define in the agreement whether it is split equally among the folios at the table or charged to the folio of whoever signs. The rule must pick one option and apply it the same way every time.
  • The non-alcoholic beer. If you created it under the beer category, the guest pays for it. If it sits under non-alcoholic drinks, the company pays. Go through the menu with the agreement in hand before going live.
  • The welcome cocktail that contains liquor. If it is a courtesy of the hotel, it is posted at zero and enters no account. If it has a price, it is alcohol and goes to the guest, even if it was offered at the front desk.
  • The dinner that starts at ten thirty and ends at eleven fifteen. The time rule is applied using the opening time of the check, not the closing time. Write it that way into the agreement so you never argue about it.
  • The outside guest. A traveler with an agreement invites a client of his to dinner. Many agreements do not cover the invitee. The per-person, per-day cap solves almost everything: if dinner for two exceeds the cap for one, the excess goes to the traveler’s personal account.

Setting it up step by step

  1. Read the signed agreement and underline every sentence that says what is covered, what is not, up to how much, at what time and in which revenue center. If a sentence does not fit into those five questions, ask for it to be rewritten before configuring anything. There is a full guide on how to write one that does not generate disputes (/blog/como-escribir-un-convenio-corporativo-que-no-genere-pleitos).
  2. Review the category of every item on the restaurant, bar and room service menus. It is the boring job and it is the one that prevents the complaint: every alcoholic drink in an alcohol category, every non-alcoholic drink outside of them.
  3. Create the company as an agreement account with its covered categories, its per-person, per-day cap and its time or revenue center limits if any.
  4. Flag the product-level exceptions if the agreement has them. If it does not, do not invent any.
  5. Run a test dinner with the folio of a fictitious guest from that company: order food, alcohol and a non-alcoholic drink, close to the room and check that the folio shows two charges with the right amounts.
  6. Show the result to the controller and the front desk before the first real arrival. They will see those two charges every day and must know how to read them.

What each person in the hotel should see

The server sees the usual menu and the usual check. They should not pick a payer or ask whether the wine goes separately. Their only signal is that, when closing to the room, the system confirms the guest exists, is in house and has an agreement. Any configuration that requires the server to remember something will fail on the shift with the most tables.

The front desk sees the folio with the two charges apart: one labeled agreement and one personal. On check-out it collects only the personal one and explains, if the guest asks, that the rest is paid by the company. No calculator at the counter and no calls to the restaurant to ask what each charge was.

The controller sees, at month end, a report per company: how many agreement charges, in which categories, how many excesses moved to personal accounts and how many folios closed with no balance. That is the basis of the invoice, and also the basis of the food and beverage report that separates corporate sales from direct guest sales. The corporate traveler (Corporate traveler) is the easiest segment to measure when every charge carries its agreement attached.

Mistakes that keep repeating

  • Writing the rule on the product, along the lines of "this wine is always personal", instead of in the agreement. When the second company arrives with different rules, you will not be able to serve it.
  • Letting the server pick the payer with a button. That is the open door for alcohol to end up on the company invoice because the guest asked nicely.
  • Not defining what happens with the excess over the cap. If it is not written down, the front desk will forgive it or collect it depending on the mood of the day.
  • Forgetting tax and service. Is the cap before or after tax? Does it include the suggested gratuity? Decide and write it into the agreement.
  • Not testing with a fictitious folio. The first test should never be with a real guest or with the hotel’s biggest account.
In short

The agreement says what the company pays for and the system applies it line by line, by category, by product or by time, splitting the check into two charges against the folio without anyone doing the math. The server does not pick a payer and the front desk does not use a calculator.

What to do this week

  1. Pull out your hotel’s active agreements and mark, in each one, the alcohol sentence and the cap sentence.
  2. Review the category of every drink on the restaurant and bar menus, one by one.
  3. Pick a single agreement and configure it with covered categories, cap and time limits.
  4. Run the test dinner with a fictitious folio and check the two charges from the front desk.
  5. Ask the controller to compare the agreement report against last month’s invoice made by hand.
  6. Write down the shared bottle rule and the outside guest rule before they show up.

Inn Restaurant applies the agreement rules against the guest folio at the moment the check is closed and splits it between company and guest without the server stepping in. If you want to see how your own agreement looks once configured, 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.