A void report is a starting point for a conversation, not proof that someone did something wrong. Group voids by reason and shift, compare them with the number of orders, and look at what happened before each item was removed. Then check plausible explanations with the people who worked the shift.
The most useful result is a specific next step: clarify a menu button, change how servers confirm an order, or investigate why a product was unavailable. A manager can also decide that the report needs better reason codes before it supports any conclusion.
Separate voids, refunds, and discounts
A void generally removes or cancels an order item or transaction. A refund returns money from a completed payment. A discount reduces the amount charged. Your system may handle the timing and labels differently, so agree on definitions before comparing reports.
For example, a server who selects the wrong side and removes it before payment may create a void. Returning payment after a guest has already paid is a refund. Reducing a guest's bill because an item arrived late is a discount. Those events answer different questions, even if they arise from the same service problem.
Ask your POS provider what the void report actually counts. Does it show individual items, entire tickets, or both? Does a corrected item create a new line? Can a void happen after payment, and if so, how is it distinguished from a refund? Confirm whether the report shows the original amount, the amount removed, and when the action occurred.
Consistent reasons matter as much as consistent definitions. A short list might include entry error, guest changed mind, item unavailable, and duplicate entry. Give staff a way to explain unusual cases rather than forcing every event into an inaccurate category. If “other” is common, review its notes and decide whether a missing category would make the report more useful.
A restaurant POS system should make these workflows understandable to the people entering and reviewing transactions. During a purchase evaluation, ask to see how a reason is selected and how a manager can inspect the related order. Do not assume that every system records the same detail.
Group reasons by shift: a hypothetical worksheet
Suppose a manager reviews two dinner shifts using the same definitions. The report counts voided item events, not dollars or unique orders. The order count includes all orders opened during each shift. One order could have more than one voided item, so the rate is events per 100 orders, not the percentage of orders affected.
| Shift | Orders | Void reasons | Events per 100 orders |
|---|---|---|---|
| Tuesday dinner | 80 | 4 entry errors; 2 items unavailable | 7.5 |
| Friday dinner | 100 | 1 entry error; 3 items unavailable | 4.0 |
Tuesday has six events: six divided by 80, multiplied by 100, equals 7.5 events per 100 orders. Friday has four: four divided by 100, multiplied by 100, equals 4.0. Tuesday deserves a closer look, particularly at entry errors, but the numbers do not establish their cause.
Start with the four Tuesday entries. Were they the same menu item or modifier? Did they happen near the start of a shift, after a menu change, or during a busy period? Were several entered on one order? A cluster around one button suggests a different investigation from unrelated corrections spread across the evening.
Also inspect the unavailable-item events. Three on Friday may reflect one item that sold out before the menu was updated. Or they may involve three unrelated items. In the first case, the team might need a faster way to communicate a sold-out item; in the second, a broader availability review may be useful.
Keep a simple worksheet beside the report: the pattern, possible explanations, the evidence to check, the chosen action, and the date to review it. Record an owner for the follow-up. Avoid writing “staff carelessness” as a cause when the only evidence is a void reason.
Compare volume and context before drawing conclusions
Raw counts can mislead. A busier shift has more chances for an entry to need correction. The rate in the worksheet provides context, but a small number of events can still move it sharply. Compare several similar shifts when possible, and keep the definitions and time windows consistent.
Look beyond the total:
- Item and modifier: Are names, sizes, or buttons easy to confuse? Did a recent menu change alter the usual selection?
- Timing: Was the item removed before it reached the kitchen, after preparation began, or after payment? Ask what timestamps and order history the system can show.
- Service conditions: Were there unusual menu shortages, new staff, a large party, or a change in order flow?
- Reason quality: Are staff using the same code for the same situation? Read available notes before treating a label as a complete explanation.
- Related events: Did a refund or discount follow the void? Keep each event separate so the same service issue is not mistaken for several independent incidents.
For a kitchen-related question, compare the order history with what the team recalls seeing on the kitchen display system, if one is used. A void after preparation begins may call for a different response from a correction made before the kitchen starts. Ask the vendor whether the relevant timing and changes are visible; do not assume a report captures every kitchen action.
Labor context can help explain a busy shift, but it cannot establish why an individual item was voided. For a separate approach to staffing comparisons, see the guide to comparing labor hours with sales by shift. Keep that comparison distinct from the reason-code review.
Choose a correction and test it fairly
Return to the hypothetical Tuesday entry errors. The manager has several reasonable alternatives: leave the process alone and gather more data; clarify the menu labels; or coach the team on confirming selections. The right choice depends on what the order details and staff conversations reveal.
Suppose those conversations and order details indicate that the four errors involved two similarly named side buttons. Under that assumption, clarifying the labels is a more targeted first action than coaching one employee. Ask the team whether the proposed names are distinct enough to use quickly. Also check that the change does not make the kitchen's item names confusing.
Record the acceptance test before making the change. For this example, the manager can use the following worksheet entry:
- Decision: Try clearer names for the two sides.
- Practice check: In a designated training or sandbox environment, ask staff to select each side from a sample ticket and identify it on the order view. Confirm that this simulation cannot create a real payment, guest message, or kitchen or courier dispatch. If that environment is unavailable, use a paper mock-up instead.
- Acceptance criteria: Each participant selects the intended side on the sample ticket and can distinguish the two names without a manager pointing to the correct choice. If not, revise the labels and repeat the check.
- Live-service review: Once the change is approved, review the relevant entry-error voids and ask staff about usability over the next few comparable shifts. This is a separate live review, not the practice test. Decide whether the labels helped, need another revision, or were not the main issue.
A successful practice check shows that the labels work in the sample scenario. It does not prove that voids will fall during service. If the issue continues, look again at screen layout, modifiers, order communication, and whether the reason code is being used consistently.
Make review routine, not punitive
Set a regular review that fits the restaurant's volume. A manager can scan totals and reasons, select a small number of unusual patterns for closer review, and document what was learned. Not every void needs an investigation: correcting an entry can be the appropriate way to keep an order accurate.
When a pattern involves a particular employee, ask for their account privately and describe the transaction rather than making an accusation. Check whether the same issue appears across staff, items, or shifts. If a transaction remains unexplained, follow the restaurant's established review process and preserve the relevant records rather than treating the reason code as a verdict.
For your next step, take one recent shift report and complete the worksheet: define the events and order count, group the reasons, list at least two explanations, and choose one practical check. Then compare your management requirements with Fleksa's available workflows, including the order detail and reporting views you need.
Frequently asked questions
Does a high void count mean staff are making mistakes?
No. It may reflect entry corrections, guest changes, unavailable items, or how the system records events. Review reasons and order context before deciding what needs attention.
Should managers compare void dollars or void counts?
Both can be useful, but they answer different questions. Counts show how often events occur; amounts show the value removed. Define whether the report includes items, whole tickets, or both before comparing either measure.
What if most voids are marked “other”?
Review any available notes with the team and look for repeated situations. Add or clarify a reason only when it helps staff classify events consistently, then check whether the new categories are being used as intended.
