Restaurant Discounts, Voids and Refunds: Permissions, Reasons and Reconciliation

Discounts, voids and refunds are normal parts of restaurant operations, but weak controls can create till differences, inaccurate reports and opportunities for misuse.

Understand the three operations

A discount reduces the selling price, a void removes or stops an item or order before settlement, and a refund returns money after payment. Each action should have its own permissions, reason codes and reporting path.

Require a reason

For sensitive actions, require a reason such as entry error, guest complaint, unavailable item or manager instruction. A free-text note can add context without replacing the structured reason.

Set role limits and approvals

A waiter may request a discount, while higher percentages, post-payment voids or refunds should normally require a manager account or approval. Thresholds should be defined by role and location.

Keep the original transaction link

Every refund should remain connected to the original order, item, amount and payment method. The total refunded amount must not exceed the remaining refundable balance.

Separate pre-payment voids from post-payment refunds

Before payment, an item can be removed from an open order with a recorded reason. After payment, money must be returned through a refund linked to the original transaction. Merely changing an order status without recording the financial movement makes till and revenue reports unreliable.

Define discount rules

• Set a maximum percentage or amount for each role.
• Decide in advance whether discounts may be combined.
• Report item-level discounts separately from whole-order discounts.
• Record the user and reason for every manual discount.
• After payment, record the change as an adjustment or refund rather than silently changing the price.

Refund to the original method where possible

Where the payment setup permits, return funds to the original payment method and never exceed the refundable balance. Exceptions such as customer credit need a clear policy, guest consent and confirmed accounting treatment.

Handle offline and uncertain payment states carefully

During a network outage or when a payment result is uncertain, staff should not repeat a charge or refund before checking the original transaction. A needs-review status and manager approval path can reduce duplicate financial actions.

Practical scenario

After payment, a guest reports that one item was entered incorrectly. The manager finds the original transaction, confirms the item and refundable amount, records the reason and processes the permitted refund. The original order remains in the history alongside the refund and the users involved.

Management reports

• Discount count and value by employee
• Voided items and orders
• Refunds by payment method
• Most frequent reason codes
• Actions outside the normal pattern

End-of-shift review

The shift manager should review all discounts, voids and refunds together with till differences and unresolved payment states before closing the shift.

How Lonio can help

Depending on the confirmed configuration, Lonio can keep financial actions linked to the order history and restrict sensitive operations through user roles. Refund methods, approval steps, offline behaviour and audit detail should be validated in the live setup.

Conclusion

Good control does not mean banning discounts. It means every change has a reason, responsible user, appropriate permission and traceable report.

Frequently asked questions

What is the difference between a void and a refund?

A void normally removes an item before payment is finalised; a refund returns money after payment and must remain linked to the original transaction.

Should a waiter be able to issue refunds?

That depends on policy, but refunds should normally be limited by role or require manager approval.

How should refunds be controlled?

Record the amount, reason, payment method, original order and acting user, then reconcile them at the end of the shift.