Sales, purchases, cash, payroll, stock, recipes, assets, the counter, the floor and the ledger behind all of it — in a single desktop application that runs on your own machine, with the internet unplugged. This page walks through every screen in the sidebar and what you would actually use it for.
One page that answers the questions a manager asks before the shift starts, without running a single report.
A live snapshot of the operation the moment the app opens: what has sold, what is owed to you, what you owe, and how stock and cash have moved. Every figure is read from the same tables the reports read, so the headline number and the ledger can never quietly disagree with each other.
Twelve screens covering the full customer side: the documents themselves, the money still outstanding, and the analysis that tells you which customers and which dishes are actually paying for the kitchen.
Raise a quotation, turn it into a confirmed order, then deliver and invoice from the same document — or go straight to a direct invoice when the job was never quoted. The order carries its own status, so you can always see what has been promised and not yet handed over.
Every open order split into the two legs that actually get chased — delivery and invoice — each shown as Pending, Partial or Complete, with the order overall as Open, Completed or Cancelled. Filter by period, status and party; the KPI row totals open orders, order value and what is pending on each leg. Nothing new to maintain — it reads the same delivered/invoiced counters the order flow already keeps.
Record what physically left the kitchen or the store against an order. The delivery is the document that moves stock and books cost of goods sold, so your margin is right even when the invoice follows days later.
The tax document itself: lines, VAT, totals and the effect on the customer's balance. Invoices can be generated from a delivery or written directly, and each one posts a balanced double-entry journal behind the scenes.
A return, a spoiled dish or a billing mistake gets a credit note against the original invoice rather than an edit to it. The customer's balance comes down, both documents stay on file, and the audit trail stays honest.
Every riyal owed to you, aged into buckets so current debt and ninety-day debt are not sitting in the same total. Work down the list by customer and apply the receipt when it arrives, without leaving the screen.
A printable running account for one customer: opening balance, every invoice, credit note and receipt in date order, closing balance. This is the sheet you attach to a reminder email or hand to a corporate account at month end.
Rank every customer by what they actually bought over a date range. For catering and corporate accounts it usually shows that a handful of names carry most of the revenue — and which of them stopped ordering last month.
Which dishes and which stock items are moving, by quantity and by value. The menu-engineering view: what sells, what does not, and what you keep buying in for a dish nobody orders.
Sales value less the costed consumption, item by item. A dish can be your best seller and your worst earner at the same time, and this is the screen that tells you which one it is before you reprint the menu.
Revenue less cost of goods sold for each customer, so a discounted contract can be judged on what it leaves behind rather than on the size of the invoice. Useful before a renewal conversation.
Built for ZATCA Phase 2. The module generates UBL 2.1 XML, assigns the invoice counter value, maintains the PIH hash chain and produces the Base64 TLV QR payload for tags 1–5. Chain integrity is re-verified on every read, and documents are flagged unsigned until a real CSID is onboarded.
The mirror of the sales pipeline, running the other way: order, goods receipt, vendor bill — or a direct bill when the van turns up without warning. Nine screens in total.
Put the commitment in writing: item, quantity, agreed price, expected date. The order then flows into a goods receipt and a vendor bill, which is what lets you argue about a price three weeks later and win.
The same split view as sales tracking, from the buying side: receipt and bill status per order, both shown as Pending, Partial or Complete. See at a glance which suppliers are behind on delivery and which goods have arrived but not yet been billed, with the same period, status and party filters and PDF/Excel export.
Book in what actually arrived, which is rarely exactly what was ordered. The receipt is what increases stock and creates the cost layer that FIFO or weighted-average costing will later draw down.
The supplier's invoice, matched against the receipt. Bills carry the input VAT and drive the payables balance, so nothing gets paid out of an account that was never billed in the first place.
Short delivery, damaged crate, or a price you never agreed — raise a debit note against the bill. What you owe the supplier comes down and the original document stays exactly where it was.
Everything you owe, aged the same way receivables are. Sort by due date before a payment run so a critical supplier is not left waiting while a small bill gets settled early out of habit.
One supplier's full account in date order: bills, debit notes, payments and the running balance. The sheet to hold next to the statement they send you when the two of you disagree by SAR 1,200.
Spend by supplier over any period. It is normally the fastest way to discover that three names out of twenty take most of the money, which is where negotiating time is best spent.
What you bought, how much of it, and at what average price. Watch a single ingredient drift upward across the months and act on it before it quietly removes a point of gross margin.
Five screens for the movement of actual money — deposits, transfers, receipts, payments and the overheads that never go anywhere near a purchase order.
Cash boxes and bank accounts in one place: deposits, internal transfers between accounts, customer receipts and vendor payments. Each movement posts to the ledger as it is entered, so the balance shown in the app is the balance you reconcile against the statement.
Rent, electricity, gas, municipality licences, repairs, delivery-app commission — the everyday spending that never passes through a purchase order. Code it to the right expense account once and the reports stay meaningful.
Expenses grouped by account and period, so you can see where the overhead really went rather than guessing. This is the screen to open when the gross margin looks healthy but the bank account does not.
Money in and money out across every cash and bank account, on one timeline. The place to look when the takings are right and the payments are right but the closing balance still is not.
Each individual payment to a supplier and each receipt from a customer, matched to the bill or invoice it settles. The outstanding balance moves the moment the money does, not at the end of the month.
Payroll sits inside the same ledger as everything else, so the wage bill lands in the profit and loss on the day you run it rather than when someone remembers to type it in.
Staff records, salary expense, advances taken against wages and the salary payment itself. Run the month, post the expense, pay it from the cash or bank account it really came out of, and keep every advance tracked against the person who took it until it is cleared.
Five screens covering the item master, the movement history, per-location balances and the transfers between sites. Nothing changes a quantity without leaving a record of what changed it.
The item master: dishes, ingredients, packaging and resale goods, each with the cost it carries and the price it sells at. Sales, purchases, recipes and the POS terminal all read from this one list, so a price change happens in a single place.
The complete movement history for any item — receipts, deliveries, transfers, production and consumption in date order. When a quantity looks wrong, this screen shows precisely which document made it wrong and when.
On-hand quantity and value for every location this database holds, side by side — main store, kitchen, cold room, a second site. When something runs low, you can see at a glance which location still holds it.
Move stock between warehouses, branches or storage locations with a document behind it. Transfers deliberately post no journal entry — the value has not left the business, it has only changed shelf.
Define the sites, branches and storage locations you genuinely use: main store, kitchen, cold room, second branch. Stock is always held against one of them and never floats around unassigned.
A kitchen is a small factory. Two screens turn ingredients into finished items and keep the plate cost honest as supplier prices move. Off by default for the Restaurant setup — switch the business nature in Setup to turn it on for a commissary kitchen producing across branches, or any operation that needs a bill of materials.
The recipe behind each dish or sub-assembly: which ingredients, how much of each, and therefore what the finished item costs to make. When a supplier price changes, the plate cost follows it, which is the difference between a priced menu and a hopeful one.
Turn raw items into finished ones — a batch of sauce, a tray of pastry, a prepped component for tomorrow's service. Raw stock is consumed and the finished item is received in a single transaction that either completes in full or leaves your stock untouched.
Ovens, fit-out, furniture, the delivery van and the POS hardware belong on the balance sheet, not in this month's expenses.
Capitalise an asset with its cost, date and useful life, then depreciate it on a straight line for as long as you keep it. The register handles the disposal when the asset is sold or scrapped, and will not let the same period be depreciated a second time.
Two screens for the part of the business that has to work in the middle of Friday service: fast counter selling, and dine-in service with an open order on every table.
The floor plan shows which tables are free, which are running an open order and how much each of them is carrying, so the front of house can answer a question without walking over to look.
Fast counter selling: find the item, tap it, take the payment, print the ticket. Prices are entered the way they appear on the menu — VAT-inclusive — and the tax is extracted from the ticket rather than added on top, so what the customer is quoted is what the customer pays.
The dine-in view. Every table carries its own order, items go on as they are ordered, and the bill is settled through the POS at the end of the meal. Reprinting a kitchen ticket gives you the paper again without firing the order a second time.
A shift is a session: it opens with a counted float, collects every sale rung on that terminal, and closes only when the drawer has been counted and a supervisor has signed the count off.
A cashier opens a session on a terminal by counting the float into the drawer. From that moment every POS sale is tied to the open session, so the shift’s takings are a fact recorded as they happen — not a spreadsheet reconstructed at midnight.
Cash taken out mid-shift — the urgent gas cylinder, the produce run — is recorded as a payout against the session, with a reason. The expected cash at close already knows about it, so a legitimate payout never reads as a short drawer.
At close the application computes the expected cash — float plus cash sales minus payouts — and the cashier enters what was actually counted. The difference is shown as over or short before anything is submitted, alongside the card and bank takings for the shift.
A submitted close waits for a supervisor, who approves or rejects it — and a cashier cannot approve their own count. On approval, any difference posts to the ledger as a Cash Over/Short journal entry, so the books say what the drawer said.
The sessions list gives a supervisor the whole picture — filter by date, terminal, cashier or status — and every session carries session-wise sales and collection reports, so “how did the evening shift do” is a click, not an investigation. Every open, payout, close and decision lands on the session’s event log, which is append-only.
Four screens where the documents from every other module arrive as double-entry postings, and where your accountant will spend most of their time.
Every document in the application lands here as a balanced double-entry posting, alongside any manual journals you need to write yourself. An entry whose debits do not equal its credits, or a line coded to an account that does not exist, is rejected rather than saved.
The account structure — assets, liabilities, equity, income and expenses — seeded when you install and extendable to match how you already report to the owner or the bank. Each account carries its own ledger and its own running balance.
Set a budget per account and per period, then watch budget against actual as each month closes, with projections for how the rest of the year lands if nothing changes. Useful for arguing with yourself about a second branch before signing the lease.
Profit and loss, account balances and inventory valuation over whatever date range you choose. These are the same reports the automated suite re-checks on every build, and the test suites finish by proving the trial balance and balance sheet still balance.
Tag postings to a branch, a kitchen, a department — then read profit and loss for each one separately, instead of one blended number for the whole company.
Cost centres nest — a branch above its kitchen and its delivery counter — and reports can roll a parent up from its children. A centre cannot be made its own ancestor, and one that already carries postings is deactivated rather than deleted, so history stays readable.
Pick the cost centre on the document and it rides the posting into the ledger — a sale order’s cost centre carries through to the invoice raised against it. Manual journal lines can be tagged line by line, so one entry can split rent across branches.
A movement ledger per centre, and a profit-and-loss report with one column per cost centre — plus an Unallocated column that is always shown, so postings nobody tagged are visible in their own column rather than quietly missing from everyone’s.
Set a budget per account, per centre, per period, then read budget against actual with a signed variance — so the downtown branch overspending on produce shows up as that branch’s number, in that month, not as a company-wide shrug.
Design the approval chain your company actually uses — who reviews, who authorises, at what amounts — and gated documents stay drafts until the final approval, when they post to the ledger.
Any number of levels, each a named action — Reviewed By, Finance Approval, whatever your company calls it — assigned to specific users and/or whole roles. Amount bands route documents, so a small expense takes the short path and a large one takes the long one.
A journal entry or expense caught by a workflow exists only as a draft — readable by every reviewer, posted by none of them. The final approval executes the posting and records the posted document’s id on the approval, so the trail and the ledger point at each other.
Levels run in sequence: nobody at level two can act before level one has. Consecutive levels marked parallel form one stage — finance and compliance can review in either order, but both must sign before the chain moves on. The chain is frozen when a document is submitted; editing the workflow later never changes documents already in flight.
Rejecting or returning a document requires a written reason. A returned document goes back to its preparer — only the preparer can correct and resubmit it, and resubmission restarts the chain from the top. Every action lands on an append-only trail: level, user, time, comment and the status change, never edited, never removed.
Reviewers work from an approvals inbox whose “my queue” tab shows exactly the documents waiting on them — and only those — with the draft, the chain and the full trail in one dialog. A bell in the top bar carries the pending count everywhere in the application.
The produce supplier who also runs a staff canteen account. The sister company you both buy from and sell to. One trading partner, two ledgers — and one statement.
Link a customer to their vendor record once, in Customers & Vendors. From then on both records know they are the same business, and the combined statement can be pulled from either side.
Your invoices to them and their bills to you, your receipts and your payments, interleaved in date order with a single running balance. Both sides read the same way — and the closing figure is the net position: what they owe you minus what you owe them, which is the number the settlement conversation actually needs.
Projects & Contracts appears only when the company's nature is set to Contracting — a restaurant never sees it, because the sidebar only shows the modules your business actually uses. The approvals inbox itself is available to every business nature.
Track cost and revenue against a contract and recognise revenue under IFRS 15 on percentage of completion, with progress billing as the work advances. SAR 200,000 of cost incurred against an SAR 800,000 contract recognises the project as 25 per cent complete.
Everything waiting on somebody's decision, in one queue rather than in one manager's memory. Approve it or send it back, and the document carries on through its flow with the decision recorded against it.
Trading partners, approval chains and company configuration. What you choose here decides how the rest of the application costs your stock, who signs off on what, and which modules appear in the sidebar.
One record for each trading partner, with contact details, VAT number and the running balance you have with them. The same list feeds sales, purchases, statements, aging and the buyer details on an e-invoice, so a corrected VAT number is corrected everywhere at once.
The builder for the chains themselves: any number of levels, each assigned to named users or whole roles, with amount bands so a small document takes the short path and consecutive levels marked parallel where two reviewers sign side by side. What a chain does once a document is inside it is described under approval workflow.
Company details and the costing method — FIFO or weighted average — plus the business nature that decides which modules the sidebar shows. Set it when you install and the application shapes itself around the business you actually run.
These are not settings or intentions. Each one is asserted by the automated test suite that runs against every build.
Every document posts a balanced journal entry. Revenue and cost of goods sold post as two entries rather than one, so the two can be read and corrected independently.
Both costing methods are supported and the choice is yours, made once in Settings. Cost layers are created by goods receipts and drawn down in the order the chosen method dictates.
VAT is extracted from the ticket price rather than added on top of it. A gross ticket of 46.00 at 15 per cent is a net 40.00 — the number on the menu is the number the guest pays.
In the order flow it is the delivery that records COGS, and only the delivery. Invoicing the same goods afterwards does not book the cost a second time.
A posted journal entry can no longer be changed in place. A correction posts a reversal and the original stays visible, so the history of the ledger cannot be rewritten after the fact.
If debits do not equal credits, or a line points at an account that does not exist, the posting is refused outright rather than left for you to find later.
A production run or a delivery consumes everything it needs or nothing at all. A failure part-way through leaves no half-mutated stock behind to reconcile by hand.
A stock transfer between warehouses posts no journal entry, by design. The goods have changed location; the business is neither richer nor poorer for it.
Fixed assets are written down on a straight line, and the register refuses a second depreciation run for a period it has already posted.
Project revenue is recognised on percentage of completion. SAR 200,000 of cost against an SAR 800,000 contract recognises 25 per cent, and progress billing follows the same measure.
Much of it is covered by the automated test suite — the cost-centre and combined-statement math, the FIFO/weighted-average costing, the approval and POS-session engines and the batch/lot expiry logic are all checked against worked examples before a release ships, alongside 49 tests covering persistence, the Electron-adaptation layer and licensing.
The company's nature, chosen in Settings, decides which modules appear in the sidebar. A services company is not asked to manage warehouses; a contracting company gets projects and progress billing instead of a floor plan.
| Nature | Inventory | Manufacturing | POS | Tables | Projects |
|---|---|---|---|---|---|
| Restaurant | ✓ Included | Not included | ✓ Included | ✓ Included | Not included |
| Trading | ✓ Included | Not included | ✓ Included | Not included | Not included |
| Trading & Manufacturing | ✓ Included | ✓ Included | ✓ Included | Not included | Not included |
| Trading & Services | ✓ Included | Not included | ✓ Included | Not included | Not included |
| Manufacturing | ✓ Included | ✓ Included | Not included | Not included | Not included |
| Contracting | ✓ Included | Not included | Not included | Not included | ✓ Included |
| Services | Not included | Not included | Not included | Not included | Not included |
Meezan ERP POS installs on Windows, macOS and Linux, keeps its database on your disk, and works with the internet unplugged. Download it, or let us walk you through the modules that matter to your business.
