One server can leave while another takes responsibility for open checks if the POS and your handover process support it. The important question is not just whether a check changes hands. You also need to know who can act on it afterward, how the sale and tip appear in reports, and what happens to anything left unresolved.
Do not assume that changing a check’s owner moves the table, changes historical sales credit, or settles a tip. Those can be separate actions. Before choosing a restaurant POS system, walk the vendor through your actual shift change and ask for the results in writing.
List open checks and owners before the shift ends
Start the handover while the outgoing server is still available. Pull the list of that server’s open checks and compare it with the dining room and any other orders they are handling. The manager and incoming server should be able to identify every check that still needs attention.
For each check, note its ID, current owner, incoming owner, status, and any exception. An exception is something the next server or manager must resolve: a split still being discussed, an unpaid balance, a tip awaiting adjustment, or a guest request that has not been entered. Record enough detail to act without putting sensitive payment information on the sheet.
Check IDs matter because a physical table and a check are not the same thing. One table can have several checks, and a check may cover only part of a party. If two parties share a table, or one party has split its bill, confirm ownership for each check rather than signing off on the table as a whole.
Agree on a cutover point. Before it, the outgoing server handles changes or tells the incoming server about them. After it, the incoming server is responsible for follow-up. The manager should know who has authority to reassign a check and what to do if a check cannot be transferred.
A practical end-of-shift check has three parts:
- Completeness: Compare the handover list with the POS open-check list. Investigate any missing or extra check.
- Acceptance: Have the incoming server confirm the assigned checks and their exceptions, not merely receive a verbal summary.
- Closure: Have the manager record unresolved items and confirm whether the outgoing server can be released.
This is a staff-ownership decision, not a table-move exercise. Ask the vendor to show what the incoming server can see and do after reassignment, including adding items, reviewing the balance, and completing the check if permitted by your staff roles.
Simulate the difficult cases before buying
Use a vendor demo or isolated training environment with fictional checks. Make sure the exercise cannot trigger a real card payment, guest message, or courier dispatch. Ask the vendor to show the screens and reports, then record what happened rather than relying on a general answer that the system “supports transfers.”
Unpaid check: Create a fictional check with a remaining balance. Reassign it from the outgoing server to the incoming server. Can the incoming server see the full balance and add another item? Who is shown as the owner before and after? Ask how the check would be closed in normal service, but do not run a real payment for practice.
Shared table: Create two fictional checks at one physical table, with different owners. Reassign only one. Does the other check keep its owner? Can both servers identify the right check without changing the table assignment? Also ask what happens if your staff split or combine checks after a handover.
Unadjusted tip: Use a fictional check with a recorded tip that still needs adjustment. Ask who can make the adjustment after ownership changes and where the original and adjusted amounts appear. Do not assume the check owner automatically receives the tip or that changing ownership changes past reporting.
For each case, record the initial state, action, final state, and report shown. Separate a demonstrated result from a promise to investigate. Ask for written documentation of any permission setting, configuration, or restriction that affects the outcome. If the answer depends on your setup, have the vendor identify the setting and who controls it.
After a successful simulation, a manager can plan a limited live-service pilot using the restaurant’s normal guest and payment procedures. That is different from a practice scenario: define who monitors the handover, how exceptions are escalated, and when the manager will stop the pilot and use the existing process. A simulation alone does not prove the workflow will fit a busy dining room.
Compare check ownership with sales and tip reports
Ownership tells staff who is responsible for the open check now. Sales attribution describes where the system reports the sale. Tip attribution describes where it reports the tip. These are different questions, and the answer to one does not establish the others.
Hypothetical example: Server Ana starts check 214 with $48 in food and drinks. Ben takes responsibility at shift change and adds $12. The final sale is $60. A $9 tip is recorded later and needs no further adjustment. These figures describe one check, not a processing-fee or operating-cost calculation.
Ask the vendor to show the sales report and tip report for both servers. One possible reporting result is $48 in sales attributed to Ana and $12 to Ben, with the $9 tip shown under one server or another. Another system or configuration might report the $60 differently. The point is to see the actual result and decide whether it fits your restaurant’s established handling of sales and tips.
Now change the scenario: the $9 tip is entered before reassignment but needs an adjustment afterward. Can an authorized person make that change, and does the report preserve a clear record of what happened? If the manager cannot identify or correct the item using the restaurant’s process, that exception may change the buying decision even if the open check itself transfers.
Compare the demo’s screen state with the relevant server, shift, and check reports. Ask whether reports reflect the time an item was entered, the current check owner, the person who closed the check, or another rule. Also ask whether a reassignment can be reversed and how that appears in the history.
Use your own policies when deciding who should receive credit or a tip. Have a qualified adviser address any legal or tax questions about those policies; a POS report is evidence of what the system recorded, not a substitute for that advice.
Use a sign-off sheet to make the decision
The following fictional sheet shows three checks at a shift change. It is a handover record, not proof that any particular POS handles these cases. The last column tells the incoming server and manager what remains to be verified or resolved.
| Check ID | Outgoing owner | Incoming owner | Exception and action |
|---|---|---|---|
| 214 | Ana | Ben | Unpaid balance; Ben confirms the balance and takes over follow-up. |
| 215 | Ana | Ben | Shares a physical table with check 216; confirm only 215 is reassigned. |
| 216 | Cara | Cara | No owner change; Cara confirms she retains responsibility. |
| 217 | Ana | Ben | Tip adjustment pending; manager confirms who may adjust it and reviews the report. |
Read the rows against the POS list, not against memory. Checks 215 and 216 illustrate why a shared table needs separate check-level decisions. Check 217 stays on the exception list until the authorized person resolves the tip issue and the manager can verify the result.
At the bottom of your working sheet, leave room for the shift date, cutover time, outgoing and incoming server acknowledgments, manager sign-off, and follow-up owner for each unresolved exception. If the POS cannot reassign a check, write down the agreed alternative and who remains responsible. Do not mark the handover complete simply because the outgoing server has left.
Before selecting a vendor, compare the same sheet with its demonstration and written answers. Can every open check be accounted for? Can the incoming server perform the necessary actions? Are sales and tips reported in a way your manager can reconcile? Are role permissions and exception handling clear? A product is a better fit only if the answers match the way your restaurant intends to operate.
Review the vendor’s POS questions and consider how the handover fits your wider restaurant management software workflow. Then request a Fleksa POS demo using the sample sheet, and ask the team to document the outcome of each case.
Frequently asked questions
Can a server leave before every check is paid?
Possibly. First account for each open check, confirm who accepts responsibility, and resolve or assign exceptions. Ask the POS vendor whether the required reassignment and staff permissions are supported in your setup.
Does transferring a check transfer its sales and tips?
Not necessarily. Check ownership, sales reporting, and tip reporting can follow different rules. Ask to see the relevant reports before and after a simulated reassignment.
What if a check cannot be reassigned?
Ask the vendor what alternative workflow is available and who remains responsible. Record the exception, the manager’s decision, and the person who will follow it through before releasing the outgoing server.
