Yes, an owner can distinguish marketplace order revenue from fees and settlements—but only if the reports show enough detail to connect the same orders and period. Start with item sales in the POS, then account separately for discounts, tax, marketplace charges, refunds and payout timing. The final settlement is the cash amount due, not a measure of sales or profit.
A useful report lets you trace the difference rather than just displaying two totals that do not match. Before buying software, ask to see that trace for each marketplace, location and POS combination you actually use.
Map what each channel reports
Make a list of your restaurant locations and the marketplaces active at each one. Include the POS used at each location and who can access the marketplace statements. A chain with the same menu at two locations may still receive separate statements or payouts, so give each location its own reconciliation.
For each channel, identify these amounts and where they appear:
- Gross item sales: the menu prices before discounts and other adjustments.
- Discounts: promotions applied to orders, including who funds them.
- Tax: amounts shown on orders and any amounts the marketplace retains or remits rather than pays to the restaurant.
- Marketplace fees: charges deducted from the settlement, with their basis and any adjustments.
- Refunds and other exceptions: credits, cancellations or corrections, including when they affect the statement.
- Settlement: the amount the marketplace says it will pay for the statement period.
Do not assume every marketplace calculates these lines the same way. A discount funded by the restaurant has a different effect on its settlement than one funded by another party. Tax may appear on the customer receipt without appearing in the restaurant's payout. Ask for a sample statement and a description of each line before deciding which figures belong in your bridge.
Also check whether the POS records an order at full menu price, after discounts, or in another form. A POS sales total can be useful for operations without being identical to the marketplace's settlement starting point. If a line is missing, note who can provide it and whether staff must enter or export it separately.
Compare the same orders and period
Choose a marketplace statement, then find the corresponding orders in the POS. Match location, channel, dates and time zone first. A statement based on settlement dates may contain orders from an earlier sales period, while the POS report may group orders by business day. Ask each vendor how its reports define the period and handle orders near closing time.
Use an order identifier to trace a few entries from the marketplace to the POS. Check item amounts, modifiers, discounts and tax, then look for any later refund or cancellation. If identifiers differ between systems, ask whether there is a cross-reference in the export. Without one, staff may have to match on several fields, such as time and amount, and investigate duplicates.
A summary can hide errors that cancel each other out. For example, one missing order and one duplicated order of the same amount could leave the daily total unchanged. Order-level detail is what makes that difference visible.
Ask the provider to demonstrate the exact workflow, not just show a channel logo. Can staff filter by location and channel? Can they export order-level data and fee lines? Does a refund update the original order, appear as a separate adjustment, or require a manual entry? What happens when the marketplace statement arrives after the POS period is closed?
When comparing restaurant integrations, separate actions the connection performs from work your team must do in a spreadsheet. A connection that sends orders to a POS is not automatically a settlement reconciliation. The related buying guide can help you assess connection arrangements; for this decision, focus on whether the financial fields and exports answer your questions.
Build a settlement bridge
The following figures are hypothetical and describe one statement, not a Fleksa price or feature. Assume the marketplace collects the customer payment and passes the tax shown here to the restaurant. The restaurant funds the discount. The refund is a later item adjustment with no tax change in this example.
The bridge includes a variable marketplace fee and the refund as an exception. It excludes fixed software costs, payment processing charges, delivery charges, other adjustments and any costs outside this statement. The fee is a statement deduction, not an all-in operating cost.
| Statement line | Calculation | Amount | How to read it |
|---|---|---|---|
| Gross item sales | Menu prices before discount | $200 | Starting sales figure |
| Restaurant-funded discount | $200 − $20 | −$20 | Reduces item sales to $180 |
| Tax collected | $180 + $12 | +$12 | Customer order total is $192 |
| Marketplace fee | $192 − $27 | −$27 | Deduction from settlement |
| Refund adjustment | $165 − $10 | −$10 | Later exception on this statement |
| Settlement | $192 − $27 − $10 | $155 | Amount due under these assumptions |
Read the table from top to bottom: the $200 gross item figure becomes $180 after the discount, and $192 after adding tax. The $27 fee and $10 refund then bring the settlement to $155. The $155 payout is not $155 in item sales; it includes the assumed tax amount and reflects deductions.
Suppose the POS initially shows $180 in discounted item sales and $12 in tax, but the refund appears only on the marketplace statement. The owner can explain $37 of the difference between the $192 initial order total and the $155 settlement: $27 in fees and $10 in refund. The next question is whether the refund also needs to appear in the POS, and in which period. Do not enter a duplicate adjustment just to force the reports to match.
For an actual statement, add rows for every applicable charge or credit. Keep amounts with different meanings separate: a fee is a cost line, tax is not item sales, and a settlement is a payout amount. The bridge explains the payout; it does not by itself calculate profit.
Test the workflow without creating a live order
Ask the provider to walk through a simulation using a unique test identifier and fictional data. Confirm in advance that the exercise will not create a real card payment, guest message or courier dispatch. If the systems cannot support that safe simulation, use a documented sample order and report instead.
Record the expected result before the demonstration: the source order's items, modifiers, discount and total; where those details should appear in the POS or kitchen workflow; and which settlement fields you expect to export. Then record what is actually shown in the simulation. If a supported exception can be simulated safely, trace it through the reports as well.
Keep the result specific. “Order appeared in the POS” does not answer whether a later fee or refund is available in reporting. Conversely, a missing automatic adjustment may be acceptable if staff can obtain a clear statement line and have a manageable manual process. Document an unsupported case as a limitation and decide whether that limitation matters for your volume.
A live service pilot is a separate decision from a simulation. Before any live pilot, agree on staff responsibilities, monitoring and a fallback process with the provider. Do not use a practice scenario to trigger real payments, customer communications or dispatches.
Assign the gaps and decide what to buy
Turn unresolved items into a short action list. Name an owner for each question, the report or person needed to answer it, and the next decision. For example:
- Order matching: Have the manager check whether both exports include a usable identifier. If not, estimate the time needed for manual matching.
- Fees and promotions: Have the marketplace account owner obtain a statement explaining the deductions and who funds each promotion. Decide whether the detail is sufficient for the bridge.
- Refund timing: Have the bookkeeper trace one adjustment across statement periods and determine whether it is already reflected in the POS.
- Accounting treatment: Ask your accountant how the restaurant should treat the relevant sales, tax, fees and adjustments in its books. Provide the statement and the bridge rather than assuming the payout is the sales figure.
For a low-volume channel, a monthly export and a manageable spreadsheet may be enough. For several busy locations, order-level matching and clear exception reporting may be worth prioritizing because manual investigation could consume more staff time. In either case, compare written quotes alongside the work that remains with your team. A quoted processing fee alone is not the full cost of operating a channel.
Bring your channel list, location details and safe test cases to a Fleksa demo. Ask how the restaurant POS system and relevant connections would handle your reports, and confirm availability for each location. If relevant, ask about the Uber Eats integration and the settlement detail your team would still need from the marketplace.
Frequently asked questions
Why is my marketplace payout lower than my POS sales?
Fees, discounts, refunds, tax handling and timing can all create differences. Match the same orders and period, then list each statement adjustment before drawing a conclusion.
Does a marketplace integration reconcile settlements automatically?
Do not assume it does. Ask the provider to show which order, fee and adjustment fields are available for your exact marketplace and POS, and which steps remain manual.
Should marketplace fees be subtracted from sales in the POS?
Keep the fee visible as a separate line in your bridge rather than treating the payout as sales. Ask your accountant how to record the amounts in your books.
