The server collects at the table: what changes in control when the money never passes through a central cashier
When the hotel restaurant’s server collects with a terminal at the table and sends room charges from there, there is no longer one register: there is one per server. Here is the virtual drawer, the individual close and the reconciliation with the front desk, with a worked example.
The guest wants to pay and does not want to get up. The server pulls out the terminal, collects at the table, and the money never passed through anyone else. It is faster for the guest and easier on the dining room, but at that instant the hotel restaurant stopped having one central cashier and started having as many cashiers as servers. If control did not change at the same time, the night’s close will be a sum of pockets.
What changes when the money does not pass through a central cashier
With a central cashier the model is simple: one person holds the cash, one terminal records the cards and one screen sends charges to the room. Responsibility has one name and there is one close. When collection moves to the table, those three things are spread across five or six people who are also running between kitchen and dining room. None of that is bad, but it requires each server to have their own register, even if that register does not physically exist.
The deeper change is about responsibility. Before, if money was missing, it was missing from the register. Now, if it is missing, it is missing from the close of someone with a name. That is better, not worse: the shortage is located in minutes instead of being spread across everyone. But it only works if the system keeps the account per person from the first payment of the shift to the last.
The virtual drawer per server
The virtual drawer is each server’s individual ledger inside the system: everything they collected in cash, everything that went through their terminal and everything they sent to a guest’s folio, separated by payment method, from the moment they opened their session. There is no metal drawer per server; there is a record that says how much cash they must hand in at the end and how much must match their terminal’s batch.
What it records
- Cash payments, with the amount received, the change given and the net the server keeps until the close.
- Card payments, tied to the terminal that processed them and the transaction number, to cross-check against the batch.
- Room charges sent from the table, with room, verified folio and confirmation status.
- Tips by payment method, separated from sales from the very first moment.
- The discounts, voids and reprints that server requested, with their authorizer.
With that, each server’s close is a single question: does the cash you hand in match what your virtual drawer says you collected in cash? Everything else (card and room) is reconciled against systems that already keep their own record, not against anyone’s word.
The three payment methods at the table
In a hotel restaurant, collecting at the table has three paths and each one is controlled differently. The table summarizes who holds what, what it is reconciled against and where it usually fails.
| Payment method | Who holds it | Reconciled against | Typical risk |
|---|---|---|---|
| Cash | The server until their close | Cash handed in against the virtual drawer | Collecting without recording and keeping the whole sale |
| Card on terminal | The acquirer; the server only processes | The terminal batch against the system’s payments | Altered tip or terminal charge with no ticket in the system |
| Room charge | The front desk, on the guest folio | Charges sent against charges confirmed on the folio | Charge to the wrong room or voided after the signature |
The room charge row is what makes the hotel restaurant different. When the guest says “To my room, please.”, the server does not collect: they send. And what they send has to land on a verified folio, not on a typed number. That verification at the table, with the stay confirmed on the server’s screen, is what keeps the charge from ending up in room 214 instead of 241. How it works is on the room charge page (Room charge).
The individual close step by step
The close per server takes five minutes if the system did its job during the shift. It is done with the manager or the general cashier, in the same order every day, and ends with one signature per server. This is the order that avoids arguments.
- The server closes their sales session. From that moment they cannot collect anything else in that shift.
- They hand in the cash without seeing the expected number. The manager counts and writes it down.
- The system shows the expected cash from the virtual drawer. The difference is calculated and signed.
- The card total in the virtual drawer is compared with the transactions on the terminal assigned to that server. Any terminal transaction without a ticket in the system is investigated right then.
- The room charges sent by the server are listed with their status: confirmed or pending. Pending ones keep a name for the cross-check with the front desk.
- Card tips are paid out according to the hotel’s policy and the server signs the voucher. Their close is done.
An illustrative example: three servers, one shift
The figures below are invented to show what the close looks like when each server collects at the table. They are not data from any hotel. It is the dinner shift at a hotel restaurant with three servers on the floor.
| Server | Cash | Card on terminal | Room charge | Total sold |
|---|---|---|---|---|
| Server A | 4,200 | 6,800 | 3,000 | 14,000 |
| Server B | 2,900 | 5,100 | 4,500 | 12,500 |
| Server C | 3,600 | 4,400 | 1,500 | 9,500 |
| Shift total | 10,700 | 16,300 | 9,000 | 36,000 |
Read it by columns. Cash (10,700) is the only one counted physically, and it is counted three times: 4,200 handed in by A, 2,900 by B and 3,600 by C. If A hands in 4,100, the 100 shortage belongs to A, not to the shift. Card (16,300) is compared against the terminals’ batch close; if the batch says 16,450, there is 150 charged on a terminal with no ticket, and the question goes to whoever has the difference on their terminal. Room charge (9,000) is cross-checked that night against the folios: the front desk must show nine thousand in confirmed restaurant charges with that date.
And there is one more reading only a hotel restaurant can make: server B sent 4,500 to folios out of a total of 12,500, more than a third of their sales. Server A, 3,000 out of 14,000. If the hotel wants to raise what its guests spend, it already knows who offers room charge naturally and who still asks for a card out of habit. That is information for training, not for punishment.
The terminal and the batch
The most common mistake when moving to table-side payment is treating the terminal as if it were part of the restaurant system. It is not: the terminal records what the server keys into it, and the system records what the server enters on the ticket. If the two amounts are not linked, a server can charge 950 on the terminal against a 900 ticket and the difference becomes a tip the guest never gave. Or they can charge on the terminal a consumption they never recorded in the system.
The control is the daily cross-check: every transaction in the terminal batch must correspond to a system ticket with the same amount, and every ticket paid by card must have its transaction in the batch. When the terminal is integrated, the system does that cross-check on its own and the amount travels from the ticket to the terminal without anyone typing it. When it is not, the cross-check is done by hand and takes half an hour per terminal every night. It is worth doing either way; what is not worth it is skipping it.
The new risks and how they are closed
Collecting at the table does not create more risk than a central cashier; it creates different risks. Each one has a simple fix if the system keeps the virtual drawer and the manager runs the individual close every night.
- Collecting cash without recording the ticket. Closed by comparing tables served against the server’s tickets, and by having the kitchen print only what the system sends.
- Charging a higher amount on the terminal than the ticket. Closed with an integrated terminal or with the batch cross-checked against tickets, transaction by transaction.
- Sending the charge to the wrong room. Closed with the folio verified on the server’s screen before sending, with the guest’s name in view.
- Voiding a charge after the guest signed and collecting cash. Closed by requiring manager authorization to void charges and reflecting the void on the folio at the same time.
- Mixing the cash of two servers who help each other. Closed with the rule that every payment is recorded in the session of whoever receives the money, no exceptions.
- Losing the terminal or the payment phone. Closed with one session per device that the manager can close remotely and with cash handed in through partial drops once it passes a cap.
All of the above lands on the server and the shift manager. What each of them sees on their screen, and what they do not, is described on the page for servers (Server) and on the register page (Cash and shift close), which explains how the individual close feeds the revenue center’s close.
When the server collects at the table, every server is a register: a virtual drawer that separates cash, card and room charge, and an individual close signed every night. Cash is counted against the virtual drawer, card against the terminal batch and room charge against the guest folio.
What to do this week
- Turn on one session per server in the system and remove any shared floor login.
- Assign one terminal to each server per shift and note on the close which terminal each person used.
- Run the individual close every night for seven days, with the cash difference signed per server.
- Cross-check each terminal’s batch against the system’s card tickets, transaction by transaction, on at least three nights this week.
- Ask the front desk for the list of confirmed restaurant charges by date and compare it with the charges sent per server.
- Check who offers room charge and who does not, and train the ones who still ask for a card out of habit.
Inn Restaurant keeps a virtual drawer per server, closes the individual shift with cash, terminal and room charge kept apart, and sends every charge to the verified folio from the server’s screen. If you want to see how a shift with table-side payment is closed, the fifteen minute demo is booked on the contact page (contact).
More articles
The hotel food and beverage department accounts under the hospitality standard: what goes in each one
A hotel’s food and beverage department statement has four blocks: revenue, cost of sales, payroll and other expenses. Here is what goes in each line, what does not belong even if it looks like it should, a worked example, and what the restaurant’s point of sale must deliver so the controller builds it without guessing.
Discounts in the hotel restaurant: who can apply them and how they show up in the report
A discount with no reason, no cap and no name is hotel money that left without anyone deciding. Here is the matrix by position, the short list of reasons and the way the controller should read them every morning.
The register that “balances” because nobody checked it: how a manipulated shift close is detected
A shift close that balances to the cent does not prove the money is all there: it proves the cash matches what the system says was sold. If someone edited what the system says, the register balances and the hotel loses. These are the traces it leaves.
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.