A manager can account for orders across delivery channels and the POS if the necessary records are available and someone owns the exceptions. Start with each marketplace's order list, match it to the POS, and investigate the records that do not line up. A dashboard total alone cannot tell you which order is missing or why.
The aim is order completeness: did each relevant marketplace order have the expected POS record and status? That is a different job from reconciling transaction amounts to bank payouts. Both matter, but an order can appear in the POS and still have a payout issue, or be absent from the POS without proving that money was lost.
1. Set the boundaries before exporting records
Choose one restaurant location and a closed period, such as yesterday's completed business day. Use the same start and end times for each export where possible. If a marketplace uses calendar days while your POS uses a business day that ends after midnight, note the difference and check the orders near the boundary separately.
List every marketplace the location actually uses, then obtain the permitted order records from each one and the relevant POS records. Include the source channel, marketplace order reference, creation time, location and current status where available. In the POS export, look for a source reference as well as the POS order ID. Keep access limited to staff who need the records, and leave guest names, phone numbers and addresses out of the worksheet.
Decide which events count before comparing totals. For example, will an order created during the period but canceled the next morning belong in yesterday's count? A useful approach is to count it by creation time and note its later status, as long as you apply that rule consistently. Also decide how to treat scheduled orders, manually entered orders, retries and duplicate submissions.
Ask each provider what the export represents: orders created in the period, orders completed in the period, or records updated in the period. If those definitions differ, a count difference may be a timing difference rather than an absent order. Record the definition and any access restrictions at the top of the worksheet so another manager can repeat the comparison.
2. Match individual orders, then compare statuses
Start with a unique marketplace reference and match it to the source reference on the POS record. If the reference is missing or changes between systems, use a combination of location, channel, time and order details to find a candidate. A similar timestamp or total alone is not proof: two guests can order the same meal within minutes.
For each likely match, check the items, modifiers and order total as well as the status. Keep the original marketplace and POS IDs in the record. If one system groups or splits records, ask the vendor how those records should be counted before marking them as duplicates or missing.
Separate two questions: is there a corresponding record, and do the statuses agree? An order marked canceled by the marketplace but completed in the POS has a record match and a status exception. It should not also be counted as an absent POS record. Keep the status labels as shown by each system until you understand how they map to one another.
When evaluating software, ask for a demonstration using your exact channels, location and POS combination. Can the manager export order references and statuses from both sides? What happens when a marketplace cancels or changes an order? Which corrections can staff make in the software, and which require a manual entry or a support ticket? Ask to see the steps rather than relying on a general integration label.
Fleksa's restaurant integrations directory distinguishes live connections from connections available on request. Check the actual setup you need; for example, the Uber Eats integration page is a starting point for a restaurant using that channel. If you are considering an existing POS connection instead, the guide to direct POS integration and middleware can help frame the choice. Neither approach removes the need to check order-level evidence.
3. Use a worksheet to find and resolve exceptions
The following example is hypothetical. A restaurant compares orders created during one closed day across two marketplaces. Its POS has ten matched records for twelve marketplace orders. The table counts each marketplace order once; the status issue is noted within the matched group, not added to the missing count.
| Channel | Marketplace orders | Matched in POS | Exceptions and next step |
|---|---|---|---|
| Marketplace A | 7 | 6 | One canceled order has no POS record. Confirm whether a POS record was expected. |
| Marketplace B | 5 | 4 | One order has no POS match. One of the four matches has a status difference. Investigate both separately. |
| Total | 12 | 10 | Two orders lack a match; one matched order also needs a status review. |
The total does not establish that two orders were lost. The canceled Marketplace A order may have been canceled before a POS record was expected, but the manager should verify the timing and setup. For Marketplace B, the manager should check the unmatched reference, the time boundary and any manual POS entries. For the matched status difference, compare the event times and ask whether the status update should have reached the POS.
In a working worksheet, give every exception its own row. Include the location, period, channel, source reference, POS reference if found, source status, POS status, owner, next action and review date. A short reason such as “canceled before expected POS creation, confirmed by provider” is more useful than simply marking an item closed. If evidence is incomplete, leave the item open and record what would settle it.
Also scan the POS for relevant marketplace-tagged records that do not match the channel export. They may reflect a different reporting period, a manual entry or a duplicate. Investigate those separately rather than subtracting them from the count of marketplace orders without a match.
4. Test the workflow and assign follow-up
Before buying or changing an integration, walk through a simulated order with the vendor. Use a unique test identifier and a test environment or another agreed simulation that cannot create a real card charge, guest message or courier dispatch. Compare the source order with the expected POS and kitchen result, including modifiers and totals. Then ask the vendor to demonstrate a supported cancellation or other exception. Record the expected result and what the demonstration actually shows.
If a case is intentionally unsupported, document the limitation and the manual procedure. Do not treat a simulation as proof that a live service has been tested. If you later run a live pilot, agree on its scope, staff responsibilities and safe handling with the providers first; check the resulting records after service without assuming the pilot guarantees every future order will appear.
Assign an owner to each open item. A shift manager might check for a manual entry, while the integration provider investigates a reference that did not reach the POS. Record the support contact, ticket reference and next review date. Agree on the decision each reply should support: close the item with evidence, correct an internal record through the permitted process, or escalate it to the marketplace or POS provider.
For a purchase decision, favor the workflow your team can actually repeat. If the vendor can show reliable references and useful exports for your setup, staff can spend their time on exceptions. If matching requires substantial manual work, ask who will do it during busy periods and whether the written quote covers the setup and support you need. A consolidated view is useful, but it does not replace a clear procedure for unresolved orders.
Bring your channel list and test cases to a Fleksa POS demo. Confirm which connections and setup options are available for your restaurant's location, and ask the team to show how you would investigate an unmatched order.
Frequently asked questions
How often should a restaurant reconcile marketplace orders?
Choose a cadence that lets your team investigate while records are still easy to find. A daily review of the prior closed business day can work for busy locations; use the same boundaries and follow up on older open items.
Does a missing POS record mean an order was lost?
No. A cancellation, reporting boundary, manual entry or reference mismatch may explain it. Check the order's history and the expected behavior for your setup before deciding what happened.
Should order reconciliation include marketplace payouts?
Keep payout reconciliation as a separate check. Matching orders and statuses helps establish completeness; comparing transactions with payouts answers a different question about money received.
