You can identify the recipient and reporting path for each type of delivery tip only if you trace it from the ordering channel through every connected system and settlement report. A tip displayed on an order is not, by itself, proof of who receives the money or where it appears in your restaurant’s records.
Before choosing an integration, list your channels and locations, ask vendors which tip fields pass through each connection, and compare a sample order with the reports used to settle and review it. Mark anything you cannot verify as an open decision.
Separate the tip, its recipient, and the payment path
Start with the guest’s action. Did the guest add a delivery tip at checkout, leave a cash tip at the door, or add an amount after the order was placed? Those amounts may follow different paths even when they relate to the same order. A cash tip handed to a driver, for example, will not necessarily appear in an online order record.
Next, identify the intended recipient and who actually holds or distributes the money. Depending on the arrangement, the recipient could be a delivery worker, restaurant staff, or someone else under the channel’s terms. Do not infer the recipient from a field labeled simply “tip.” Ask the channel and delivery provider to explain the arrangement for each location.
Finally, map the payment path. A marketplace may collect the guest’s payment and provide a settlement report. A direct-order transaction may follow a different payment and delivery arrangement. An aggregator or middleware service may pass order information to the POS without handling the funds itself. Ask each provider what it sends, what it displays, and what it pays out.
Keep sales, tips, deposits, and fees separate in your worksheet. Sales are the order’s food and other sale amounts; a tip is a separate guest-added amount. A deposit is money transferred to an account, potentially after adjustments. Processing fees are costs, not tips or sales. A quoted processing fee alone is not the all-in cost of running a channel: software, delivery, and other applicable charges may also matter.
For each restaurant location, write down the ordering channel, delivery arrangement, payment collector, POS, and any intermediary. The same marketplace name does not establish that two locations have the same setup or reporting path.
Follow the fields from channel to POS
Ask for a walkthrough using your exact channel, location, intermediary, and POS combination. Start with the source order and follow its identifier into the integration, the POS order, and the reports your team uses. A connected kitchen ticket is useful, but it does not answer the tip-reporting question.
Use these questions in the demonstration:
- Is the tip sent as a separate amount, combined with another amount, or omitted from the POS order?
- Does the record identify the intended recipient, or must the team consult the channel’s terms and settlement report?
- Can staff match the channel order ID to the POS order and settlement entry?
- Where does a tip added or changed after checkout appear? Does it update the original POS record, appear elsewhere, or require a manual note?
- How are cancellations, refunds, and missing or mismatched amounts shown? What action can staff take, and where?
- Can reports be filtered or exported by location and channel, and which fields are included?
Ask the vendor to show each answer in the relevant screen or report, rather than relying on a general statement that orders are integrated. If a field stays in the channel report, that can still be workable. The important point is that someone knows where to find it and how to match it to the order.
Also separate an available action from manual work. For example, a POS may display an imported amount while the restaurant still needs to review a separate settlement report. If a desired change is not supported, record the limitation and decide whether the team can handle the extra step reliably.
When comparing restaurant integrations, check which connections are available for your setup and which are on request. The Uber Eats integration page is a starting point for a channel-specific discussion; ask what it means for tip fields in your particular configuration. If you are weighing a direct connection against an intermediary, the related buying guide can help frame that choice.
Build a recipient and reporting-path matrix
The following example is hypothetical. It shows how one restaurant might document three tip situations; it does not describe any vendor’s actual behavior. The restaurant must confirm recipients and report locations before treating the matrix as an operating procedure.
| Tip situation | Expected recipient | Expected reporting path | Open question and owner |
|---|---|---|---|
| Marketplace checkout: $4 delivery tip | Delivery worker, subject to channel terms | Source order shows $4; settlement report shows its treatment; POS field to be confirmed | Does the POS receive a separate tip field? Integration vendor to demonstrate |
| Direct order: $3 delivery tip | Delivery worker, subject to delivery agreement | Direct-order record shows $3; payment and delivery reports to be matched; POS field to be confirmed | Who transfers the tip and where is that transfer reported? Delivery provider to explain |
| Cash tip at the door: $2 | Person receiving the cash, subject to the restaurant’s arrangement | Not expected in the online order or deposit; follow the restaurant’s cash-recording procedure | What record should the team keep? Manager to confirm with an adviser |
The matrix distinguishes an expected recipient from a verified payment. In the first row, seeing $4 on the source order would establish that the guest added that amount; it would not establish that the worker received it. The owner’s next step is to compare the channel’s terms and settlement information with the integration vendor’s demonstration.
Give each unknown a named person at your restaurant, not just a vendor to contact. Set a date for an answer and a decision: accept the reporting path, add a documented manual check, or keep evaluating. If the answer differs by location, use separate rows rather than forcing one rule across the business.
Compare a safe order scenario with reports
First run a simulation or use a vendor-provided test environment that cannot trigger a real card payment, guest message, or courier dispatch. Use an invented order identifier and no private customer information. Agree on the expected result before looking at the output.
In a separate hypothetical scenario, order TEST-27 contains $24 in food and a $4 delivery tip, for a guest-facing total of $28. This example excludes fixed costs, variable costs such as processing and delivery charges, exception costs such as refunds, and any other charges. It is an order-total check, not a deposit calculation or an estimate of operating cost.
The expected result is a source order showing $24 in food and $4 as a separate tip. The POS should show the order and its food total; whether it shows the tip separately is a question for the configured connection. Record the actual simulated result beside each expectation. If the POS shows only $24, note that difference and check whether the $4 remains visible in the channel report. Do not assume the missing POS field means the tip was lost or paid to the restaurant.
Match the identifier across the source order, integration record where available, and restaurant POS system. Also check modifiers and totals so the tip review does not obscure an order-entry problem. Then ask to see how a supported cancellation, refund, or later tip change would be represented. An unsupported scenario is a documented limitation, not a failed promise of functionality.
A simulation checks what the setup displays; it does not prove a real settlement or payout. If you later consider a live service pilot, agree its scope and safeguards with the providers first. Review actual reports and transfers only through an authorized process, and do not use a practice scenario to initiate a real payment, guest message, or dispatch.
Resolve treatment and ownership before rollout
Once the reporting path is mapped, ask a qualified local adviser how each tip type should be treated and what records your restaurant should retain. Bring the channel terms, delivery agreement, sample reports, and your matrix. Your adviser can help address the applicable legal and tax questions; a POS field name is not a substitute for that advice.
Assign a manager to review channel and settlement reports, another person to investigate differences, and a backup for each role. Decide how often the review happens and where the team records unresolved items. When an amount differs, note the order identifier, channel, date, expected amount, observed amount, and next contact. Avoid copying unnecessary guest details into the investigation log.
Choose the setup that your team can actually reconcile. A system that displays the tip on the order may reduce a lookup, but a separate report can be acceptable if matching is dependable and the extra work has an owner. If the recipient or payout path remains unclear, get that answer before relying on the connection for tip reporting.
Bring your channel list and tip test cases to a Fleksa demo. Ask the team to walk through the reporting path for your POS and confirm availability for your restaurant’s location.
Frequently asked questions
Should every delivery tip appear in the POS?
Not necessarily. Ask whether each channel sends the tip to the POS and where it appears if it does not. Make sure staff can match the order to the report that contains it.
Does a tip on an order prove the driver received it?
No. It shows an amount associated with the order, not necessarily a completed payout. Check the applicable channel or delivery arrangement and the relevant settlement records.
Can we test tip reporting without placing a live order?
Ask for a simulation or test environment that cannot charge a card, message a guest, or dispatch a courier. Use an invented identifier and compare the displayed result with your expectations; review real settlement separately through an authorized process.
