A customer’s marketplace total may differ from the amount shown in your POS because the two screens are adding up different parts of the order. The marketplace may show delivery charges and a tip alongside food, discounts and tax, while the POS may display only the portion sent to the restaurant. A difference can also point to a missing discount, modifier or tax amount.
Start by comparing the parts, not just the final numbers. Find out what each total represents, trace one order in cents and ask the channel or integration provider to explain any amount you cannot account for. A difference is not automatically an error, but it should be understandable.
Start with the order components
Make a list for each ordering channel and restaurant location you want to compare. A delivery order from one marketplace may have a different set of charges from a pickup order or an order placed through your own website. Note the POS and any integration or middleware used for each route.
For each order, collect these amounts separately:
- Items and modifiers: Menu prices, quantities, add-ons and substitutions.
- Discounts: Promotions applied to the order, including which party funds them if that information is available.
- Tax: The amount displayed by each system, rather than an assumed rate.
- Delivery and other charges: Charges paid by the customer, with their labels and recipients where known.
- Tips: The amount the customer adds and where it appears.
Keep customer charges distinct from amounts deducted from a restaurant’s settlement. A delivery charge shown to a customer, a processing fee charged to a restaurant and a marketplace payout are different measures. Matching the displayed order totals alone does not establish the restaurant’s all-in operating cost or the amount it will receive.
Write down unknowns before drawing a conclusion. For example, you may see a delivery charge on the customer receipt without knowing whether it should appear on the POS order screen. Ask the provider rather than treating its absence as either normal or incorrect.
Define what each displayed total includes
Before comparing amounts, identify the exact screens and labels. A customer checkout total, an order-detail total in a marketplace dashboard and a POS order total may each have a different purpose. Even two totals called “order total” may not include the same components.
Ask each provider to walk through the actual channel, location and POS combination you use. Have them show which fields arrive in the POS, which remain in the channel dashboard and which require a manual lookup. Confirm whether the kitchen receives the item details and modifiers it needs; a matching dollar amount cannot prove that the order itself is complete.
Useful questions include:
- Does the POS amount include the customer’s delivery charge and tip? If not, where can staff see them?
- Does a promotion arrive as a separate discount or change the item prices?
- Which tax amount appears on the POS screen, and where can we compare it with the channel receipt?
- What happens when an item is unavailable, an order is changed or a refund is requested? Which actions are supported in each system, and which require staff to use another screen?
- Can we identify the same order in the channel, POS and kitchen view without relying on a guest’s personal information?
These answers matter as much as the integration label. Fleksa’s restaurant integrations directory distinguishes live connections from connections available on request. Availability and setup depend on the restaurant, so confirm your particular combination. If you are weighing another integration route, the guide to direct POS integration and middleware can help frame that decision.
Bridge one order in cents
The following is a hypothetical order, not a claim about how Fleksa or any marketplace handles these fields. Assume the customer buys two items for a combined 2,500 cents, receives a 200-cent discount, and sees 184 cents in tax, a 350-cent delivery charge and a 300-cent tip. The tax is an assumed displayed amount, not a calculation or a suggested rate.
For this example, assume the POS displays items, the discount and tax, but not the delivery charge or tip. The table bridges the two displayed totals. The last column shows how much each line contributes to the customer total minus the POS total.
| Order component | Customer view | POS view | Difference |
|---|---|---|---|
| Items and modifiers | 2,500¢ | 2,500¢ | 0¢ |
| Discount | −200¢ | −200¢ | 0¢ |
| Tax | 184¢ | 184¢ | 0¢ |
| Delivery charge | 350¢ | 0¢ | 350¢ |
| Tip | 300¢ | 0¢ | 300¢ |
| Displayed total | 3,134¢ | 2,484¢ | 650¢ |
The customer view adds up to 3,134 cents, or $31.34. The POS view adds up to 2,484 cents, or $24.84. The 650-cent difference is fully explained by the assumed delivery charge and tip being outside the POS display. That does not tell you who receives those amounts or what the restaurant is paid.
This is a displayed-total bridge, not a cost or payout calculation. It includes the listed customer-facing components only. Fixed software costs, variable processing or marketplace fees, and exception costs such as refunds are excluded. Review those separately if you are comparing operating costs.
Now change the question: what if the POS showed 2,584 cents instead? Under the same assumptions, the POS would be 100 cents higher than expected. The delivery charge and tip would no longer explain the whole gap. Check item and modifier prices, the discount and tax line by line before deciding which provider needs to investigate.
Use a safe comparison and document exceptions
Build a small set of cases around your own menu and channels. Include a basic order, an order with modifiers, one with a discount and one with a tip or delivery charge. Add an exception that matters to your staff, such as an unavailable item or an order change. Do not assume every provider supports every action; an unsupported case is a limitation to record and weigh.
Start with a simulation or a provider-approved test environment. Use a unique test identifier and fictional order details. Configure the exercise so it cannot charge a real card, send a guest message or dispatch a courier. If a provider cannot demonstrate a step safely, ask for a walkthrough instead of triggering a live transaction.
For each case, record the expected item details and amounts before the demonstration. Then record what actually appears in the channel, POS and kitchen view. Keep the expected and observed entries separate. Include the screen label and whether the amount is in dollars or cents; a screenshot or written field list without private guest data can make a follow-up easier.
A simulation checks the setup without involving a real guest. If you later choose a live service pilot, agree on its scope and safeguards with the providers first. Treat it as a separate decision, not as a necessary step in a practice scenario. Do not promise staff that a new route will run without interruption while it is being introduced.
For example, if an unavailable-item change cannot be made through the POS but staff can handle it in the channel dashboard, record that manual step. Decide who will perform it during a rush and how the kitchen will learn about the change. If nobody can show where the change appears, leave the case unresolved rather than marking it as passed.
Assign each gap and make the buying decision
Turn the comparison into a short issue list. Give each unexplained amount an owner, the affected channel and location, the order identifier, the expected result and the observed result. Ask the channel provider, POS provider or integration provider to explain the specific field. If the issue crosses systems, name one person at the restaurant to coordinate the replies.
Separate a display difference from a decision-changing problem. If the customer total includes a charge that the POS intentionally excludes, and staff can find that charge in a reliable place, the difference may be workable. If a discount is missing, modifiers do not reach the kitchen, or staff cannot identify the matching order, resolve that before relying on the route.
Compare the remaining manual work with your staffing. A second dashboard may be manageable for one location with a few orders, but harder when several channels are busy at once. Ask for a demonstration of supported exception handling and a written description of any manual steps. For a location using the Uber Eats integration, for example, confirm the connection and the fields for that location rather than assuming another restaurant’s setup applies.
Bring your channel list, POS details and safe test cases to a Fleksa demo. Ask the team to show the relevant restaurant POS system screens, explain any differences in displayed totals and confirm availability for your location.
Frequently asked questions
Does a different POS total mean an order is wrong?
Not necessarily. The screens may include different charges or tips. Compare every component and investigate any difference that remains unexplained.
Should the POS total match the marketplace payout?
Not necessarily. A displayed order total and a payout measure different things. Ask for a separate breakdown of deductions and adjustments when comparing the payout.
How can I check an integration without affecting a guest?
Use a simulation or provider-approved test environment with fictional details. Confirm that the exercise cannot create a real card charge, guest message or courier dispatch.
