Staff can combine separately opened checks only if the POS supports the merge for the checks’ current status. The buying question is whether the combined check keeps the item history and payment details your team needs—not just whether it shows one total.
Ask each vendor to demonstrate an unpaid merge, explain what happens when a payment is already attached, and show how staff recover from a mistake. Use the same sample checks for every demonstration and record both the result and any remaining questions.
Start with two checks for one party
Consider this hypothetical scenario: a party sits together, but two servers open separate checks as guests order. Before anyone pays, the host asks for one bill. The restaurant wants the combined check to preserve enough detail for staff to answer questions and close the sale correctly.
Check A belongs to Server A and contains two meals at $18 each and two drinks at $6 each, for a subtotal of $48. Check B belongs to Server B and contains two meals at $14 each and two drinks at $2 each, for a subtotal of $32. A $4 discount is applied to Check B before the merge.
Together, the checks contain eight items. Their combined subtotal is $80, the discount is $4, and the amount due before any applicable tax, tip, or payment is $76. These figures describe a hypothetical sale, not POS operating costs. They exclude fixed costs, variable costs such as processing fees, and exception costs such as staff time spent correcting an error.
The host cares about a clear bill. Both servers may need to see what they entered. A manager needs to know who owns the combined check and what happened to the discount. Whoever reconciles the shift needs a payment record that makes sense later. Those needs can differ even when the final amount is correct.
Keep this decision separate from splitting a bill or moving a party to another table. Those actions may be useful in service, but neither proves that two existing checks can be combined with their history intact.
Watch the unpaid merge from start to finish
Ask the vendor to enter the sample checks separately, with their different server assignments, and apply the discount to Check B. Before the merge, have the demonstrator show the item details, discount, ownership, and totals on each check. Then ask them to combine the checks without taking payment.
Compare the result against the expected eight items, $80 subtotal, $4 discount, and $76 amount due. A single $76 balance is necessary for this scenario, but it is not enough on its own. Open the combined check and ask:
- Can staff identify each item and the check it came from?
- Does the $4 discount remain visible, and is its scope clear?
- Which server is shown as the owner after the merge? Can staff see the original assignments?
- Can a manager find a record of the merge and the person who performed it?
- What do staff see if they try to merge the wrong checks?
Decide which details your restaurant actually needs. For example, if managers resolve item disputes by looking up the original server, the ability to find that assignment may matter more than which server owns the final check. If the original assignment disappears from the screen, ask whether it remains available elsewhere and who can access it.
Record what the vendor shows, not merely what someone says should happen. A screenshot of the combined check may establish the visible total, while a separate demonstration or written explanation may be needed for the history. Note any conditions, such as user permissions or setup choices. If an answer is verbal, ask for it in writing before making it a buying assumption.
Your broader restaurant management software requirements can provide context, but score this workflow on its own. A system that handles orders well still needs to handle your particular check-merging process.
Ask about payments and mistaken merges
Repeat the discussion with one change: suppose Check A already has a recorded $20 payment before the merge. The hypothetical sale is still $76 before tax and tip, so the remaining balance would be $56 if the system combines the checks and correctly carries that payment forward. The $20 is a payment against the sale; it is not a processing fee or an additional sale.
Do not assume the POS will permit this merge. Ask whether it blocks the action, carries the payment to the combined check, or requires a different process. Have the vendor show how the original payment and remaining balance would be presented, including how staff can avoid collecting that $20 again. If the action is blocked, ask for the exact staff steps and who has permission to carry them out.
Use a simulated payment record or vendor-provided demonstration data. A practice scenario must not create a real card charge, send a guest message, or dispatch a courier. If a realistic payment state cannot be demonstrated safely, get the workflow and its limits in writing rather than charging a card to find out.
Then consider a mistaken merge: a server combines Check A with a check belonging to another party. Ask whether an authorized person can undo the merge, what happens to item and discount history, and how the team should restore the correct bills if there is no undo. Also ask whether a manager must intervene.
This exception can change the buying decision. A restaurant that often opens multiple checks for large parties may decide that an unclear correction process is too disruptive, even if the unpaid merge looks simple. A restaurant with rare merges and a clear manager-led workaround may judge the same limitation acceptable. The choice follows from the frequency and consequences of the exception, not from a feature label alone.
Use an acceptance table to compare evidence
The table below turns the scenario into a decision record. The expected results are your requirements for the example, not claims about any vendor. Assign an escalation owner at your restaurant before the demonstrations; that person can resolve an open question or decide that a workaround is acceptable.
| Check | Expected result | Evidence to request | Escalation owner |
|---|---|---|---|
| Unpaid merge | Eight items; $80 subtotal, $4 discount, $76 due before tax and tip | Show both original checks and the combined check | Owner or purchasing lead |
| History and ownership | Original item and server details remain findable; final owner is clear | Show the relevant check details and merge record, or document the limit | Shift manager |
| Existing payment | If permitted, $20 remains recorded and $56 remains due before tax and tip; otherwise, staff receive a clear block and process | Show a simulated payment state or provide written steps | Manager responsible for reconciliation |
| Mistaken merge | Staff can identify the error and follow a defined correction process | Show undo or document the alternative and required permissions | Shift manager |
After each demonstration, mark a row as met only when the evidence answers the requirement under the conditions you expect to use. Record a partial result when the vendor shows a workable alternative that needs approval. Leave a question open when the response is only an assumption or the relevant screen was not shown.
Compare those records side by side. One vendor may preserve original server details on the check screen; another may make them available only in a manager view. Either could work, depending on who needs access during service. Ask about any extra setup, permissions, or charges associated with the demonstrated workflow in the written quote. Processing fees and other operating costs are separate from the sample check totals.
Choose a workflow your staff can use
Include the people who will use and oversee the process. A server can judge whether the steps are clear during a busy shift; a manager can judge whether the correction path and history are usable. The purchasing lead can compare unresolved questions against the restaurant’s willingness to accept a workaround.
For a fair comparison, give each vendor the same sample data and acceptance table. Ask Toast, Square, Fleksa, or any other candidate to demonstrate your requirements rather than relying on a generic feature list. If a vendor cannot show a condition, ask for a written answer that identifies the limitation and the staff process.
Separate a safe simulation from a live service pilot. In a simulation, use demonstration data and avoid real payments, guest messages, and courier dispatches. If you later run a live pilot, use the vendor’s agreed operational setup, train the staff involved, and have a manager available to handle actual service issues. A simulation result alone does not prove every live-service condition will behave the same way.
Before selecting a system, review the open rows and decide who will resolve each one. See Fleksa’s POS questions for broader purchasing context. Then request a demo of the restaurant POS system with the sample checks, and ask for the merge outcome and any limits to be documented.
Frequently asked questions
Does the right total prove a merge worked?
No. Check the items, discount, server ownership, and available history as well. A correct balance can still leave staff without details they need to answer a guest or reconcile a shift.
Can a check with a payment always be merged?
Do not assume it can. Ask whether the POS permits the action, how it records the payment and remaining balance, and what staff should do if the merge is blocked.
Who should handle a mistaken merge?
Assign an owner before service, usually a shift manager, and confirm the required permissions. The vendor should show an undo process or document an alternative for restoring accurate checks.
