When order totals do not match a management report, start with the records, not the difference alone. Choose a small set of orders, agree on which ones belong in the report, and trace each order through its status, timestamp and reporting location. That usually tells you whether you are looking at a filter problem, a timing difference or a record that needs vendor investigation.
Do not assume that the order list and dashboard measure the same thing. One may show orders placed during a calendar day while the other groups completed sales by business day. A void, refund or late sync can change the comparison too. The goal is to identify the exact records and rules behind the gap before changing settings or adjusting a report.
Define the sales total you expect
Write down the report’s location, date range and time zone. Then identify the event that assigns an order to that range: placement, completion, payment or another timestamp. A restaurant that serves past midnight should also ask when its business day begins and ends. A 12:15 a.m. order may belong to the previous service day in one view and the new calendar day in another.
Next, define the order states. For example, should the total include only completed orders? Are canceled or voided orders excluded? How are partially refunded orders shown? An order can be visible in an order list without qualifying for a completed-sales report.
Agree on the money basis as well. Decide whether you are comparing the amount before or after discounts, and how refunds, tips, delivery charges and taxes are treated. A payment total can differ from a sales total because it measures a different event or includes different amounts. Deposits are not automatically sales; check how the report treats them.
Keep source and dining option separate. A direct online order is a source; pickup and delivery are fulfillment options. Filtering for pickup is not the same as filtering for online orders. If you compare a restaurant POS system with a management view, record both filters on each side.
Fleksa’s partner portal provides order and dashboard views, including sales and order summaries for a selected period and order-status tabs. Available views and configuration can vary, so confirm which fields and filters your team can use before relying on a particular comparison.
Trace a small order list to the dashboard
Hypothetical example: A manager expects a report for one location and one business day. The agreed basis is completed order amounts after discounts, excluding tips, taxes and delivery charges. Voided orders do not count. There are no refunds in this set. These figures are sales amounts, not profit or an operating-cost calculation; fixed, variable and exception costs are excluded.
The table shows the expected contribution of each order and what the dashboard currently includes. The manager has identified two separate reasons for the $45 gap: one order has not yet synchronized and one falls across a business-day boundary.
| Order | Expected | Dashboard | Finding |
|---|---|---|---|
| A: completed | $40 | $40 | Included as expected |
| B: completed | $30 | $30 | Included as expected |
| C: completed | $25 | $0 | Awaiting synchronization |
| D: completed after midnight | $20 | $0 | Assigned to the next calendar day |
| E: voided | $0 | $0 | Correctly excluded; original amount was $15 |
| Total | $115 | $70 | $45 difference |
Order C calls for a timing check. Order D calls for a decision about which day the report should use. Order E is not missing sales under the agreed rule, even though its original amount may appear in an order-history view. Adding that $15 to the expected total would create a new mismatch.
If the manager intended to report by calendar day rather than business day, D would not belong in this day’s expected total. The expectation would then be $95, and the remaining difference would be C’s $25. The right answer depends on the report definition, not on making two numbers match at any cost.
Use a similarly small worksheet for a real discrepancy. Record an order identifier, status, relevant timestamps, expected contribution, reported contribution and the reason for any difference. Avoid copying guest names or payment details into a worksheet unless they are needed and handled under your restaurant’s data practices.
Check timing, status and day boundaries
Late synchronization
First, compare when the order was completed with when the report was refreshed. Note the time you checked and check again after the vendor’s stated sync window, if one applies. An order that appears later may explain a temporary gap, but it is still worth asking whether the delay fits your closing process.
If the record remains absent, confirm that it exists in the source order view and that the location and report filters match. Ask the vendor how to distinguish a pending sync from a failed one, what alert is available for a failure, and whether staff can safely retry it. Do not create a duplicate order to force the totals to match.
Voids and refunds
Check the event history, not just the current label. An order may have been completed and later voided or refunded. Ask whether the report revises the original day, records the adjustment on the day it happened, or presents it separately. A partial refund needs its own amount and date; treating it as a full void can overstate the difference.
Also check for a change of status after the reporting cutoff. A manager may compare an earlier snapshot with a later order list and mistake a legitimate change for a missing record. Save the report time alongside the status history.
Business-day boundaries
Look at orders near opening, closing and midnight. Record the time zone and the timestamp each report uses. If the restaurant closes after midnight, decide whether the operating report should follow the service shift or calendar date. Then ask whether the dashboard can use that definition or whether staff must account for the difference in another report.
Do not change the business-day setting during an unresolved investigation without recording the old setting and the time of the change. Otherwise, the next comparison may reflect a different rule rather than a correction.
Turn the finding into a support request
A useful support request lets another person reproduce the mismatch without searching through a full month of transactions. Send the location, report name, date range, time zone, refresh time and every active filter. State the expected sales basis and the exact order states that should count.
For each disputed record, provide the order identifier, amount, relevant timestamps and status. Say what you expected to see and what appeared instead. A screenshot of the report filters and total can help; remove unnecessary guest and payment information. Ask which timestamps and adjustment rules the report uses, and whether the vendor can trace the record from the order view to the report.
Keep the alternatives visible. If the record is in another day, ask whether the day assignment is configurable. If it appears after a refresh, ask about the normal delay and failure alerts. If its status excludes it, ask whether the report can show excluded records separately. If none of those explains the gap, request an investigation of that specific record rather than a general statement that the dashboard is working.
Set an owner and a follow-up time. Until the discrepancy is resolved, keep the original snapshot and document any manual reconciliation separately. If the result affects accounting or contractual questions, take the documented facts to the appropriate qualified adviser.
Set a practical acceptance test
Before buying or changing reporting software, ask the vendor to demonstrate the same trace. In a simulation or designated test environment, use clearly marked sample orders for a normal completion, a void, a delayed update and an order just after midnight. The practice must not take a real card payment, send a guest message or dispatch a courier.
Agree on the expected contribution and reporting day for each sample before viewing the result. The check passes when staff can identify each sample in the relevant views, explain whether and when it contributes to the total, and reproduce the agreed total after the stated refresh window. Record the filters, timestamps, expected amounts and observed amounts. If a sample fails, record the gap and who will investigate it; do not treat a changed expectation as a fix.
A simulation checks the reporting workflow without affecting service. If you later run a live-service pilot, use normal authorized restaurant orders and monitor actual operations separately. Agree in advance who checks the report and how discrepancies are escalated; a simulation alone does not prove that every live integration will behave the same way.
For a broader picture, compare the fields used by the dashboard with the information staff see in the kitchen display system. Use the guide to comparing labor hours with sales by shift when the sales total will also be used for shift analysis.
Next step: Take one unexplained order and its report filters to a vendor demonstration. Compare your management requirements with the workflows available in Fleksa’s restaurant management software, including how your team would trace that order and follow up on a mismatch.
Frequently asked questions
Why is an order visible but absent from sales?
It may have a status the report excludes, fall outside the report’s date or location, or not yet have synchronized. Compare its identifier, status and timestamps with the report rules before treating it as lost.
Should voided orders appear in a sales total?
That depends on the report’s definition. A report may exclude voids from sales while showing them separately in order history. Confirm how the system handles the original transaction and any later adjustment.
How long should I wait before contacting support?
Check the vendor’s stated refresh or sync window. If the record remains absent after that window, send support the order identifier, report settings, expected amount and the times you checked.
