A Kathmandu restaurant with two floors, forty tables and one printer used to run on paper KOTs. The waiter wrote the order, walked it to the kitchen, and the kitchen shouted it back. It worked — until a Friday night with three waiters, two cooks and a queue at the door.
The shift that happened across 2025 and 2026 was not "restaurants bought software". It was narrower and more useful: the kitchen stopped reading paper, and the invoice stopped being a separate act from the sale.
What a kitchen display actually changes
A KDS is not a screen that shows the same ticket in a different font. It changes three things at once:
- Routing. A momo goes to the momo station, a pizza to the oven, a beer to the bar. Nobody walks the length of the kitchen to hand over paper.
- Timing. Every ticket carries an elapsed clock. Ten minutes is green, twenty is red. The kitchen sees the queue, not just its own bench.
- State. Pending, preparing, ready, served. A waiter can see "ready" without asking, and the cashier can see that a table is still eating before printing a bill.
The measurable win is not speed. It is that the kitchen stops being the only place that knows what is happening.
Why IRD invoicing moved to the same event
In Nepal, a tax invoice is not a receipt you write later. It has to be sequential, tied to the sale, and — once issued — it cannot quietly disappear. That makes the moment of payment the only honest place to mint it.
MasterRMS treats the settle action as a single transaction:
- the order is marked paid,
- the fiscal invoice is minted with the next number in the fiscal year sequence (2083/84 for 2026),
- the invoice number is stamped on the order,
- a reprint is marked
*** COPY OF ORIGINAL ***.
If step 2 fails, step 1 never commits. There is no state where money was taken and no invoice exists.
The three things that break first
Every deployment teaches the same lessons:
- Printer drivers. Thermal printers are reliable; the driver between the browser and the printer is not. Test the actual printer, on the actual counter, before opening night.
- Menu drift. Prices change on the board, not in the system. Give one person the menu permission and make it part of the morning routine.
- Staff turnover. A new waiter on a Saturday night will tap the wrong table. Table-level confirmation and an order log that shows who punched what is cheaper than a refund policy.
A practical rollout order
Do not switch everything on at once. The sequence that works:
- Week 1: menu and tables in the system, POS running, paper KOT still in parallel.
- Week 2: KDS on, paper KOT retired for the busiest station only.
- Week 3: fiscal invoicing on, cashier trained on reprints and voids.
- Week 4: reports and stock reconciliation, once the data is trustworthy.
By the end of the month the question stops being "is the software working" and becomes "why did table 12 wait nineteen minutes" — which is the question you actually wanted to answer.