Why room charge is an accounting decision, not a payment method
When the guest says “to my room, please”, the hotel restaurant sold but did not collect. Here is what happens in the folio, in the drawer and in the report, and why treating it as one more payment button costs you every night.
The guest finishes dinner, the server brings the check and hears the usual line: “To my room, please.” In most hotel restaurants that moment is handled as if the guest had chosen card instead of cash. It is not that. What just happened is that the restaurant sold and did not collect, and the collection moved to another department, another moment and another document. That is an accounting decision, and if your system does not treat it as one, the shift close and the hotel report will lie a little every night.
What it looks like: one more way to pay
On the screen of almost any point of sale, room charge sits next to cash, card and transfer, one more button in the list of payment methods. It is convenient for the server and that is why it was built that way. The problem is that the convenience hides what happens next: cash and card close the check with money; room charge closes it with a promise.
The promise says: the front desk will collect this consumption when the guest checks out, against the guarantee left at check-in. The restaurant received nothing. Count the drawer at eleven at night and the charge is not there, and it has no reason to be. But if the system classified it as a payment method, your close adds it up as if it were.
The confusion does not belong to the servers. It belongs to the design. When a system built for a street restaurant is installed in a hotel, room charge gets bolted on in the same place where meal vouchers used to be. And a patch inherits the logic of whatever it patches.
What actually happens: a sale with deferred collection
When the guest says “to my room”, three different things happen at once. The restaurant records food and beverage revenue: the sale already took place, the dish was cooked, the wine was opened. The hotel records a receivable against a guest: someone owes that amount and will pay it on the way out. And the guest folio grows: the consumption line is added to the room nights and to whatever else has been posted.
Notice that money appears in none of the three. Revenue appears, debt appears, and a document that supports the debt appears. That is why we call it an accounting decision: what you are deciding is which book the sale is written in and who becomes responsible for turning it into cash. Order and payment are two separate things, and room charge is the clearest case of that separation in the entire hotel operation.
Treat it as a payment method and the separation disappears from the system but not from reality. The money will still be missing from the drawer, the folio will still be waiting for the front desk, and the controller will still have to explain the difference with a spreadsheet on the side.
The journey of a charge: from ticket to folio to statement
In the restaurant
The check is closed with a destination, not with a payment. The system has to know which stay it goes to, who authorized it and with what signature. What gets printed is proof of consumption, not a receipt for money. That nuance matters when the guest reviews it at check-out: they are looking at what they consumed, not at what they already paid.
In the folio
The charge reaches the guest folio as a line with date, outlet, description and amount. In a well-run hotel that line arrives immediately, not at the end of the shift when someone keys it in from a notebook. The difference is enormous when the guest decides to leave at six in the morning and last night’s dinner charge does not yet exist at the front desk.
At check-out
The front desk presents the statement, the guest reviews, pays or the corporate agreement absorbs it, and the folio closes. Only at that moment does the restaurant’s consumption become money for the hotel. Between dinner and check-out, hours or days can pass, and for all that time the charge lives as a receivable someone has to watch.
What the restaurant’s shift close sees
The close of an outlet has to reconcile what was sold against what is in the drawer and in the card slips. Room charge reconciles against nothing physical, and that is precisely the point: it reconciles against the folio. A proper close separates three columns: what came in as cash, what came in by card, and what went out to guest folios, each with its own list.
When room charge is treated as a payment method, the cashier ends up doing a trick: subtracting the charges from the total so the cash balances, or adding them to a line called “other”. Either way the list of folios is lost, and without that list nobody can reconcile the next day. The guide to the shift close by outlet (A guide to the shift close by revenue center in a hotel) shows how each column is built.
- Cash is counted and deposited, and any difference belongs to the shift.
- Card is reconciled against the bank terminal report.
- Room charge is reconciled against the front desk guest ledger, folio by folio.
- Comps and discounts are kept apart, because they are not payment either and they also need explaining.
- Tips are not sales and do not enter any revenue column.
What the controller sees in the report
Under the hospitality accounting standard, USALI, food and beverage revenue belongs to the food and beverage department no matter where the money comes in. A room charge collected at the front desk is not rooms revenue: it is restaurant revenue that the front desk collected on the restaurant’s behalf. If the system treats it as a payment method, it can easily land in the wrong line of the income statement or get counted twice.
The controller also has to reconcile two books that in many hotels live in different systems: the point of sale and the front desk system. Every restaurant charge must have a twin in a folio, with the same amount and the same date. The ones without a twin are lost consumption or duplicate charges, and both cost money. On the page for the controller (Controller) we describe what that reconciliation looks like when the two systems speak the same language.
There is a third effect almost nobody looks at: food and beverage revenue per occupied room. If the charge is not tied to a real folio, you do not know how much of your sales came from guests and how much from the street, and the number you present at the monthly meeting is an estimate dressed up as data.
An illustrative example with numbers
The figures below are made up to show the calculation. They are not data from any hotel or from the industry. Picture one night at your hotel’s restaurant with these sales:
| Item | Amount (illustrative example) |
|---|---|
| Net restaurant sales for the night | 24,000 |
| Collected in cash | 6,000 |
| Collected by card | 8,000 |
| Posted to rooms (14 folios) | 10,000 |
| Money that should be in the drawer and terminal | 6,000 + 8,000 = 14,000 |
| Receivable from guests | 10,000 |
The restaurant sold 24,000 and collected only 14,000. The other 10,000 exist as fourteen lines in fourteen folios, and will be collected at the front desk over the next few days as each guest checks out. If the close shows 24,000 “collected”, the manager believes there is 10,000 more than there is, and the controller finds out the day a folio closes without that line.
Now suppose two of those fourteen charges were keyed in with the wrong room number, and between them they add up to 1,400. They go to a folio that does not recognize them and are missing from another. The guest on the wrong folio disputes them at check-out, the front desk removes them to avoid an argument, and the consumption vanishes. The restaurant sold it, cooked it and will never collect it. Over three hundred restaurant nights a year, one such error per night is no longer a detail: it is 420,000 a year that left the kitchen and never reached the bank.
Where it breaks
- The server types the room number into a text field and the system accepts it without checking that there is an active stay.
- The guest left no guarantee, or the corporate agreement does not cover meals, and nobody knows until check-out.
- The folio is already closed because the guest left at noon and is consuming at the pool in the afternoon.
- The charge is written in a notebook and keyed in at the front desk hours later, or never.
- Two systems with two lists: the point of sale says one thing, the folio says another, and the difference is resolved by deleting.
Every one of these points is a consequence of the same cause: treating the charge as money already in the house instead of a promise that has to be verified and followed. In the article on why a text field is not enough (Room charge: why a text field is not enough) we develop the first item on the list, which is the most frequent one.
What changes when the system treats it as an accounting decision
First, the charge stops being a button and becomes a verification: before accepting, the system confirms that the room has an active stay, that the guest is who they say they are, and that they have credit to consume. Second, the charge is recorded with the folio as its destination, not with the room number as text, and it reaches the front desk immediately. Third, the close separates the charge from the collection and hands the controller the list of folios to reconcile without a spreadsheet.
The effect for the guest is invisible, and that is the goal: they say “to my room”, sign and go on with their evening. The effect for the hotel is that restaurant revenue, the receivable and the folio all say the same thing, and the morning report can be read without a footnote.
Room charge is not money that came in: it is a restaurant sale the hotel will collect later against a folio. Treat it as a verified receivable, not as a payment method, and the close, the folio and the report will stop contradicting each other.
What to do this week
- Take last night’s close and separate three columns by hand: cash, card and room charges. If the charges are added up as collections, you have already found the first problem.
- Ask the front desk for the list of restaurant charges that reached folios last night and compare it with the point of sale list. Count the ones without a twin.
- Look at how the server captures the destination of the charge. If it is a free text field, count how many charges last week carried the wrong room number.
- Ask the controller which line of the income statement a charge collected at the front desk ends up in. It should be food and beverage revenue.
- Write down with the front desk a rule for consumption after check-out: who authorizes it and what it is collected against.
Inn Restaurant was built so that this separation between sale and collection is the rule of the system and not a cashier’s trick: every charge is verified against the stay, travels to the folio with name and signature, and the close presents it as what it is. If you want to see a full night, from the table to the report, book a 15-minute demo (contact).
More articles
The guest who already checked out and keeps consuming: how the ghost charge is prevented
It is the most common case of lost consumption in a hotel restaurant: the guest closed the folio at noon and orders by the pool in the afternoon. Here is how it happens, where that consumption ends up, and the control that stops it before it reaches the front desk.
How food and beverage revenue per occupied room is calculated, and what a good number looks like
It is the metric everyone quotes in the hotel meeting and almost nobody explains well. Here is the definition, the formula, a worked example with numbers flagged as illustrative, and what you can do to move it.
The eight places where a hotel loses food and beverage revenue
Your hotel’s restaurant already sells well. The problem is that part of what it sells never reaches the drawer, the folio or the report. Here are the eight scenes where it happens, and what stops each one.
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.