Restaurant Table Transfers and Order Merging: Preserve Kitchen, Payments and History

Guests may change tables, two parties may join, or an order may need to move to another table. This must happen without losing items, resending food or creating billing errors.

Before moving or merging

Check the source and destination tables, open orders, preparation status, discounts and recorded payments.

Full table transfer

In a full transfer, the order and its guest relationship move to the destination table. The source table should only be released when no other order or payment remains open.

Partial transfer

When only selected guests or items move, quantities, notes, course and item ownership must remain correct. Items already sent to the kitchen must not be sent as new orders.

Merging two orders

Before merging, review discounts, configured tax, previous payments and ownership of items. The history of the original orders must remain traceable.

Kitchen status must remain unchanged

A table change is a front-of-house event and should not return prepared items to production. If the destination uses a different printer, station or course, any corrective message must be explicit and testable.

Previous payments, deposits and balance

Cash, card payments, deposits, credit and tips must remain linked to the original orders. The new total must show gross amount, recorded payments and actual outstanding balance. A payment must not be counted twice or disappear from history.

Discount and pricing rules

Two orders may have different discounts or prices. Determine whether a discount applies at item, order or customer level and whether combining it is permitted. Price changes after merging must record the reason and user.

Guest or seat-based ordering

Linking items to seats or guests makes partial transfers and bill splitting easier. Shared items still need a clear ownership and allocation rule.

Concurrent user control

Two users may open the same table during a busy service. Before finalising a move or merge, review the latest changes and prevent newer order data from being overwritten.

History and rollback

Record source table, destination table, original orders, moved items, user, time and reason. Correct mistakes using the history rather than creating a fresh order and deleting the earlier trail.

Access and approval

A simple transfer without payment may be available to floor staff. Merging an order with payments, important discounts or financial corrections should be restricted to authorised roles.

Practical scenario

Two guests move from table 12 to join table 14. Their items are selected by seat, preparation status remains unchanged and one guest's earlier payment stays with that part. After merging, items, payments and balance are checked and the transfer history is recorded.

Post-change checklist

• The source table has no unintended order or balance.
• The destination shows all intended guests and items.
• No item was resent to the kitchen.
• Discounts, configured tax, tips and payments are correct.
• The change history and user remain visible.

Conclusion

Moving a table is not a visual change only; it must preserve the relationship between guest, order, kitchen and payment.

Frequently asked questions

What is the difference between full and partial transfer?

A full transfer moves the whole order and guest; a partial transfer moves selected seats or items.

Should a table transfer resend food to the kitchen?

No. Existing preparation status should remain and only necessary correction messages should be sent.

What happens to previous payments after merging?

They stay linked to the original order and are counted once in the merged balance.

Which changes need manager access?

Merges involving payments, important discounts or financial corrections should be restricted.