Requesting Bills

When the guests are ready to pay, you request the bill. This is a signal — not a payment — that tells the POS terminal the table is ready to cash out. Payment happens on the POS, not the waiter tablet.

​

Overview

Requesting the bill:

• Flags the table as billing on the floor plan (magenta border).
• Tells the POS to prioritise this table on the Table Billing view.
• Optionally checks the kitchen for un-served items and warns if food is still coming.
• Broadcasts to nearby devices via LAN so cashiers see it instantly.
• Queues offline if the network is down.

​

Reading the Bill Summary

The Manage view for a table shows the Bill Summary — a per-item breakdown with KDS status labels: Each item shows one of these status labels: The subtotal at the bottom reflects only non-cancelled items.

​

Mark items served (thermal print mode)

When thermal_print_enabled is on and the kitchen uses paper tickets rather than a KDS, the Bill Summary shows a checkbox beside each item once it’s ready, printed, or served.

• Tap the checkbox as each item lands at the table.
• The status flips to Served.
• When every non-voided item is served, the session auto-transitions to served and the floor card turns grey-green.

A banner explains this:

Kitchen ticket printed — tick each item below as it arrives at the table. Once every item is served, the table auto-marks as ready for payment.

​

Request the bill

At the bottom of the Manage view:

1. Tap Request Bill.
2. DishInk queries table_order_items for anything still sent_to_kitchen or preparing.

​

If nothing is pending

The request is placed immediately:

• The table flips to billing.
• A LAN broadcast fires.
• A toast confirms: Bill requested · Table 7.

​

If items are still with the kitchen

The Kitchen Warning modal opens:

Kitchen is still preparing 2 items and 1 more is waiting to start. Are you sure you want to request the bill now?

You have three options:

• Cancel — dismiss, go back to Bill Summary, wait for kitchen.
• Request Anyway — proceed with the bill request. Items in-flight will still be served, but the table shows billing immediately.
• Notify Kitchen (if configured) — sends a “priority finish” ping to the KDS.

​

Offline bill requests

When offline, the Kitchen Warning check is skipped (no way to query in-flight status). The request queues immediately with an amber toast: Bill request queued · Table 7. LAN broadcast still fires so the on-network POS can pick it up.

​

What the POS does next

The POS receives the request via realtime or LAN:

• The table jumps to the top of the Table Billing list.
• A New bill request notification badges the POS chrome.
• The cashier opens the table and processes payment — split, discounts, partial, refunds, and Smart Invoice all live on the POS.

Once payment completes, the session closes automatically and the table returns to free (or auto-archives if temporary).

​

Cancelling a bill request

If the guests order another round after requesting:

1. Simply add items via Taking Orders — DishInk resets the table from billing back to ordering.
2. Any queued POS notification is dismissed.
3. Send the new items to the kitchen as usual.

No PIN required for this — it’s a routine mistake.

​

Tips & best practices

​

Common mistakes

• Requesting before the last course. The Kitchen Warning is your seatbelt — heed it or use Request Anyway knowingly.
• Confusing Request Bill with Pay. Payment is on POS. Requesting is just a signal.
• Marking items served the guest hasn’t received. Only tick the checkbox on delivery. If you tick too early and all items go served, the table auto-transitions to served — the cashier may think it’s ready.
• Requesting when offline and assuming the POS saw it. The queue still needs to sync. The LAN broadcast helps on-network — but a POS in another building may not know until reconnect.

​

Related pages

• Table Billing (POS)
• Split Bills
• Partial Payments
• Sending Orders to Kitchen
• Kitchen Display / Preparing Orders
• Closing Tables