A till that posts to the ledger, not a spreadsheet
POS Terminal and Floor / Tables are two screens of the same accounting system. Every ticket you close writes revenue, VAT, cost of sales and stock movement in one transaction — on the machine in front of you, with no network in the loop.
Fast counter sales, priced the way you sell them
POS Terminal is built for the queue at the counter: pick items, take the money, close the ticket. Prices are VAT-inclusive, because that is how a menu board works — the number on the button is the number the customer pays.
VAT is then extracted from the ticket price rather than added on top. A gross ticket of 46.00 at 15% leaves 40.00 of net revenue and 6.00 of VAT. The customer sees a round menu price, and the ledger still gets the split it needs for the VAT return.
- VAT-inclusive tickets. The gross is what you charge; the net and the VAT are derived, not bolted on afterwards.
- Revenue and COGS post as two entries. Not one blended line — gross profit is readable per product without unpicking anything.
- FIFO or weighted average. The costing method is a Settings choice and applies consistently across POS, purchases and production.
- Reprints are safe. Reprinting a kitchen ticket does not re-send it to the kitchen, so a lost docket never becomes a duplicate dish.
- Every sale is attributable. Each till operator works under their own named account, so a ticket belongs to a person, not to "the till".
Dine-in, table by table
Dine-in service is not one transaction, it is a conversation that lasts an hour. The floor screen holds that conversation open until the guest asks for the bill.
- Free
- No open order. The table is available to seat and carries no balance.
- Running bill
- An order has been taken and the table holds a running total. Courses can be added to it for as long as the guests are seated.
- Billing
- The running bill has been handed to POS Terminal to take payment. Once the ticket closes, the table returns to free.
One table, one running total
You take an order against a table rather than against a sale. The table becomes the container: it accumulates items course by course, keeps its own total, and stays open while people are still eating.
When the guests are ready, the table is billed through POS Terminal. That is the moment the sale exists as a document — VAT extracted from the gross, revenue and cost of sales posted, stock consumed. Before that moment nothing has hit the ledger, which is exactly what you want while a table is still ordering.
- Order per table. Add items whenever they are ordered; the running bill absorbs them.
- Bill through POS. The floor hands the table to the same till the counter uses — one pricing and VAT path, not two.
- Kitchen tickets sent once. A reprint gives the pass another copy without firing the dishes again.
- Seeded floor plan. A fresh install starts with a chart of accounts, a menu, a floor plan and an admin user, so the screen is not empty on day one.
From table to trial balance
Six steps, all of them inside one application, all of them on your machine. Nothing here is a nightly export or a sync job that can silently fail.
-
The order is taken
A waiter opens the table on Floor / Tables and adds items. The table now holds a running bill that can grow through every course.
-
The kitchen ticket is sent
The order goes to the kitchen once. If the docket is lost or smudged, a reprint produces another copy — a reprint does not re-send to the kitchen, so nothing gets cooked twice.
-
The table is billed through POS
The running bill moves to POS Terminal for payment. VAT is extracted from the gross ticket rather than added to it, so a 46.00 ticket at 15% resolves to 40.00 net and 6.00 of VAT.
-
The sale posts revenue and cost of sales
Two entries, not one. Revenue is recognised and the cost of what you sold is booked alongside it, which is what makes product-wise gross profit meaningful rather than a guess.
-
Stock is consumed through the recipe
The Bill of Materials tells the system what a dish is actually made of, and the components come out of stock. Consumption is transactional: a failure leaves nothing half-mutated, so you never find stock that moved for a sale that did not.
-
It lands in the ledger, the P&L and the ZATCA queue
The same posted document feeds Journal & Ledger, the profit and loss report and the ZATCA e-invoicing artifacts. One sale, one source, three places it shows up without being re-entered.
The shift closes when the drawer agrees
Every terminal runs inside a session: opened with a counted float, closed against an expected figure, signed off by a supervisor. The drawer count is a workflow, not a ritual.
-
The session opens with a float
The cashier counts the float into the drawer and opens the session on that terminal. From here on, every sale rung on the terminal is tied to this session.
-
The shift trades
Sales accumulate against the open session as they happen — cash, card and bank splits included — so the shift’s takings are recorded facts, not an end-of-night reconstruction.
-
Cash leaves the drawer only as a payout
Mid-shift cash out — the urgent produce run, the gas cylinder — is recorded as a payout with a reason. The expected cash already accounts for it, so a legitimate payout never reads as a short drawer.
-
The drawer is counted against expected
At close the application computes expected cash — float plus cash sales minus payouts — and the cashier enters the counted figure. Any difference shows immediately as over or short, before the close is submitted.
-
A supervisor signs it off
The submitted close waits in the sessions list for a supervisor to approve or reject — a cashier cannot approve their own count. The list filters by date, terminal, cashier and status, so the review takes minutes.
-
The books say what the drawer said
On approval, any difference posts to the ledger as a Cash Over/Short journal entry. Session-wise sales and collection reports stay attached to the session, and its append-only event log keeps every open, payout, close and decision.
Because it is local, it is fast and it never stops
This is not a cloud product with an offline mode. There are no network calls anywhere in the application. There is no server component at all — the database is one file on the same disk as the till.
No network calls anywhere
Nothing is sent out and nothing is fetched in. There is no server component, so nothing is listening on the network for anyone to reach.
Works with the internet unplugged
Permanently, not for a grace period. Activation is offline too — a machine code goes to us, an activation code comes back, and the licence is node-locked to that machine.
It keeps taking orders when the line dies
A dead router is an inconvenience, not a closed restaurant. Service carries on, tickets keep posting, and the ledger is as complete at the end of the night as it would have been.
- Your data survives an uninstall. The database is mirrored on a throttle to
Documents/Meezan ERP Restaurant/as plain, readable files you can copy to another machine. - Writes are atomic and fsync'd with a rolling backup, and a corrupt primary falls back to the backup automatically.
- The renderer has no filesystem surface at all — every file operation goes through the API or a native save dialog.
Recipes and stock that keep up with the kitchen
A restaurant sells dishes but buys ingredients. The gap between those two is where margin quietly disappears, so the app treats a recipe as a real manufacturing object rather than a note on a menu.
Bills of Materials
Define what a dish is made of and in what quantity. The recipe is what drives stock consumption when the ticket closes, so selling a dish moves the ingredients rather than an abstract “item”.
Production
For the things you batch in advance — sauces, doughs, prepped trays — a production run consumes components and puts the finished item into stock at cost.
Stock moves with cost
Every movement is recorded with its cost, so inventory valuation is a report you run rather than a spreadsheet you rebuild. FIFO and weighted average are both supported.
Stock by warehouse
Warehouses model sites, branches and storage locations — the walk-in, the dry store, the second kitchen. Stock is answered per location, not as one blurred total.
Stock transfers
Move goods between locations without distorting the accounts: a transfer posts no journal entry, by design. Nothing has been bought or sold, so nothing hits the P&L.
One costing method, chosen once
Pick FIFO or weighted average in Settings and it applies everywhere — POS consumption, production, purchases and the inventory valuation report all agree.
Who it is for
The app adapts its sidebar to the nature of the business, so a site only shows the modules it actually uses. Here is what that looks like for four common shapes of food operation.
A single restaurant
Restaurant nature switches on inventory, POS and tables together — manufacturing stays off unless you turn it on for a commissary kitchen. One machine runs the floor, the till, and the accounts, and the trial balance is available at close without exporting anything.
A cafe or counter-service site
If nobody is seated, the floor plan simply goes unused. POS Terminal handles fast counter sales on its own, and Bills of Materials still cost the drinks so gross profit per line is real.
A multi-branch operator
Warehouses represent sites and branches, Stock by Warehouse answers stock per location and Stock Transfer moves goods between them without touching the P&L. Each machine carries its own node-locked licence.
A delivery-only kitchen
No dining room, no floor plan — just tickets, recipes and stock. Production handles the prep you batch ahead, and the same posted sale still feeds the ledger and the e-invoicing artifacts.
Whichever shape you are, the accounting underneath is the same: double-entry throughout, malformed input checked before it posts, unbalanced entries rejected outright, and an automated test suite that checks the costing, cost-centre and combined-statement maths against worked examples on every release.
See it run a service
Install it and put a table through from order to trial balance in a few minutes — the sample floor plan is already there on a fresh install. No account, no connection, no data leaving the machine.