Yes—a manager can tell whether live sales include unpaid orders if the POS report identifies its inclusion rule, or the vendor can demonstrate and document it. The number labeled “sales” alone is not enough. One report may count an order when it is entered; another may count it only after payment.
That difference matters during service. A manager looking at a strong sales total might assume the restaurant has already collected that money. An owner comparing a shift with another period might make a staffing decision on a different basis than intended. Before buying a POS, ask what the live report counts, when it counts it, and how to see the unpaid portion separately.
Start with the check status and report time
An open check is an order that has not been fully settled. A guest may still be eating, adding items, or waiting to pay. A closed or paid check has been settled under the POS workflow. Ask the vendor whether those terms always mean the same thing in its reports: a check could be closed through a nonpayment adjustment, for example, or partly paid while still open.
Set a specific observation time before comparing totals. A report viewed at 1:00 p.m. describes a different point in service from one viewed at 1:15 p.m. Even with identical settings, new orders, payments, and adjustments can change the number between those moments.
Also separate the amount of sales from the amount collected. A sales figure can describe ordered items while a payment figure describes money received. Tips, refunds, discounts, and other adjustments may appear in different places. Ask the vendor to define the fields rather than assuming that two reports with similar names use the same rules.
The manager needs an in-service view that supports immediate decisions: how much business is recorded so far, how much remains unpaid, and whether a check needs attention. The owner may want a consistent basis for comparing lunch shifts. The cashier or server needs to understand which checks are still awaiting settlement. Those needs can require more than one report or filter.
Compare two ways to read the same shift
Hypothetical example: At 1:00 p.m., a restaurant has three checks. Check A is paid for $80. Check B is open for $50, and check C is open for $30. For this illustration, each amount is the full check amount being compared; there are no tips, discounts, refunds, taxes, processing fees, or other adjustments. The figures are sales and payment amounts, not an operating-cost calculation.
The table shows two possible report rules applied to the same checks at the same time. The right-hand columns show what each rule would count, not a claim about any particular POS.
| Check at 1:00 p.m. | Status and amount | Include open checks | Paid checks only |
|---|---|---|---|
| A | Paid: $80 | $80 | $80 |
| B | Open: $50 | $50 | $0 |
| C | Open: $30 | $30 | $0 |
| Total | $160 recorded; $80 unpaid | $160 | $80 |
Both totals can be useful. The $160 view shows the value recorded on all three checks, including $80 not yet paid. The $80 view shows only the paid check. Neither, by itself, tells the manager whether the two open checks will be paid at their current amounts.
If the manager sees $160 labeled simply “sales,” the practical follow-up is to find the underlying checks and their statuses. Can the report be filtered to paid checks? Is there a separate open-check list? Does the total update when an item is added, or only when a check is settled? A manager should be able to trace the headline number back to its components without guessing.
For a buying comparison, write down the report name, the selected filters, the observation time, and the total shown. Record the vendor’s explanation beside those details. A demonstrated result for one report does not automatically establish how another dashboard, export, or date-range report behaves.
Follow a payment into a later period
Continue the same hypothetical shift. Check B is paid in full at 1:15 p.m. for $50. Check C remains open at $30, and nothing else changes. At 1:15, a current all-checks view would still show $160 under the example’s inclusion rule. A current paid-only view would show $130: the original $80 plus the $50 payment.
The more subtle question is what happens when the manager runs a report for the earlier period. Does the report use the time the order was entered, the time it was paid, or another timestamp? Does it preserve the status as it was at 1:00, or recalculate an earlier period using the check’s current status?
For example, a historical snapshot taken at 1:00 would retain B as open at that moment. A report that recalculates an earlier order period after 1:15 might instead show B as paid, depending on its rules. A payment-time report could place the $50 payment in the later period. These are different possible designs; ask which applies to the exact report you plan to use.
An exception can change the buying decision. Suppose Check C is voided after 1:00. Under an all-checks rule that recalculates earlier results to remove the full $30 void, the total for those checks would become $130. A preserved 1:00 snapshot would still show $160 at that time. If the owner needs a reliable record of what the manager saw during service, the ability to retrieve a snapshot—or another documented way to reconstruct it—may matter more than a convenient live dashboard.
Ask how partial payments, split checks, discounts, voids, and refunds affect both the check status and the report period. You do not need every exception in the first demonstration. Pick the ones that happen regularly in your restaurant, then ask to see how each appears in the report and its detail view.
Turn the example into a safe vendor comparison
Give each vendor the same three-check scenario and ask for a walkthrough using a demonstration or sandbox environment. Have the vendor confirm that the practice setup will not create a real card payment, guest message, or courier dispatch. Simulated checks are for understanding report behavior, not for testing payment processing or live service.
- Set the starting point. Enter the three hypothetical checks and settle only A. Note the simulated time and any report filters.
- Read the live view. Ask which amount appears, whether open checks are included, and where the $80 unpaid balance can be identified.
- Simulate the later payment. Settle B in the practice environment. Reopen the current view and the earlier-period report. Ask which timestamp and status each uses.
- Try the exception. Simulate the void of C and compare the earlier snapshot, if available, with any recalculated report.
- Save the explanation. Request screenshots or an export and a written description of the report name, filters, timestamps, and treatment of open checks and adjustments.
If the vendor cannot reproduce one of the views, record that as a question to resolve before selection. A workaround may be acceptable, but the manager should know how many steps it takes and whether it can be used during a busy shift. Ask who can access the report and whether the same definitions apply across locations, devices, and exports.
A later live-service pilot is a separate decision from the simulation. If you choose one, use your normal authorized service and payment procedures, and compare the report with actual check records. Do not create practice charges or dispatches to make a live result look complete. The pilot can reveal workflow issues that a controlled demonstration cannot, but it should not replace written report definitions.
Choose the reporting rule your team can use
There is no single best live-sales number for every task. If a floor manager needs to see demand already entered, a view including open checks can be useful, provided the unpaid amount is visible. If the question is how much has been collected, use a payment view with a clearly defined period and treatment of adjustments. If neither view can be traced to individual checks, the headline total is a weak basis for a decision.
Apply the same requirements sheet to Fleksa, Toast, Square, or another vendor: report name, included check statuses, timestamp, adjustment handling, detail access, and the evidence provided. Ask whether the necessary view is part of the quoted setup and whether extra services or equipment affect the quote. Get current terms in writing; a processing-fee quote alone is not the restaurant’s full operating cost.
For related questions, review these POS questions and the guide to payments, processing costs, cash close, and POS reports. You can also consider how reporting fits into your wider restaurant management software workflow.
Next step: Request a demo of the Fleksa restaurant POS system using the three-check scenario. Ask the team to document what the live and earlier-period reports show before and after the simulated payment and void.
Frequently asked questions
Do open checks count as sales in every POS report?
No. Inclusion depends on the report and its settings. Ask the vendor to identify the rule and show how to trace the total to individual open and paid checks.
Does a paid check always appear in the period when it was ordered?
Not necessarily. A report may use an order time, payment time, or another timestamp. Check the definition for the specific report and whether a later payment changes an earlier-period result.
How can I compare vendors without charging a real card?
Use the same simulated checks in each vendor’s demo or sandbox. Confirm that no real payment, guest message, or courier dispatch will occur, and request a written explanation of the results.
