When a completed check is reopened and adjusted, start with its final value and trace the change back to the original close. A report may revise the original business day, show a correction on a later day, or offer different views for each. The important question is whether you can explain the difference without counting the same sale twice.
Ask the vendor to show you the original check, the correction, the final check and the reports affected by each event. Then decide whether the reporting method gives your managers enough detail to close a shift and explain later changes.
Trace the original close, reopening and correction
A completed check is a snapshot at the time it was closed. Reopening it allows a later change, but the original snapshot still matters: a manager may already have used it to review sales or close a shift.
Start with one check identifier and follow the events in order. Record when the check closed, when it reopened, what changed, who made the change and when it closed again. Check whether the system retains both the original and corrected details rather than showing only the latest total.
Here is a hypothetical example. A check closes on Monday with $100 in sales. On Tuesday, a manager reopens it, removes a $10 item that was entered in error and closes it again. The final sales value is $90. For this example, all amounts are sales before tax; payment processing fees, fixed operating costs and other exception costs are excluded. No deposit or payment movement is assumed.
The correction is negative $10. It does not make Monday's original $100 and the final $90 two separate sales. If the item removal also changes tax or requires a payment action in a real transaction, review those records separately. A sales adjustment alone does not establish that money was returned to a guest.
The reason for reopening matters as much as the amount. A corrected item entry, a changed discount and a moved check may each affect different report fields. Ask whether the system records a reason, whether the reason is required, and whether a manager can distinguish an ordinary correction from a change that needs follow-up.
A useful audit trail should let someone who was not on shift reconstruct the sequence. If the only visible record is the final $90, the owner may know the current check value but not why an earlier report showed $100.
Compare the transaction date and business day
The date and time of an action are not always the same as the reporting business day. A restaurant that serves after midnight may assign early-morning activity to the prior service day. A correction made the next afternoon introduces another choice: should the adjustment appear against the original business day, the day it was made, or both in different report views?
Neither report label alone tells you enough. Ask the vendor to define the business-day cutoff, the time zone, and whether a report uses the original close date, the adjustment date or another date field. Also ask whether changing the report's date range changes which events are included.
In the example above, two reporting presentations could both explain the final $90, provided their labels and supporting detail are clear. The table is a worksheet for comparing them. The figures describe sales, not deposits or payment processing.
| Report view | Monday | Tuesday | How to read it |
|---|---|---|---|
| Original-day restatement | $90 revised sales | $0 from this check | Monday's current total incorporates the $10 correction. |
| Adjustment-day activity | $100 original sales | −$10 adjustment | The two days together show $90 net for this check. |
Do not add the $90 from the first row to the $100 and negative $10 in the second. They are alternative views of the same check, not independent activity. A report that shows both original sales and adjustments in separate columns also needs clear labels so that its net figure is not added to its components again.
Consider what your team needs after a manager has already saved or shared Monday's report. If a current Monday report changes from $100 to $90, can the team retrieve the earlier version or otherwise explain the $10 difference? If Tuesday carries the adjustment, can the team trace it back to Monday's check? A daily total without that link can make a normal correction look like unexplained missing sales.
For a related look at matching reporting periods across different measures, see the guide to comparing labor hours with sales by shift.
Reconcile the final check against both report versions
Set an acceptance criterion before a demonstration: a manager should be able to follow the $100 original close, the negative $10 correction and the $90 final check from the reports available to your restaurant. The vendor should also explain which business day receives each figure and how the report was generated.
Use this sequence to compare the saved original report with a report run after the correction:
- Record the original view. Note the report name, date range, business-day setting and generation time. Identify the $100 check within the total.
- Inspect the correction. Find the reopened check and the removed $10 item. Confirm the original and final values and the time of the change.
- Run the later view. Use the same report settings first. Then run the adjustment-day view if the product offers one.
- Explain the difference. A restated original-day total should differ by $10 for this check. An adjustment-day view should connect the negative $10 to the original $100.
- Check the final position. The supported net sales value for the check is $90. Confirm that a report total does not count both the final check and its original version as separate sales.
Totals alone are not enough. If other checks changed between report runs, a $10 movement in the daily total could be coincidence. Ask for check-level detail or a transaction listing that isolates the example. Likewise, keep sales, tax, tips and payment activity in their own fields rather than treating a change in one as proof of a change in another.
Use a simulated check or a vendor-provided demonstration environment for this exercise. Confirm before starting that the simulation will not create a real payment, guest message or courier dispatch. A simulated check is a reporting exercise, not a live service pilot. If you later arrange a live pilot, define its scope and approval process separately; review any real payment or guest-facing action before it occurs.
For day-to-day use, decide who investigates differences and where the team records the explanation. A shift lead might flag a changed report, while a manager reviews the check history and notes why the correction was made. Your procedure should still work when the person who made the change is unavailable.
Specify the audit export and acceptance criteria
An export is useful only if its rows can be connected and interpreted outside the screen where they were created. Ask the vendor to show an actual sample for the workflow, explain each field and identify any separate reports needed to complete the trail.
At minimum, request evidence for:
- The check identifier, original close time and original business day.
- The reopening and subsequent close times, with the relevant business day for each event.
- The original and corrected item, discount and sales amounts, plus the net change.
- The user associated with each action and any recorded reason for the correction.
- The report name, filters and generation time, so a saved result can be compared with a later run.
- Any related payment or tax fields needed to understand the transaction, clearly separated from sales.
Ask whether an export retains the original values after a correction, whether each adjustment has its own row, and whether identifiers stay consistent across reports. If an export contains only current values, ask how a manager retrieves the earlier state. Also check how access is controlled and how long the detail remains available for your team's normal review cycle.
Write the owner's decision in operational terms. For example: We can accept an original-day restatement if a manager can retrieve the prior value, identify the person and reason for the change, and reconcile the revised report to the final check. Alternatively, an adjustment-day method may suit the restaurant if the later entry links back to the original check and managers can explain the net across both days. If neither view supplies the necessary trail, ask what additional report or separate tool would be needed before buying.
Check the workflow against your broader restaurant management software needs as well. Sales reporting does not by itself establish how records reach an accounting system; ask how your team would transfer and reconcile them. For contract or accounting treatment, consult a qualified adviser where needed.
Next step: Use the worksheet and your acceptance criteria to discuss the workflow with Fleksa. Explore the restaurant POS system, and ask for a demonstration of the specific reopened-check reports and exports you need before buying.
Frequently asked questions
Does reopening a check create a second sale?
Not necessarily. A reopened check can be a correction to the original transaction. Trace the check identifier and adjustment so the original and final values are not counted as separate sales.
Should an adjustment appear on the original day or the correction day?
Reporting approaches vary. Choose a view your managers can explain, and confirm how it links the original check, correction and final value across business days.
Does a lower sales total mean the guest received a refund?
No. A sales correction and a payment movement are different records. Review any payment action separately rather than assuming it occurred from the sales report.
