Voids with a reason: the rule that separates an entry mistake from fraud

A server in your hotel’s restaurant enters two coffees on the wrong table, notices and voids them. Another server collects a 600 check in cash, voids it after the guest has left and keeps the bills. In the night report the two movements are the same line: “voided ticket”. The only way to tell them apart is to have required, before voiding, a reason and a permission.

What a void is and what it is not

The word “void” is used in the restaurant for very different things, and that mix is the first source of confusion. It helps to separate the cases, because each carries a different risk and therefore needs a different permission.

Only the first four rows are voids. Comps and transfers have their own movement and their own report. When a system puts everything under the same button, the manager loses the ability to read the report, because an authorized comp and a ticket erased after payment add up in the same column.

Why the mistake and the fraud look the same

Without a mandatory reason and a permission, a void leaves only two pieces of data: the time and the amount. With that you cannot tell whether the item was prepared, whether the table consumed, whether money changed hands or who decided to erase it. The entry mistake and the fraud produce exactly the same line in the report.

The classic fraud is short: the check is collected in cash, the customer leaves, the ticket is voided and the drawer’s expected cash drops by the same amount. The cash close balances perfectly, because the system no longer expects that money. The only footprint is the void, and if the void has no reason and no signature, the footprint says nothing.

In a hotel restaurant there is a variant of its own: the consumption is posted to the room, the guest signs, and later someone voids the charge in the restaurant and collects in cash “so as not to bother the front desk”. The guest’s folio comes out clean, the cash never reaches the drawer and the report shows one more void. That is why the room charge has to be a movement tied to the folio that cannot be erased from the restaurant without leaving a trace at the front desk.

The rule: closed reason and permission by level

The rule has two halves and does not work with only one. The first half is the reason: every void requires choosing one from a closed list, not typing free text. The second is the permission: each case in the table above is authorized by a different level with its own PIN, and that PIN is recorded together with the void.

The reasons that actually work

• Entry mistake: the item should never have been on the check.
• The guest changed their mind before the kitchen prepared it.
• Dish returned: it was prepared, served and not accepted.
• Duplicate: the same item was entered twice.
• Wrong room charge: corrected by folio transfer, not by void, and the system should force that.
• Authorized comp: leaves the void flow and enters the discount flow with its own report.

The list is short on purpose. With free text, the most common reason in any restaurant is “error” and the second is a single period. With a closed list, the server has to decide, and that decision can be counted, compared and questioned.

The permissions that actually work

The server can remove an item that has not yet gone to the kitchen, because there is no cost and no risk. Everything else requires someone else’s PIN: the captain or the manager for items already prepared and for unpaid tickets, and the manager with notice to the controller for any void after payment. Nobody authorizes themselves, not even the manager: their post-payment void appears in the controller’s report the next day.

The void report by server

The reason and the permission only help if somebody reads the result. The report to read every week is the void report by server, and it has few columns: server, number of voids, amount voided, amount voided as a percentage of their sales, most frequent reasons, voids after payment and who authorized each one.

What gets compared is not the absolute number but the percentage of sales and the share of voids after payment. A server who sells a lot voids more in number; that is normal. A server whose percentage doubles everyone else’s, or whose voids are almost all after collecting in cash, is the one to review first. How that report is built alongside the rest of the operating reports is on the reports page (Reports).

An illustrative example with numbers

The figures below are made up to show the calculation. They are not from any hotel. Imagine three servers in a hotel restaurant in the same month, with their sales and their voids.

Server C voids more often than A, but for small amounts and almost all are duplicates before payment: a server who enters fast and corrects. Server B is something else: voids 6 % of sales against 1.5 % for A with the same sales, ten of the eighteen voids are after payment, and those ten add up to 3,000, that is, 300 on average each. With the reason “dish returned” on checks that had already been paid.

None of this proves fraud. It proves that server B’s ten checks need to be reviewed, the kitchen needs to be asked whether those dishes came back, the payment method needs to be checked and so does who entered the PIN to authorize. Without a reason and a permission, the report would only say “18 voids, 3,600” and there would be nowhere to start.

Voiding a room charge

In a hotel restaurant, the most delicate void is the one for a consumption that has already traveled to the guest’s folio. The front desk sees that charge, the guest sees it on their statement and the hotel collects it at check-out. Voiding it from the restaurant without the front desk knowing leaves the folio and the restaurant report telling different stories.

The rule that works is simple: a charge already sent to the folio is not voided, it is reversed, and the reversal stays on the folio with the same detail as the original charge. If the charge went to the wrong room, it is transferred to the correct folio. If the guest has already checked out, the reversal requires the controller, because money has already been collected. What that flow looks like from the manager’s side is on the manager page (General manager).

What the system has to do

All of the above is paper if the point of sale in your hotel’s restaurant does not enforce it. This is the minimum list it has to meet.

• Closed, mandatory reasons for every void, with no free-text field as the only option.
• Permissions by role with a personal PIN, so the server cannot void what already went to the kitchen or what has already been paid.
• The void does not erase the ticket: it marks it as voided and keeps items, time, server, reason and who authorized it.
• An automatic notice to the controller for every void after payment, with the payment method of the original ticket.
• Reversal of the room charge tied to the folio, visible at the front desk, instead of a local void in the restaurant.
• A weekly void report by server with percentage of sales and a split between voids before and after payment.

How these rules connect with each cashier’s close is on the cash page (Cash and shift close).

What to do this week

1. Pull the void report for the last month and separate by hand how many were before sending to the kitchen, how many after preparing and how many after payment.
2. Define the closed list of reasons with your manager and remove the free-text field, or make it optional after choosing a reason.
3. Assign a personal PIN to captains and managers and remove the server’s permission to void items already sent.
4. Calculate per server the percentage of voided amount over their sales and sort them. Review the one at the top first, starting with their voids after payment.
5. Agree with the front desk that no room charge gets voided from the restaurant: it is reversed on the folio or transferred.

Inn Restaurant requires a closed reason and an authorization PIN on every void, reverses the room charge on the guest’s folio instead of erasing it, and delivers the void report by server with the split between before and after payment. If you want to see what that report looks like with a month of your restaurant, book a fifteen-minute demo (contact).