Open-source restaurant POS
Restaurant POS software with KOT and table orders
Evaluate the ordering path, kitchen handoff, reports, offline behavior and recovery plan before choosing a till for a cafe or restaurant.
What the stable source establishes
This page was reviewed against the published v1.3.0 source at commit b531ef4308c4dc3a25f250551a54fc5616e3b8d9.
KOT
The user guide documents kitchen order tickets sent to a kitchen printer as orders are taken, before settlement.
Easy Table
The documented table workflow keeps an order open while a party continues ordering and associates the order with its table.
KOT reporting
The pinned interface contains six views: sales summary, item-wise, discount, cancellation, open item and table-wise.
A focused rerun on 18 August 2026 passed 221 API unit tests across Easy Table controllers and models, sale service behavior and route controls, plus 37 desktop tests covering receipt output, the protected KOT print window, public-route boundaries, local assets and sales call paths. These are code-path checks, not a completed service or physical kitchen acceptance.
Restaurant reports: the question each view should answer
The exact Windows v1.3.0 portable artifact was relaunched on 17 August 2026 with the same disposable profile used for the offline-sale test. Its graphical sales report rendered the stored synthetic sale as ₹125 sale, ₹125 average sale and ₹50 gross profit. This checks one general report view; it does not prove every filter, export or KOT report.
Do not evaluate reports by their names
Enter a small known dataset, run each service scenario, and compare the report with the tickets and payments that created it. A report is useful only when staff know which operational question it answers and can reconcile the total.
Run the outage drill after the normal-day report checks pass.
| View | Operational question | Trial assertion |
|---|---|---|
| Sales summary | How many KOT sales, guests and tender amounts were recorded for the selected period? | Known checks, guest count and tender total agree with the test shift. |
| Item-wise | Which menu items moved, and in what quantity? | One item added, removed and repeated appears with the expected net quantity. |
| Discount | Which orders or items received a discount? | Manager-approved and unapproved scenarios remain distinguishable. |
| Cancellation | What was cancelled, when and by whom? | A test cancellation remains traceable instead of disappearing from the operating record. |
| Open item | Which ad hoc or open-price items entered orders? | Description, price and approval practice are visible enough for review. |
| Table-wise | Which tables produced orders and totals? | Transfers, table reuse and closing sequence do not duplicate or strand an order. |
Built-in reporting is not the same as menu engineering
What menu engineering needs
Cornell hospitality research describes the classic method as comparing each menu item's sales volume with its contribution margin, meaning selling price less food cost. That requires trustworthy quantity and recipe-cost inputs.
Posnic v1.3.0 boundary
The stable documentation does not claim recipe-level ingredient depletion or a built-in popularity-versus-contribution-margin matrix. Export verified item sales and combine them with a separately maintained recipe and food-cost source when that analysis is required.
Offline billing still has connected dependencies
A reproduced Windows v1.3.0 run completed and reopened a local cash sale while external hosts were blocked inside Electron. That proves a local sales path under the disclosed condition, not every restaurant dependency.
Local till
Test restart, login, table opening, KOT, settlement, stored-order lookup and closing reports with external access unavailable.
Kitchen path
Keep the till, router and printer powered; print a real ticket at every preparation station and verify routing, modifiers and reprints.
Payments
Card, wallet and QR providers have independent network rules. Document each approved fallback instead of assuming the POS makes a provider offline.
Run a restaurant trial before opening
- Create every service type the restaurant will use: dine-in, takeaway, delivery or counter sale.
- Build a representative menu with variants, taxes, modifiers or open items that reflect the real operation.
- Open two tables, add later rounds, move through the intended kitchen handoff and settle with each payment method.
- Void one item, cancel one order, apply one approved discount and confirm each action appears in the expected report.
- Print KOT and customer receipts on the exact printer model, width, driver, cable and network used at service.
- Reconcile item quantities, guest count, table totals, tax, tenders, cancellations and open orders.
- Disconnect external access and repeat the approved offline scenario.
- Create a backup and prove a restore in a disposable environment before relying on the till.
Fit and non-fit checklist
Worth a controlled trial when
You need inspectable open-source software, a local database, KOT and table-order paths, standard sales and stock records, and optional cloud services rather than a mandatory subscription.
Validate or choose another system when
You require certified payment-terminal integration, proven recipe depletion, native reservation aggregation, delivery-marketplace integrations, named hardware certification or a contracted regional compliance guarantee that Posnic has not documented.
Run an 18-record restaurant test shift
Use one known menu and table plan to follow the order from entry to kitchen handoff, payment, reports and restore. Record the exact counter, printer, route, provider and observation; a blank worksheet is not a Posnic pass.
The worksheet separates service scope, menu and roles from the observed transaction. It includes later rounds, kitchen routing, modifiers, cancellation, failed payment, open-order review, closing reconciliation, outage, backup and clean-device restore.
Primary sources used
Posnic v1.3.0 release
The stable release fixes the product, build and download boundary used in this review.
Pinned restaurant guide
The versioned guide documents KOT printing and Easy Table open-order tracking.
Pinned KOT reports
The stable interface identifies the six KOT report views discussed on this page.
PCI SSC FAQ 1300
Current primary guidance places payment terminals in the cardholder-data environment and requires applicable device controls.
NIST SP 800-34 Rev. 1
Primary contingency-planning guidance supports explicit recovery requirements, strategies, tests and maintenance.
Cornell research record
The research record distinguishes menu and revenue analysis inputs from a POS report name. Posnic does not claim built-in recipe costing.
Free local edition, optional cloud
The local desktop application is published under AGPL-3.0 with no trial clock. Cloud sync, managed off-site backup and remote dashboards are separate optional services.
Restaurant POS questions
Does Posnic include kitchen order tickets and table orders?
The pinned v1.3.0 guide documents KOT and Easy Table. Those source paths were reviewed for this page, but a full restaurant shift and physical kitchen printer were not exercised in the runtime evidence run.
Which restaurant reports are visible?
The pinned KOT report interface contains sales-summary, item-wise, discount, cancellation, open-item and table-wise views. Populate known test orders and reconcile every view before rollout.
Does Posnic include recipe-level menu engineering?
The stable documentation does not claim recipe-level depletion or a built-in menu-engineering matrix. Combine verified item sales with separately maintained food-cost data when contribution-margin analysis is required.
Can restaurant billing continue without internet?
A Windows v1.3.0 local cash sale was reproduced under Electron external-host isolation. Payment providers, cloud services, kitchen printers and the local network need their own outage drill.