The first shift close on the new system: what to check that night and what to expect in the first week

It is the first night on the new system in your hotel’s restaurant. The last guest went up to their room, the server prints the shift close and the number matches neither what is in the drawer nor what the front desk says it received in room charges. Before anyone says “the system is wrong”, it helps to know which differences are normal on a first close, which ones point to an entry error and which ones signal a permission that was configured badly.

Why the first shift close never balances on the first try

The shift close is where three things meet that until yesterday lived in different places: what the server entered, what the cashier collected and what the front desk received as room charges. On the old system, those three things had spent months adjusting to each other by habit: the cashier knew the bar closed in cash without a ticket, the front desk knew charges arrived on paper the next day and the controller had a “differences” line that nobody questioned.

The new system breaks those habits on the first night. There is no more bar ticket closed by hand, no more charge on paper, no more comfortable differences line. Everything that used to be smoothed over by hand now shows up as a visible discrepancy. That is why the first close looks worse than the previous ones even though the system is doing its job better: it is showing what used to be hidden.

You need to walk into that night with that idea clear. A close that does not balance is not a broken system; it is a list of things to check in order. And the order matters, because half of the first day’s differences are explained by the first check and disappear without touching anything else.

What to check that same night, in order

Do not review the close alone. On that first night the implementation lead, the shift cashier and someone from the front desk who can see the room folios should all be there. The controller can join the next day with the report, but the questions below are best answered with the people who were in service.

1. Count the cash in the drawer and compare it against the cash total on the close. If the difference is exactly the opening float, someone did not record it when opening the shift; it is the most common first-day error and has nothing to do with sales.
2. Open the list of open tickets. Every ticket left unclosed is a sale the close cannot see. Check one by one whether it was paid and not closed, whether it is a table that left without paying or whether it is a test ticket someone forgot to void.
3. Cross the room charges against the front desk. Ask the receptionist to open every folio with a restaurant charge and confirm that the amount and the room match. A charge the restaurant sees and the front desk does not, or the other way around, is the difference that most needs chasing.
4. Review the day’s voids and comps with the name of whoever authorized them. On the first day there are usually more than normal because of duplicate tickets from learning; what matters is that all of them have an authorization and a reason.
5. Compare sales by outlet against a similar day on the old system. Not so that they match, but to spot an outlet that shows zero or half of what was expected: that is usually a server who kept entering orders in the previous system.
6. Write down every difference with its explanation in a three-column list: amount, probable cause and who will confirm it tomorrow. That list is the most useful document of the entire first week.

If a difference is left without explanation when you finish the list, do not force it that night. Record it as pending with the exact amount and leave it for the next day’s review with the controller. What you should not do is adjust the close by hand to make it balance, because at that moment you lose the only clue you had. The guide to the shift close by outlet (A guide to the shift close by revenue center in a hotel) explains how the close reads once it is stable.

Normal differences and the ones that are not

Not every difference on the first close weighs the same. Some are the inevitable result of learning a new flow and disappear on their own in two or three days. Others signal a configuration error that will repeat every night until someone fixes it. The table below helps tell them apart.

The practical rule is this: a difference explained by one person and one specific ticket is a learning difference. A difference explained by a rule, such as “everyone can comp” or “nobody confirmed the stay before charging”, is a configuration difference and must be fixed before the next service, not at the end of the week.

The most frequent entry errors of the first week

Entry errors do not come from careless people. They come from people who have been running one flow for years and who, in the first week, repeat the old flow by reflex. It helps to know them in advance so the lead looks for them instead of waiting for them to show up as differences.

• Closing the ticket to cash when the guest said “to my room, please”, because the cash button was where the room charge button used to be.
• Posting to the room without verifying the stay on screen, using the number the guest said from memory, which turned out to be the room from their previous stay.
• Entering the tip as one more item on the check, so restaurant sales go up and the server’s tip disappears from the report.
• Opening a new ticket for every round at the bar instead of adding to the open tab, so the same table shows up three times.
• Applying an agreement discount to a guest who was not there under an agreement, because the discount was visible to every profile.
• Leaving the morning test ticket unvoided, so the day’s sales start with a check nobody consumed.

