A guide to verifying the stay before posting a charge to the folio

In a hotel restaurant, most room charges are accepted on the strength of one piece of data: the number the guest says. The server writes it down, the system stores it and everyone trusts the front desk to sort it out. When the folio does not exist, the guest has already checked out or the number belonged to the room next door, the consumption is lost. This guide describes what has to be checked before accepting, in the order it has to be checked.

Why a room number is not a verification

A room number identifies a physical space, not a person and not an account. Room 214 can be empty, occupied by someone who arrived today, occupied by someone leaving in two hours, or shared by two colleagues with separate folios. None of those situations can be told apart by the number. What you need to identify is the stay: the relationship between a guest, a room and a date range, backed by an open folio.

When the restaurant system only stores the number, it is delegating the verification to the front desk, which will do it hours later with the guest long gone from the table. The front desk cannot ask who signed or confirm the consumption belonged to that person. It can only accept the charge, reject it, or post it to whoever is in the room at that moment, which is not always the person who had dinner.

The verification has to happen at the table, with the guest in front of the server and in seconds. If it takes longer, the server stops doing it. If it does not exist, the hotel pays for the dinner of someone who should have paid. The five questions that follow are the complete verification; a system that answers all five turns the room charge into something as safe as a card.

The five questions

First: is there an active stay in that room right now?

Active means the guest has already checked in and has not yet checked out. A confirmed reservation for tonight is not an active stay if the guest has not arrived. A stay with check-out recorded at noon is not active at four in the afternoon, even if the guest is still by the pool. This is the question that stops most ghost charges.

Second: who is the guest, and does it match the person signing?

The system should show the name or names registered on the stay, and the server should be able to confirm with a natural question: “Whose name is the room under?”. If the answer does not match, it is not necessarily fraud; it may be a companion who was never registered. But the charge cannot go to a folio whose holder does not know the consumption exists.

Third: is there authorized credit for consumption?

A guest who prepaid the room and left no guarantee has nothing to back a dinner with. A guest on a corporate agreement may have lodging covered and meals excluded. The front desk records that condition at check-in, and the restaurant has to see it before accepting, not after. If credit is zero, the right answer is to ask for another payment method with a smile, not to discover it at check-out.

Fourth: which folio does it go to?

A room can have a main folio and individual folios; a group can have a master folio that absorbs certain consumption and leaves the rest to the guest; a company can have an account that covers breakfast and dinner up to a cap. The system has to show the options that apply to that stay and let the server choose together with the guest. On the company accounts page (Master accounts and agreements) we explain how that split is defined before the guest arrives.

Fifth: is there room under the limit, or any restriction?

Many hotels set a charge limit per stay, tied to the guarantee the guest left. Others block alcoholic beverages for certain agreements, or room service for agency rates. The system has to know those rules and apply them on the spot. A charge that exceeds the limit is not rejected in silence: it raises a flag, and someone with authority decides.

What to do when one fails

A failed question does not mean the guest cannot consume. It means room charge is not the right route for that consumption at that moment. The table sums up what the server does and who decides in each case. What matters is that the decision is written down beforehand, so the server never has to improvise in front of the guest.

Look at the column of who decides. None of the five depends on the server calling the front desk and waiting on the line while the table watches. Most are resolved on the tablet itself; the last one needs an authorization that can also be given from the manager’s screen without walking to the lobby.

An illustrative example: a bar night with twenty charges

The figures below are invented to illustrate the mechanics; they are not real data from any hotel. Imagine the hotel bar receives twenty room charge requests in one night, with an average check of 350 each, that is, 7,000 in total.

• Seventeen pass all five questions and go to the right folio on the spot: 17 × 350 = 5,950 secured.
• One fails the first question: the guest checked out at noon and came back for a drink. The server collects by card: 350 collected another way.
• One fails the third: a corporate agreement with no food or beverage. The guest pays cash: 350 collected another way.
• One exceeds the stay limit. The manager authorizes from her screen because she knows the guest: 350 to the folio with the authorization recorded.

Result: all 7,000 are collected, though not all through the same route. Without verification, the three charges that failed would have reached the front desk as lines with no backing: the first against a closed folio, the second against an agreement that rejects it, the third against a limit nobody authorized. With luck the front desk recovers one; the usual outcome is that all three are voided, and that is 1,050 lost in a single night for not having asked at the table. Over thirty nights, 31,500. Among the eight places where consumption leaks in a hotel (The eight places where a hotel loses food and beverage revenue), this is the second most frequent.

What must be recorded on every charge

Verifying is useless if no trace remains. When the guest reviews the statement at check-out, or when the controller reconciles at month end, every charge has to be able to defend itself. These are the minimum data points:

• Exact date and time of the charge, not of the shift close.
• Outlet and table or location where it was generated.
• Destination folio and the name of the guest who authorized it.
• Guest signature, on paper or on screen, tied to the charge.
• Who captured it and, if there was a special authorization, who gave it.
• Item detail, not just the total, so the guest recognizes what they consumed.

With those data points, a dispute at check-out is settled by showing the detail and the signature. Without them, it is settled by deleting the charge, which is how almost all of them are settled today.

What the guest sees

Everything above happens in seconds and the guest sees no questions at all. They see the server bring the tablet, see their name on the screen, sign with a finger and get a receipt if they want one. If something fails, the server does not explain the folio or the agreement: they offer card or cash as something perfectly normal. Verification done well is faster than writing the number in a notebook, and it gives the guest the feeling that the hotel knows who they are.

That matters for a reason beyond control: a charge that feels safe and fast gets used more. When guests trust that their consumption will show up correctly on the statement, they consume in the hotel instead of going out. The room charge page (Room charge) shows the full flow from the table.

What happens for the front desk and the controller

The front desk stops receiving unbacked charges and stops being the place where errors are discovered. Every line that reaches the folio arrives verified, with name and signature, and the guest’s check-out becomes a review rather than a negotiation. The controller receives a list of charges where each one has a twin in a folio, and the reconciliation between restaurant and front desk shrinks to confirming that both lists match.

What does not change is the responsibility: the front desk still defines credit rules and agreements, and the restaurant is still responsible for its sale. What changes is that the rules are applied at the moment and in the place where the consumption happens.

What to do this week

1. Take ten room charges from last week and check which of the five questions could be answered with what was recorded. Count the ones that could not.
2. Ask the front desk for the list of restaurant charges voided at check-out over the last two weeks and classify them by the question that would have failed.
3. Write on one sheet the answer to each of the five failures: what the server does and who decides. Post it next to the restaurant register.
4. Agree with the front desk how authorized late check-outs are flagged, so the restaurant recognizes them as an active stay.
5. Define the minimum data every charge must carry and check whether your current system captures it; if not, start with the signature and the name.

Inn Restaurant answers the five questions on the server’s tablet before accepting the charge, with the stay read from the front desk system and the signature tied to the folio. If you want to see it with a test room and a guest who has already checked out, book a 15-minute demo (contact).