Walk into the back office of a mid-sized café and count the screens. A POS on the counter. A kitchen display, or a ticket printer with its own controller box. A tablet for the QR-ordering vendor. An accounting package the bookkeeper uses. Somewhere in between, a spreadsheet that turns the POS's daily export into the numbers the accountant will accept.
Each of those was a sensible purchase on its own. Together they mean the same order is typed, forwarded, re-keyed or synced four times between the moment a guest asks for a flat white and the moment it appears in the month's revenue. This post is about the three loops a food business actually runs, and why they belong on one order record.
Loop one: the floor
The floor loop is state. Which tables are free, which are occupied and for how long, what has been ordered and what has not yet gone to the kitchen, which orders came in from a QR code and are waiting for a server to look at them.
The failure mode of a separate floor system is that the state lives in a different place from the money. A table shows "occupied" long after it was billed; a walk-up order is completed on the POS and never appears on the floor; a guest's QR order sits in the vendor's app until someone remembers to check it. In BIZA the floor is the list of open orders: a table is occupied because there is an unpaid order on it, and it frees itself when the last split of that order is billed. A guest's QR order lands on the table as unsent lines, so it appears exactly where the server is already looking.
Loop two: the kitchen
The kitchen loop is routing. The bar should not see the mains; the grill should not see the desserts; a round of drinks should go out before the food that follows it. Kitchen display systems solve this well — but as a separate product they need to be told about every menu change, and they have no idea what a void means to the books.
When the kitchen display reads the same order as the billing counter, routing is a property of the menu: each station lists the categories it cooks, "send to kitchen" creates one ticket per station, and the ticket prints on that station's printer and appears on its screen at the same time. Removing a line the kitchen already has requires a reason, and that reason becomes an audited event — the same event stream the manager's dashboard uses to flag a shift with an unusual void rate.
Loop three: the bill
The bill loop is where the second system usually lives. Splitting a bill by item or by seat, adding a tip, applying a service charge, taking three cards and some cash, printing a receipt the tax authority accepts — a POS does all of this. Then it exports a summary, and the accounting system receives a number it cannot see inside.
If the bill is a normal sale in the ERP, none of that summary exists. Each split is its own tax invoice with the next number in the business's sequence. The tip goes to a payable, not to revenue, and the tips report knows which server is owed what. The service charge goes to its own revenue account, taxed or not as the business decides, and only on dine-in if that is the policy. Gift cards, loyalty points, mada and UPI work at the table exactly as they do at a shop counter, because it is the same counter.
What "one order" makes possible
Once the floor, the kitchen and the bill share an order record, some things that used to need integration projects become settings:
- Waiters on their phones. The same counter, in a one-hand layout: menu, table, send, next table. No separate handheld product, no sync.
- Guests ordering from the table. A QR code opens a public menu; the order lands on the table unsent; the server reviews and sends it. No app to install, no payment taken on the guest page, and a code that can be rotated if it leaks.
- Offline service. The floor, the orders and the bills queue on the device and post in order when the connection returns, exactly once. Lunch service does not stop for the router.
- Real cash control. Shifts with a counted float, blind counts at close, every drawer open with a reason, and a dashboard that flags the shift a manager should look at — because the drawer is a ledger account, not a printout.
- Stock that means something. Bottles, packaged goods and retail lines on the menu leave the outlet's stock as they are billed, in the same inventory the purchasing team buys into.
How BIZA helps
BIZA's restaurant mode is the same point of sale that runs a shop, with floors and tables switched on: modifiers, kitchen display with station routing and ticket printers, split bills, tips and service charge, waiter phones and QR ordering at the table — every bill posted as a tax invoice and a journal entry the moment it is paid.
See the POS feature page, the hospitality industry page, or talk to the team.