A restaurant POS correction should leave a clear trail from the original order to the final amount. Before payment, that often means editing or voiding an item. After payment, it may mean a refund or another payment adjustment. The right action depends on whether the order was sent, whether the guest paid, and how the POS and payment processor handle the transaction.
Ask each vendor to demonstrate the full path, not just the correction button: the original item, the staff member who made the change, the reason, any approval, the guest receipt, and the reports a manager uses at close. The goal is to correct the guest's bill without making the original mistake disappear from the record.
Start with when the error was found
The same wrong entrée calls for different handling depending on where it is in service. Use this decision tree when you build your test cases:
- Not sent and not paid: Can the server edit or remove the item before sending the order? Ask whether the change appears in an order history and what permissions apply.
- Sent but not paid: Can the server void the item or change it on the check? Also ask how the kitchen or bar learns that the item is no longer needed. A check correction alone does not necessarily stop preparation.
- Paid: Ask whether the payment can still be voided or must be refunded, and whether the correction can cover one item rather than the whole payment. Payment status and processor rules may affect the options.
- Order and payment do not match: Pause before making another adjustment. Review the order history, payment status, and any prior correction so a second staff member does not return the same money twice.
For example, a server notices a duplicate drink before sending the ticket. Removing it may be straightforward. If the bartender has already received the ticket, the restaurant also needs a way to communicate the cancellation. If the guest has paid, the manager must consider the payment record as well as the check.
Include direct orders in your requirements if you accept them. Ask how staff can find and correct an order that originated outside the dining-room screen, and which record the manager should use when reconciling it. A restaurant POS demonstration should follow the order through the channels your team actually uses.
Compare a void with a refund
A void generally cancels an item, check, or payment at a particular stage. A refund generally returns money after a payment has been made. Those labels are useful starting points, but they do not tell you exactly what a given system changes. Ask the vendor to show the effect on both the order and the payment.
For an unpaid check, request a demonstration of an item void and a whole-check void. Does the original item remain visible? Is the check total recalculated? Can the manager see who made the change and why? If a ticket was already sent, ask what the kitchen display or printer shows and whether staff must communicate the cancellation separately.
For a paid check, ask the vendor to demonstrate both a full refund and a partial refund in a safe test environment. Find out whether the returned amount is linked to the original payment and whether the system records the affected item. Also ask what happens when the amount returned is different from the item price, such as when a manager agrees to a partial adjustment.
A payment void and an item void are not interchangeable. One may affect the payment transaction; the other may affect the check. Ask when a payment can be voided, when a refund is required, and how the guest can identify the result on a receipt. Do not assume a refund is immediately visible to the guest or that every payment method follows the same timing.
Ask how corrections appear in daily sales and payment reports, including whether a refund appears on the original sale date or the correction date. A manager needs to know which report answers which question: what was sold, what was returned, and what money is expected from the payment processor.
Set approval and reason requirements
Write down who may correct an order at each stage. A small restaurant might allow servers to remove an unsent item but require a manager to approve a sent-item void or a refund. Another operation may need a different arrangement for counter staff and shift leads. The important test is whether the POS can support the rules you choose without forcing everyone to share a manager login.
Ask to see separate staff accounts in the demonstration. Have the vendor show what happens when a staff member without approval attempts a correction, then what an authorized manager must do. Check whether the record identifies the person who requested the change as well as the person who approved it. If your policy requires both names, put that requirement in writing.
Reasons should be useful at closing time. “Wrong item entered,” “guest changed order,” and “item unavailable” tell a manager more than a generic “other.” Ask whether reasons can be required, whether your restaurant can choose them, and whether notes can be added without overwriting the original transaction.
Also ask what happens if a manager makes a mistake. Can an authorized person correct the correction while retaining both actions? Who can view or export the history? Does a report show the time and amount of each action? Look for a record that lets another manager reconstruct the sequence without relying on a verbal explanation.
Run the demonstration with the devices and workflow you expect to use. Your restaurant POS hardware choices matter if staff must move between a register, handheld device, printer, and kitchen display to complete or communicate a correction. Ask which devices and setup are supported in your quote.
Reconcile a correction before you close
A correction is not finished when the guest leaves. At close, compare the original check, the correction record, the receipt, and the payment report. Someone who was not involved in the transaction should be able to see why the final amount differs from the original amount.
The following is a hypothetical partial-refund example, not a claim about any particular POS. A guest paid $40 for a check. The manager approved a $12 refund for an incorrect item, leaving $28 after the return. The table separates the amounts and the records the manager should compare.
| Record | Amount | What to check |
|---|---|---|
| Original paid check | $40 | Original items and payment are identifiable. |
| Approved refund | $12 returned | Reason, staff member, approval, and original payment reference are recorded. |
| Amount after refund | $28 | $40 paid minus $12 returned; compare with the corrected check and payment records. |
| Receipt and reports | $12 refund shown | Receipt and relevant reports identify the correction; investigate any difference. |
The $28 is the amount remaining after the refund, not a processing payout or profit figure. This example includes the original payment and the return only. Fixed costs, variable costs such as processing fees, and exception costs such as any refund-related fee are excluded. Ask the processor how fees and refund timing appear on its records rather than treating a quoted processing fee as the restaurant's all-in operating cost.
If the POS report shows the $12 refund but the payment record does not, check its status and timing before recording a second refund. If the receipt has the right amount but the reason is missing, follow your internal exception procedure. Keep a note of the transaction reference and the person responsible for resolving the mismatch. Ask how corrections made after the original business day are linked back to the original check.
Reporting needs may extend beyond the register. Ask how the correction appears in exports or connected restaurant management software, and who can access the underlying detail. For contract or accounting treatment questions, consult a qualified adviser.
Bring realistic cases to the demo
Give each vendor the same short requirements sheet: an unsent duplicate, a sent item the guest no longer wants, a fully paid check needing a partial refund, and an attempted correction by a staff member without approval. Add your payment methods, order channels, and required reason codes. Compare the steps, records, and permissions against your own policy rather than assuming similarly named buttons work alike.
For practice, ask for a simulation or test environment that cannot create a real card payment, guest message, or courier dispatch. Review the simulated receipt and reports together. A live service pilot is different: plan it separately with the vendor, limit who can make changes, and set a procedure for reviewing actual transactions. Do not use a guest's card to run a practice scenario.
Request a Fleksa POS demo and bring your correction rules and test cases. Ask the team to show the complete record for each case, including any steps your staff would need to handle outside the POS.
Frequently asked questions
Is a void the same as a refund?
No. A void generally cancels an item, check, or payment at a particular stage; a refund generally returns money after payment. Ask the vendor exactly how each action changes the check, payment, and reports.
Can a restaurant refund just one item?
Ask the vendor to demonstrate a partial refund tied to the original payment and show how the affected item and amount appear on the receipt and reports. Payment method and transaction status may affect the available action.
What should a manager review after a correction?
Compare the original check, the correction amount and reason, staff and approval details, the guest receipt, and the payment and sales reports. Investigate differences before making another adjustment.