Each of those errors leaves a trace on the close and all of them are corrected the same way: with the server’s name, the ticket and a short conversation the next day, before the shift. What does not work is a general announcement at the meeting to “be more careful”. Entry errors are corrected one by one, with the person who made them and in front of the screen.

Adjusting permissions: what goes wrong on day one

Permissions are configured before go-live with the best of intentions and almost always end up wrong in one of two directions. Either they were too open, and the first close shows comps, discounts and voids authorized by people who should not have; or they were too closed, and service stopped three times because the server could not split a check without calling the manager.

Neither of those is a failure. It is the reason the first week exists. What helps is being clear from the first night which actions must ask for a supervisor’s authorization and which any server can do, and adjusting the system to that list instead of adjusting the list to whatever the system came with by default.

What should almost always require authorization

Voiding a ticket with items already sent to the kitchen, applying a comp, applying a discount outside an agreement, reopening a closed ticket and changing the payment method on a ticket already paid. Those five actions are where consumption leaks when permissions are left open, and the controller’s report should show who authorized each one. The page for the controller (Controller) explains how that log is read.

What the server should almost always be able to do alone

Open and close tickets, split a check by diner, move a table, add an item to an open ticket, post to the room with the stay verified and enter their own tip. If any of these actions asks for authorization, service slows down and the server finds a way around it, which is almost always worse than the permission itself.

An illustrative example with numbers

The figures below are invented to show how a close that does not balance gets broken down. They are not from any hotel. Suppose the restaurant close shows total sales of 18,500, with 6,000 in cash, 8,000 in cards and 4,500 in room charges. The drawer holds 5,500 in cash. The front desk reports 3,900 in restaurant charges.

First check: the float was 500 and was not recorded at opening. Real cash for the shift: 5,500 minus 500 equals 5,000. The difference against the 6,000 on the close is 1,000. Second check: there is an open ticket of 1,000 from a table that paid by card and nobody closed. Once closed, cards rise to 9,000 and expected cash drops to 5,000. Cash balances.

Third check: the restaurant has 4,500 in room charges and the front desk has 3,900. A difference of 600. The front desk opens folios and finds that a 600 charge was posted to room 214, which was empty; the guest who consumed was in 241. The folio is corrected that night. At the end, the close reads 5,000 cash, 9,000 cards, 4,500 room charges, total 18,500, and the three sources match. None of the differences came from the system: one was the float, one an unclosed ticket and one a charge posted without verifying the stay.

What to expect in the first week

The first week has a fairly predictable shape. On the first night everything is reviewed and almost everything is explained. On the second night, the float and open-ticket differences no longer appear because the cashier learned. The third and fourth nights are about permissions: by then it is clear what was left too open and what too closed, and it gets adjusted. From the fifth day on, the close should balance on the first try at least in the lower-volume outlets.

What should not happen is the same difference appearing five nights in a row. If on day five there are still charges the front desk cannot see, or comps without authorization, the problem is no longer learning and it is time to sit down with whoever configured the system. The cash page (Cash and shift close) describes what a close by outlet should show when it is configured properly, and serves as a reference for where yours needs to be by the end of the week.

It also helps to set an expectation with the owner: the first week is not for looking at pretty reports, it is for getting the close to balance. Reports on revenue per occupied room, mix by outlet and agreements come later, once the underlying data is reliable. Promising reports in the first week is promising reports built on data with entry errors.

What to do this week

1. Decide who will be present at the first close: the implementation lead, the shift cashier and one person from the front desk with access to the folios.
2. Write the list of actions that require authorization and the list of actions the server does alone, and compare it with the permissions configured before go-live.
3. Prepare the three-column sheet for differences: amount, probable cause, who confirms tomorrow.
4. Turn off access to the previous system in the outlets that already switched, so no sale gets entered there out of habit.
5. Agree with the front desk how room charges will be crossed every night of the first week, even if it takes fifteen minutes.
6. Schedule a review with the controller on day five to decide which differences are now configuration and not learning.

Inn Restaurant separates on the close what the server entered, what the register collected and what reached each guest’s folio, with the name of whoever authorized every comp and void, so the first night is reviewed in minutes rather than hours. If you want to see what a first close looks like on the system, the fifteen-minute demo is scheduled on the contact page (contact).