When guests move tables, the POS should keep their existing order and payment history accurate and make the check easy for the right staff to find. The kitchen should not receive duplicate items, and the remaining balance should not change just because the table number changed. Before buying, ask the provider to show you how its system handles each of those points.
A table transfer is different from managing an open tab. Here, the question is how a seated party’s check, service ownership and history behave when the party changes location. Test the move from the floor view through final closure, not just by watching a table number change.
Map the moves your restaurant actually makes
Start with your floor plan and the situations staff face during service. A whole party might leave a noisy table for a quieter one. A server might move the party after drinks have been sent but before food is ordered. A large party might need to split between two physical tables.
Those are different operations. Moving an entire check is not necessarily the same as moving selected guests or items. Ask the provider whether the POS supports each move directly, requires a split first, or needs a manager to intervene.
Use the following hypothetical test setup. Table 4 seats four guests, and Table 9 is empty and also seats four. One party of three occupies Table 4. Their check has two drinks at $5 each and one meal at $14, for a $24 item subtotal. Both drinks have already been sent to the bar; the meal has been sent to the kitchen. No tax, tip or other charge is included in these figures.
Run these as simulations in a safe training or demonstration environment. Confirm with the provider that the setup cannot make a real payment, send a guest message or dispatch a courier. If kitchen or bar devices are connected, agree on a safe test method with the team so practice tickets cannot be mistaken for live orders.
| Scenario | Action | Acceptance check | Question if it fails |
|---|---|---|---|
| Whole-party move | Move all three guests and the $24 check from Table 4 to empty Table 9. | Table 9 shows the three items and $24 subtotal; Table 4 no longer looks occupied by this party. | Can staff find the original check without creating a new one? |
| Already-sent items | Move the same check after both drinks and the meal have been sent. | Sent status remains clear; the move does not create duplicate preparation tickets. | How are kitchen and bar staff told about the new location? |
| New server | Move the party to a table served by another employee. | The responsible server can find the full check; ownership is clear. | Does ownership change automatically, manually, or not at all? |
| Partial payment | Record a simulated $10 payment, then move the check. | The check shows $24 in items, $10 paid and $14 remaining. | Can staff see which items or guests the payment was assigned to? |
| Occupied destination | Try to move the party to a table already occupied by a different party. | The system prevents an unintended merge or makes the choice and its consequences clear. | Can separate parties remain separate at one physical table? |
The matrix gives you expected outcomes, not a promise that every POS handles moves the same way. Repeat the relevant cases on the devices your staff would use, and record what takes extra steps. The occupied-destination case is separate from the move to empty Table 9: check the destination’s physical seating capacity before attempting it. Two parties sharing a table are not automatically one party or one check.
Check ownership and order continuity
Have the provider show the starting check before the move. Note its table, server, items, quantities, modifiers and sent status. Then move the party and open the check from the new table. Each item should still be identifiable, including any instructions needed to prepare or serve it.
Ask two staff members to play the old and new servers. Can the original server still find the check? Can the new server open it and add an item? If a manager must approve the transfer, see what happens when approval is unavailable. A workable process needs a clear owner even when the POS does not change server assignments automatically.
Check the floor view as well as the check itself. After a whole-party move, staff should be able to tell that the old table is available for a new party, without losing the moved check. If the POS uses separate controls for table occupancy and check location, ask staff to practice both steps. An empty-looking table with an overlooked open check can create confusion later.
Sent items deserve special attention. The kitchen may have a ticket that names the original table. Ask whether the destination appears on a later ticket, screen update or other notice, and what the server must communicate in person. Do not assume that moving the check re-sends an order or updates every display. The useful result is a clear way to serve the existing items at the right location without preparing them twice.
Include a follow-up order in the simulation. Add one more $5 drink after the move. The hypothetical item subtotal is now $29: the original $24 plus $5. Confirm that the new item is associated with the moved check and that the earlier three items remain visible. If staff use more than one restaurant POS hardware device, check whether the same information is available where each role needs it.
Test partial payments and exceptions
Start this case again from the original $24 check, without the extra drink. Record a simulated $10 payment before moving the party. After the move, the item subtotal should still be $24, the recorded payment should be $10, and the unpaid balance should be $14. This is a check-balance example, not a processing-fee or operating-cost calculation; tax, tip and other charges are excluded.
Now ask what the $10 payment applies to. If it was assigned to a particular guest or item, can the new server see that assignment? If the system treats it as a payment against the whole check, can staff explain the remaining balance without assuming that a particular guest has paid? The distinction matters when a party plans to split the rest of the bill.
Try a second exception: one guest wants to move while the other two stay. Ask the provider to demonstrate the supported sequence for moving only that guest’s items, including any already-sent item and any assigned payment. If the system requires staff to split the check first, have them do that in the demonstration. Verify that the sum of the resulting item subtotals still equals the starting subtotal, and that a payment is not counted twice or lost from view.
Also ask what happens if the destination already has an open check. Can the operator keep two parties’ checks separate, and how is an intentional merge confirmed? Find out whether an accidental move can be reversed, who has permission to do it, and what record remains. A warning is useful only if its wording tells a busy server what will happen next.
For each exception, write down the staff action and the recovery path. If a feature needs a manager, a particular role permission or a manual note to the kitchen, include that in your operating plan. Compare the workflow in a restaurant POS with the way your floor actually runs, rather than judging it solely by the number of taps.
Verify records after the check closes
In the simulated whole-party move, close the check using the provider’s safe practice method. Review the record from both the original and destination table views, if those views are available. Look for the original items, any later additions, recorded payments, final balance and the location or history that helps a manager trace the move.
Then compare what each view shows. A table history does not need to duplicate every detail, but staff need a reliable route to the complete closed check. Ask whether the history identifies the move, the employee who performed it and any ownership change. If it does not, ask how a manager would investigate a guest’s question about where an item or payment went.
Flag discrepancies by consequence. A duplicate kitchen ticket risks extra preparation. A missing payment record can lead to an incorrect balance. A table that still appears occupied can disrupt seating. A missing audit detail may make a later correction harder. Have the provider demonstrate the fix and repeat the affected case rather than accepting an explanation alone.
Before a live service pilot, agree on who can perform transfers and who handles problems. A simulation checks the workflow without affecting guests or money; a live pilot is a separate, controlled period of actual service with real orders and payments. Brief the team on the approved process, identify a manager to resolve issues, and review transfer records afterward. Do not promise staff that every issue can be avoided.
For a buying decision, compare the full workflow and any quoted setup, hardware and processing terms—not just the transfer button. Ask what training is included and what happens if the required devices or permissions cost extra. A broader restaurant management software evaluation can include how the floor view fits with reservations, while this test stays focused on the check and its history.
Next step: Bring the matrix and your floor plan to a provider demonstration. Ask staff who will use the system to perform the moves, then discuss any gaps and recovery steps with the provider. Discuss your table-transfer requirements with Fleksa.
Frequently asked questions
Should moving a table resend food to the kitchen?
A move should not cause duplicate preparation. Ask how the POS preserves sent status and how kitchen staff learn the new location; the answer may involve a staff communication step.
Can a partially paid check be moved?
Ask the provider to demonstrate it. Check that the recorded payment remains visible, the remaining balance is correct and any guest or item assignment can still be understood.
Can two parties share one physical table without merging checks?
That depends on the POS workflow. Ask for a demonstration using two separate parties, and confirm the physical table has enough seats before considering the arrangement during service.
