
Ask what the figure represents
A payment-method column answers a different question from an item or sales view. It shows the routes through which amounts were assigned to a sale. First check whether the view includes confirmed payments, open transactions or both, and which period it covers. Bonzumo connects sales and payments, but a figure is useful only when its meaning is clear.
A table orders at seven and pays at nine. Depending on the view, order and payment may fall into different time windows. Do not read payment-method figures as a direct curve of kitchen workload. Order and production times matter more for that question. Note which event determines time assignment so two colleagues interpret the same view consistently.
Keep cash payments separate from cash held
“Paid in cash” first describes guest payments. It is not identical to the amount counted in a till. Opening float, deposits, withdrawals and other recorded cash movements change the physical balance without creating new restaurant sales. Comparing the cash-payment column directly with counted notes and coins misses that context.
For example, a report shows 200 euros in cash sales. The till opened with 100 euros float and a recorded 20-euro payment was taken out. With no other movements, 280 euros would remain in the till, while the payment method still shows 200 euros. This distinction explains a report without mistaking a cash movement for another sale or a missing card payment.
Read card payments as confirmed transactions
A payment request displayed on a terminal is not yet a confirmed card payment. When a card figure looks unusual, check whether the transaction reached the status that your agreed payment route treats as successful. An unclear terminal response is neither proof of a charge nor proof of failure. The feedback offered by a particular device must be checked for the actual integration.
With a split bill, one card transaction may cover only a portion while the table remains open. The card total explains the confirmed card share, not the state of the entire bill. Use table and payment context to understand the balance rather than concluding from one report column that the whole group has paid.
Treat vouchers as an amount applied
A voucher may cover part of a bill, leaving a balance to pay by cash or card. Read the voucher amount alongside the remaining payment. A 75-euro bill with an eligible 50-euro voucher leaves 25 euros for another method. Voucher origin and redemption must fit your configured process; every third-party scheme is not automatically connected.
When a voucher amount appears in a report, ask which sale it belongs to and whether a remaining balance was recorded separately. Do not treat application of the voucher as a second order. An understandable linked transaction is more useful than two columns no one can reconcile. Test the voucher types your venue actually uses and inspect the payment portions they create.
Put tips beside the bill amount
A tip is a voluntary extra, not another item sold. It may be paid in cash or included in a confirmed card amount. People splitting a bill may make different choices. Ask whether each reported figure means the bill, the tip or the combined charge. Bonzumo supports tips in the payment context; internal sharing follows the venues own rules.
For example, a guest pays a 40-euro bill and a 5-euro tip by card. The confirmed charged amount may be 45 euros, while the sold items still total 40 euros. Without that separation, a higher card figure can look like higher product revenue. Inspect a real transaction before using those columns for business decisions or handover.
Recognise partial payments within one bill
A group can split by item or into equal shares. Several payment portions, perhaps with different methods, can result. Counting payment transactions therefore does not reliably count guests or orders. Trace a sample bill and identify which part is cash, which is card and which remains open. Bonzumo supports splits; report figures must be read alongside that allocation.
For a Bonzumo demonstration, use a table of four with two partial payments, a voucher and one guest leaving no tip. Compare the individual payment route with the payment-method view. Can you explain totals without inventing intermediate amounts? If terminal status remains uncertain, label it unresolved instead of forcing it into a column. The report then becomes a clear view of real guest bills rather than a replacement for checking them.