A manager may need to correct an exceptional price without losing the original amount or the reason for the change. A restaurant POS can meet that need only if the right person can make the correction and the record keeps enough detail to explain it later. Ask for a demonstration of both the approval and the resulting audit record before you commit to a system or change your setup.
Start with four checks: an open-price item, an approved override of a listed price, an unauthorized attempt and the record available for review. Treat an open-price entry separately: if no menu price existed before the sale, there may be no original price to preserve. Your operating rule should say what staff must enter instead.
Set the rule before testing the screen
A price override changes the amount charged for an item. It is different from applying a discount to a listed price, and different from selecting a menu modifier with its own price. A system may show these actions in different places or report them differently. Use the action your staff would actually take when correcting an exceptional price.
First, decide which situations justify a change. For example, a manager might correct a price entered incorrectly for a special. That does not automatically mean every server should be able to change any item price. Decide who may request a change, who may approve it and whether the approving manager must enter a reason.
Next, define what the record must contain. A useful minimum for a listed-price correction is the item, original amount, new amount, reason, date and time, and the identities of the person making the change and the approver. Ask whether those identities are separate when one person requests a change and another authorizes it.
For an open-price item, decide whether the record should identify the person who entered the amount and the reason or reference for it. There is a meaningful difference between an item that had no preset price and one whose preset price was replaced. Your reviewer should be able to tell which happened.
Finally, set a fallback. If a manager is unavailable or the record cannot capture the required details, staff need a clear instruction: pause the correction, contact the designated manager or use another approved process. Do not make staff guess during a rush.
Ask vendors to show the whole workflow
Bring the same requirements sheet to each demonstration. Toast lists restaurant POS, hardware, online ordering, payments, kitchen display systems and integrations. Square offers restaurant point of sale and related payment and order tools. Fleksa offers restaurant POS connected with direct ordering, reservations and related tools. Those descriptions do not establish how any of them handles your override rule; ask each vendor to demonstrate it.
Begin on the device staff would use at the counter or table. Ask the vendor to ring an open-price item, then change a different item with a preset price. Have the demonstrator show what a server sees when requesting the change and what a manager sees when approving it. Check whether the reason is required, optional or unavailable, and whether staff can enter a useful explanation rather than select an overly broad label.
Then ask the vendor to attempt the same correction under a role without approval authority. A clear result matters: staff should know whether the change was denied, is waiting for approval or has already taken effect. Ask what happens if approval is canceled or the manager enters incorrect credentials. Does the original price remain on the order?
Do not stop at the checkout screen. Ask to see the receipt, the order detail and the report or history a manager would review later. The guest-facing receipt may need to show the final charge without exposing an internal reason. The manager-facing record should support your chosen review rule. Confirm where each detail appears and whether it can be found after the order is closed.
Repeat the relevant steps on each device and order channel where your team expects to make corrections. A workflow shown on a terminal should not be assumed to work the same way on a handheld or an online order. Include your POS hardware in the discussion, and ask which devices, plan, integrations or payment processor the demonstrated workflow requires.
Request a written quote for the setup you need. Ask about recurring charges, hardware, implementation, processing, contract length and cancellation terms. A quoted processing fee alone is not the all-in operating cost. Where a contract term needs interpretation, consult a qualified adviser.
Use an authorization and audit matrix
The following is a hypothetical practice scenario, not a claim about any product. A restaurant lists a special at $18. A manager is authorized to correct it to $16 because the special was entered at the wrong price. Separately, the restaurant sells an open-price item with an entered amount of $7. These are item amounts, not processing fees or estimates of operating cost; fixed, variable and exception costs are not included.
Use a vendor-provided demo or practice environment with simulated transactions. Do not run a real card payment, send a guest message or dispatch a courier. The matrix describes expected behavior under this restaurant's chosen rule. Enter actual results only after an authorized test; do not mark a row as passed just because a presenter says it is possible.
| Action and actor | Expected result during entry | Expected receipt or record | Decision if unmet |
|---|---|---|---|
| Server enters the $7 open-price item | Amount is accepted only under the restaurant's allowed role; staff can identify why it was entered. | Receipt shows $7. Manager record identifies the item, entered amount and actor; it does not invent a prior price. | Decide whether another approved entry process is needed. |
| Manager approves changing the listed special from $18 to $16 | Staff see the final $16 amount and enter the reason: incorrect special price. | Receipt shows the final $16 charge. Manager record retains $18, $16, the reason and relevant actor and approver identities. | Require a workable record or use a different approved correction process. |
| Server without authority attempts the $18 to $16 change | Change is denied or held for authorized approval; the server sees its status. | The order remains at $18 unless approval is completed. Ask whether the attempt is recorded and where. | Do not permit this role to use the workflow until the control meets the rule. |
| Manager reviews the closed practice order | Manager can find the order and open its history. | The approved correction remains distinguishable from the open-price entry, with the required details visible. | Assign a documented fallback or treat the requirement as unmet. |
For the approved correction, the item charge falls by $2: $18 minus $16. That is a price difference, not a deposit or payment fee. The example does not calculate an order total, tax or payment processing charge. If the receipt shows only $16, that can still satisfy the guest-facing requirement, provided the manager's record preserves the original amount and reason.
Record the result in a separate test log: date, device, role, order reference, observed screen and report, and pass or fail against each row. Note the exact plan and configuration used. If the system captures the final amount but not the original, record that as a failure of the stated audit requirement, even if the correction itself was easy to make.
Choose the operating rule and verify exceptions
Turn the matrix into an operating decision. Assign an owner to maintain the rule, a manager responsible for reviewing corrections, and a fallback for service when approval is unavailable. Set a review rhythm that fits the volume of exceptions. The reviewer should look for missing reasons, unexpected actors and repeated changes to the same item, then resolve questions with the people involved.
Make acceptance criteria specific. For the hypothetical listed-price correction, acceptance requires an authorized manager to approve $18 becoming $16, a receipt showing the final item charge, and a retrievable manager record with both amounts and the reason. If identifying both requester and approver is essential to your rule, require that too. A report that shows only the final $16 does not meet those criteria.
Ask about exceptions before rollout. Can a correction be made after payment or order closure? If so, what record is created and does the receipt change? What happens when a check is split, an item is voided or an order moves between devices? Can a reason or actor be edited later, and is that edit visible? If your team needs an answer, add the case to the matrix rather than assuming the standard flow covers it.
Keep practice separate from live service. Train staff in a safe demo or practice environment first, using simulated orders and no real payments, guest messages or courier dispatches. If you later run a live service pilot, authorize it separately, tell participating staff the operating rule and review actual exceptions. A simulation demonstrates a workflow; it does not prove how a busy shift will unfold.
Also decide how the review fits your broader restaurant management software routine. If records must be exported or retained for a particular purpose, ask the vendor how that works. For legal or tax treatment of records or corrections, ask a qualified adviser rather than relying on a POS demonstration.
Next step: Request a Fleksa restaurant POS demo using the matrix above. Bring your own roles, devices and acceptance criteria, and ask to see the receipt and manager record for each scenario.
Frequently asked questions
Is an open-price item the same as a price override?
Not necessarily. An open-price item may have no preset amount, while an override replaces a listed price. Set separate record requirements so a reviewer can distinguish the two.
Should every denied override attempt appear in a report?
That depends on your operating rule. If you need to review denied attempts, make that an explicit requirement and ask the vendor to show where the attempt, actor and time appear.
What if the receipt shows only the final price?
That may be suitable for the guest receipt. Check whether a separate manager-facing record retains the original amount, final amount, reason and required identities after the order is closed.
