The wedding at the hotel: how to record consumption in the ballroom, the bar and the guests’ rooms
A wedding at the hotel is not one account: it is three. The couple’s, each lodged guest’s and the hotel’s own. When the three get mixed, someone overpays, someone does not pay, and the controller finds out on Monday.
On the Saturday of the wedding, your hotel restaurant becomes four businesses at once: the banquet in the ballroom, the event bar, the everyday bar full of guests in suits, and the rooms of the relatives who arrived on Thursday. Everyone consumes, everyone signs, and almost nobody carries a wallet. If the point of sale does not know which account each signature belongs to, Sunday morning you have a pile of checks and a single question: who pays for this?
Three accounts, not one
The confusion starts when the hotel thinks of the wedding as "the event". The event is a contract, but the weekend’s consumption belongs to three different pockets, and the system has to know which is which before the first guest walks in.
- The event master account: it belongs to the couple, or whoever signed the contract. It receives the banquet, the contracted bar, the ballroom rental and everything the contract says they pay. It has a deposit, a balance and a settlement date.
- The folio of each lodged guest: it is personal. It receives the room, breakfast if not included, whatever was ordered at the bar outside the event and the room service at dawn. It is settled at check-out with that guest’s own card.
- The hotel’s internal account: the courtesies. The bridal suite, the welcome drink, the tasting dinner beforehand. Nobody is charged for them, but they cost money, and the controller needs to see them as cost, not as lost sales.
A consumption posted to the wrong account does not disappear: it changes owner. The wine an uncle ordered at the lobby bar and that landed on the master account is paid by the couple without knowing it. The bottle the contract did cover and that landed on the uncle’s folio is paid by him, annoyed, at the front desk. Neither mistake is visible on Saturday. Both are visible in the review.
The ballroom: sold before it is served
The banquet is the largest consumption of the wedding and the easiest to record, because almost all of it was sold in advance. The contract states a guaranteed number of people, a price per person and a list of what is included. What the point of sale has to do on Saturday is not to sell: it is to confirm that what left the kitchen matches what was contracted and to record only what was added on top.
That means the ballroom needs its own revenue center in the system, separate from the restaurant and the bar. If the banquet is captured as one giant restaurant table, restaurant sales are inflated that day, revenue per occupied room is distorted and the banquet report is empty. Under USALI, banquets is its own department and wants its own line, as explained on the groups and banquets page (Groups and banquets).
What does get added the same day
Almost every wedding asks for something at the last minute: two more tables because unconfirmed cousins showed up, an extra hour of bar, the cake the family brought and the hotel cut and served for a service fee. Each of those extras must enter as a new line on the master account, with the time and the name of whoever approved it on the couple’s side. Without that name, Monday is their word against yours.
The bar: open or by consumption, and the line between them
The event bar has two modes and each one is recorded differently. With an open bar, the contract sets a price per person or per hour, and what is served generates no charges: it generates inventory consumption against revenue already agreed. With a bar by consumption, every drink is a sale that accumulates on the master account, or on each guest’s account if that is what the couple decided.
The problem shows up at the border. The open bar ends at one in the morning, but the party does not. From that hour on, every drink is real revenue and someone has to pay for it: the couple, if they approved the extension, or each guest. If the bartender does not see on screen at what time the rule changed, drinks keep going out "from the bar" and that sale exists nowhere.
Best practice is for the rule to live in the system with a start time and an end time, and for the bar’s point of sale to switch mode by itself when it expires. The bartender sees the notice, informs the guest and asks whether they will pay or charge it to their room. No decision is left to memory.
The guests’ rooms: group rate, personal consumption
Lodged guests arrive with a group rate negotiated by the couple, and many hotels assume that everything else "goes to the group" too. It does not. The group rate is a room price; the folio is still personal. What that guest orders in the restaurant on Friday night, at the pool bar on Saturday noon or from room service at three in the morning is theirs, unless the contract says otherwise for a specific item.
This is where the room charge has to be verified rather than typed. A guest who says "to my room, please" at the bar has to exist as an active guest in a room of the wedding block, and the charge must land on that folio, not on the master account or on the room next door. If the server only types a number into a text field, the wedding Saturday is the day of the year when the most charges get lost, as detailed in the article on why a text field is not enough (Room charge: why a text field is not enough).
When the couple does pay for something the guests consumed
It is common for the contract to cover Sunday breakfast for the whole block, or the parents’ first night. That does not change the rule: it changes the destination of one specific line. The guest’s Sunday breakfast is recorded on their folio and transferred to the master account with a reason ("covered by event contract"). The guest sees on their statement that it existed and that they did not pay it. The couple sees it added to theirs. Nobody has to explain anything at the front desk.
An illustrative example with numbers
The figures below are invented to show how consumption is split among the three accounts. They are not from any wedding or any hotel; they only serve to follow the arithmetic.
An example wedding has 120 guests with a banquet package of 850 per person, which includes a three-course dinner and a four-hour open bar. The couple requested one extra hour of bar at 6,000 per hour. Thirty rooms in the block were occupied at the group rate, and over the weekend those guests consumed 18,400 in the bar, the restaurant and room service outside the event. The hotel gave away the bridal suite and a welcome drink at an internal cost of 2,400.
| Item | Account it goes to | Amount (illustrative example) |
|---|---|---|
| Banquet: 120 × 850 | Event master account | 102,000 |
| Extra bar hour: 1 × 6,000 | Event master account | 6,000 |
| Guest consumption outside the event | Each guest’s folio (30 folios) | 18,400 in total |
| Bridal suite and welcome drink | Hotel internal account (courtesy) | 2,400 cost, 0 revenue |
| Master account total | Event master account | 108,000 |
| Deposit paid at signing (50 %) | Event master account | 54,000 |
| Balance to settle | Event master account | 54,000 |
Notice what is not on the master account: the guests’ 18,400. If that consumption had been posted "to the event" out of habit, the couple would have received a balance of 72,400 instead of 54,000, and Monday’s argument would have lasted longer than the party. And notice the 2,400 in courtesies: they are not revenue, but the controller needs them to know what it really cost to win that wedding.
What the controller sees on Monday
A well-recorded event leaves three clean reports. The first is the event statement: contract, approved extras, deposit and balance, ready to be sent to the couple before they leave the hotel. The second is the close of every revenue center over the weekend, where the ballroom and the event bar appear as their own centers and the restaurant and the lobby bar are not loaded with sales that were never theirs.
The third is the reconciliation between room charges posted at the points of sale and what the front desk collected across the block’s thirty folios. If those two figures do not match, there is consumption that was served and never charged, and a wedding Saturday is the day when that gap tends to be largest. With the three reports, the controller can say how much the wedding brought in, what it cost and what it left, separating the block’s lodging, the banquet and the loose consumption.
Without them, what the controller has is a weekend total that cannot be split among departments, and a wedding that looks profitable or ruinous depending on which account each bottle went to.
Mistakes that repeat at every wedding
- Capturing the banquet as a restaurant table. It inflates the restaurant, empties banquets and distorts that day’s revenue per occupied room.
- Letting the open bar stay "open" past the contracted hour. Every drink after that is a sale that does not exist.
- Posting to the master account what a guest ordered outside the event. The couple pays without knowing or disputes it, rightly.
- Accepting last-minute extras without a name or a time. On Monday nobody remembers who asked for the two additional tables.
- Recording courtesies at zero price without flagging them as courtesy. The controller cannot measure the real cost of the event.
- Typing the room number instead of verifying the stay. In a block of thirty rooms, crossed charges are only a matter of time.
A wedding at the hotel is three accounts: the couple’s master account, each guest’s personal folio and the internal courtesy account. The ballroom and the event bar are their own revenue centers, the open bar switches off at its hour in the system, and every room charge lands on a verified folio, not on the one the server remembers.
What to do this week
- Review the contract for the next wedding and underline every item the master account covers. Everything not underlined belongs to the guest, and the team must know it before Friday.
- Create, if they do not exist, the ballroom and the event bar as revenue centers separate from the restaurant and the lobby bar.
- Configure the open bar with a start and end time in the system, and define what happens with drinks after that: master account with approval, or the guest’s folio.
- Agree with the front desk that every room in the block is linked to the event, so the room charge verifies the stay and does not depend on a typed number.
- Define who on the couple’s side can approve extras on the day of the event, and capture that name on every added line.
- Prepare the event statement template with deposit, extras and balance, to hand over on Sunday before check-out.
Inn Restaurant handles the ballroom, the event bar and the lobby bar as separate revenue centers, with the event master account kept apart from each guest’s folio and room charges verified against the stay. If there is a wedding on your calendar, the fifteen-minute demo on the contact page (contact) is a good way to see it before that Saturday.
More articles
Corporate credit in the hotel restaurant: limits, terms and who signs off
Extending credit to a company is easy. Collecting it is not. Here is the corporate guest receivable explained from the hotel restaurant: the limit, the payment term, the signature that approves and the alarms that keep an account from becoming uncollectible.
Invoicing a travel agency for its guests’ consumption without disputes
The agency sends guests to your hotel with a meal plan, the restaurant serves them, and at month end the invoice goes out. If the invoice does not carry the detail per guest and per day, the agency will send half of it back. Here are the agreement, the cap and the report that prevent that.
Agreements that expire: why the system, not the server’s memory, must switch the rule off on the date
Every agreement with a company has an end date. The problem is that nobody in the hotel restaurant sees it: the server applies the usual discount, the guest signs, and the controller discovers weeks later that the folio was billed under a dead rule.
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.