Before choosing a POS, ask the vendor to print an unpaid guest check for your actual table-service setup. The check should identify the right table, show the current items and amount due, and avoid suggesting that payment has already been made. Then change an item and print it again. If staff cannot confidently tell which version is current, the workflow needs more work.
This is different from checking a receipt after payment. A guest check tells the table what it owes; a payment receipt records a completed payment. Your evaluation should keep those two documents and their status labels separate.
Set requirements around your service flow
Start with the moment a guest asks for the check. Does the server print it at a service station, at the counter, or from a handheld device? Does another employee run it to the table? If more than one person handles the check, the table identifier has to make sense to both.
Write down the exact device, printer and order source you want to evaluate. A result from one terminal and printer does not establish what will happen on another setup. If your restaurant uses a handheld and a fixed terminal, ask to see each workflow you expect staff to use.
Give the decision to someone who understands both the floor and the POS setup. An owner or general manager might approve the purchase, while a lead server checks whether the printed result is usable during service. Assign one person to record the outcome and another to follow up with the vendor.
Set a simple acceptance standard before the demonstration:
- The check identifies the correct physical table using a label staff recognize.
- Items, quantities, changes, charges and the amount due are legible and understandable.
- The document does not say paid or present payment details that suggest a transaction occurred.
- Staff can identify the current check after an order changes.
- The process works on the devices and printer intended for that service area.
Also decide how you want staff to handle an old paper copy. Printing an updated check does not remove the earlier one from a guest's table. A practical procedure might have the server retrieve the old copy and explain that the new one replaces it.
Compare table details, amounts and devices
Bring a short requirements sheet to each vendor conversation. Toast lists restaurant POS and hardware among its offerings; Square offers restaurant point of sale and related payment and order tools; Fleksa offers a restaurant POS alongside direct ordering, reservations and related tools. Those descriptions alone do not establish how an unpaid check prints in your setup. Ask each vendor to demonstrate the same scenario rather than marking a feature as available from a product description.
For table identification, use your own labels. If your floor has a patio table and a dining-room table with similar names, test a label that staff could plausibly confuse. Ask whether the printed identifier matches the one used to select the table on screen and whether a long label remains readable on the paper.
Next, inspect the money fields. Can a guest follow the item amounts, subtotal, applicable taxes and other charges through to the total due? If your restaurant adds a service charge or permits an adjustment, ask how it appears and whether the printed description is understandable. Confirm the setup with your qualified adviser where contract, legal or tax treatment needs review.
Check the physical output too. On the proposed restaurant hardware, is the text large enough to read? Are totals cut off or faded? Ask what happens if the printer is unavailable: can staff redirect the job, and how do they know whether a copy actually printed? Record the answer for the specific configuration rather than assuming every printer behaves alike.
If orders reach the POS from more than one channel, ask which ones can be associated with a table and printed as an unpaid guest check. Do not treat a successful table-service example as proof for every order source.
Run an original-and-amended check test
Use a simulation with sample items and a test table, not a live guest order. The following figures are hypothetical and describe the check only; they are not Fleksa prices or a statement about how any product calculates charges.
Create a test order for physical table Patio 4: one sample entrée at $24 and one sample drink at $8. The item subtotal is $32. Add a hypothetical fixed $3 charge, making the amount due $35. For this exercise, no tax is included. The check total includes the two items and the fixed charge; it excludes payment processing fees and any other variable or exception costs. Those excluded costs are not guest-check line items in this example.
Before printing, agree that the expected first copy identifies Patio 4, lists the two items and the $3 charge, totals $35 and clearly leaves the amount unpaid. Print it through the intended device and printer. Keep the copy and note what actually appears, including any payment-status wording.
Now amend the test order: replace the $8 drink with a $10 sample drink. The new item subtotal is $34. With the same $3 charge, the revised amount due is $37. Print again without taking payment. The expected second copy should reflect the replacement and the $37 due, not present the $35 version as the current bill.
Place the copies side by side. Look for a useful revision marker or other clear way for staff to distinguish them. If neither copy identifies its version, ask how the team should know which is current. A manual procedure may work, but it adds a step: the server must retrieve the first copy and deliver the replacement. Decide whether that is acceptable during a busy shift.
Also look at payment status on both copies. Does either one say paid, show a tender or otherwise read like proof of payment? If the document has no explicit unpaid label, ask staff whether the wording and layout still make the amount due clear. Record the observation rather than assuming a blank status field is adequate.
Keep this as a simulated check. Do not run a real card payment, send a guest message or dispatch a courier. Separately, if you choose to run a live service pilot, establish staff responsibilities and guest-facing procedures first; a simulation alone does not show how the process holds up during service.
Record the decision and exceptions
Use pass, fail and unknown against your agreed requirements. The example below shows how a team might record a demonstration; it is not a claim about a particular vendor. A pass means the requirement was observed on the specified setup. A fail means the observed result missed it. Unknown means the team still needs an answer or demonstration.
| Requirement | Illustrative result | Next action |
|---|---|---|
| Correct table and $35 original total | Pass: both are clear on the first copy | Keep the sample and record the device and printer |
| Revised $37 total and current version | Fail: revised total is correct, but copies are not distinguishable | Lead server evaluates whether retrieving the old copy is workable |
| Unpaid status | Pass: neither copy implies payment | Retain both copies with the test record |
| Second service-station printer | Unknown: not demonstrated | Vendor demonstrates that configuration before approval |
The distinction matters: a correct total does not automatically make a revision workflow safe, and an untested printer is not a pass. For each failed or unknown item, record the owner, the proposed workaround and a date or milestone for retesting. Attach the two printouts or clear copies so the decision is based on what staff will actually read.
If you accept an exception, name the person who can approve it and the conditions. For example, a manager might permit the old-copy retrieval procedure for a limited pilot, provided servers are trained and the team reviews any confusion before wider rollout. If the procedure depends on a device or printer you have not seen, keep that requirement open until it is demonstrated.
Discuss setup and staff responsibilities alongside the broader restaurant management software workflow. A written quote should identify the equipment and services included; ask separately about processing fees and any other operating costs. A low equipment quote does not establish the full cost of running the system.
For your next step, request a Fleksa POS demo and bring your own table labels, sample order and amendment. Ask the vendor to print both unpaid versions on the proposed setup, then review the copies with the staff who would use them.
Frequently asked questions
Is an unpaid guest check the same as a receipt?
No. A guest check presents the amount due before payment. A receipt records a payment after it occurs. Check the wording and layout so guests and staff can tell the difference.
What if the updated check has no version number?
Ask how staff can identify the current copy. If the answer is a manual procedure, such as collecting and replacing the old check, decide who owns that step and test whether it works for your service flow.
Should every printer be tested?
Test each device and printer configuration you intend to rely on, especially where different service areas use different equipment. Record any configuration not demonstrated as unknown until it is checked.
