A tour in screenshots
No mockups and no invented screens. Every screen here comes from a demo restaurant built and traded through the product itself: orders from the till and from the tables, a shift closed with a count, purchases received, and journals posted by the sale. Click any image to enlarge it and read the figures.
What each screen proves
Written for someone who has never used restaurant software: what the screen is, and why it matters.
Orders
At the top, an order a guest sent from table T07 by QR, marked "awaiting confirmation": it does not reach the kitchen until staff accept it. Below it, till orders with their status, payment state, subtotal, VAT and total in SAR.
Nothing reaches the kitchen that the restaurant has not accepted.
Tables
Available tables in green; occupied ones in orange with their open check and its amount. At the top, a payment request from table T08 waiting for staff, and every table has a QR code ready to print.
You know the state of the room without asking anyone.
Kitchen display
Till, QR and delivery orders on one board, in Waiting, Preparing and Ready columns. Each ticket shows the table, the items and how many minutes it has waited, and moves on with one tap.
The kitchen sees every order in one order of work.
Closing a shift
The system shows the cash expected in the drawer; staff count it by denomination and the total is worked out. The difference is shown (−3 SAR), and the session does not close without a reason for it.
Every missing riyal has a written explanation.
Purchasing
Each purchase order with its reference, supplier, status and total. Here, five orders have been received; on receipt, the quantities entered their locations and their cost updated.
Stock cost comes from what you actually paid.
Accounting
Every paid order produces two automatic entries: the sale, and the cost of the sale. Debit equals credit, and every one is "Posted" — nobody keyed them in.
The books agree with operations without a second round of typing.
Team and permissions
Each employee has a role — warehouse staff, kitchen staff, waiter, cashier, branch manager, owner — one or more branches, and a quick-login PIN. Names and addresses here belong to a demo account.
You know who did what, and at which branch.
The invoice
The paid order's invoice in Arabic and English: invoice number, VAT number, taxable amount, 15% VAT, total and payment method, and a QR code at the bottom.
An invoice for every paid order, automatically.
A difference in construction
Most restaurant software began as a till, and inventory, purchasing and accounting were added later as separate islands. The result is figures that sometimes agree and sometimes do not, and somebody spending the end of every month reconciling them. MENUVA was built the other way round: one operational event moves stock, cost and the accounts at the same moment.
The common approach
The till is separate from stock: a sale records an amount, and stock is updated later or by hand.
MENUVA
A sale takes the dish's ingredients off the selling branch's stock and costs them in the same moment.
The common approach
One number per item for the whole business — a generic pool that does not know where the goods physically are.
MENUVA
A central warehouse distinct from the branch stores, and every branch with its own stock and its own value.
The common approach
Weak per-branch visibility: figures roll up into one report and one branch is hard to separate from another.
MENUVA
Sales, cost of sales and stock per branch, decided on the server rather than by the device.
The common approach
A transfer is a manual edit of two numbers — subtract here, add there — with no document and nobody accountable.
MENUVA
A transfer is a document with a full cycle: request, approval, full or partial dispatch, then confirmed receipt — and the cost travels with the goods.
The common approach
No in-transit state: goods are either treated as arrived before they are, or vanish from the books in between.
MENUVA
An explicit state between dispatch and receipt: the goods belong to neither branch, and stay visible and counted in the valuation.
The common approach
Approvals on stock movement between locations are weak or absent.
MENUVA
A transfer needs approval from a user holding transfer-approval permission at one of its two ends before goods move, and the receiver confirms arrival.
The common approach
The purchase order does not name a destination: goods enter a generic pool and are traced afterwards.
MENUVA
The purchase order names the receiving warehouse or branch explicitly, so the receipt updates the right place directly.
The common approach
An estimate, or a figure kept in an outside spreadsheet that goes stale with every supplier price change.
MENUVA
A recipe per dish, with real ingredient consumption at the selling branch's weighted average cost.
The common approach
Separate accounting needing a second keying or a periodic export, so operations and the books drift apart.
MENUVA
Operational events produce their entries as they happen — sales, receipts, transfers, counting differences.
The common approach
Broad user-level permissions, with restriction usually done by hiding items in the interface.
MENUVA
Access by role and by branch, enforced by refusing the request at the server rather than hiding it on screen.
The common approach
A limited trail: after some time it is hard to establish who changed what, and when.
MENUVA
An auditable operational history, and accounting entries that cannot be edited retrospectively.
The common approach
Generic screenshots and unrealistic sample data that never show how the system actually runs.
MENUVA
A real demo restaurant with three branches, a central warehouse, live trading, real transfers and balanced books — and every screenshot on this page comes from it.
Every line in the MENUVA column can be opened and shown in the live demo. We name no competitor, and we claim no figure we have not measured.