POS System in Lebanon — Dual-Currency, Bilingual, Built for the Way Shops Actually Trade

VAT at 11%, on a base that moves

1. In force

   Value-added tax applies at 11%.

2. 2026

   No mandatory e-invoicing framework.

Lebanon applies value-added tax at 11%, administered by the Ministry of Finance. The rate is the easy half of the question. The hard half is the base: VAT here is applied on a pound amount whose relationship to the dollar has moved repeatedly, and the treatment of a dollar-denominated sale is the thing to verify rather than assume. Confirm current treatment, your registration threshold, and your filing frequency with the Ministry of Finance at finance.gov.lb before you make decisions on it. A software vendor is not a tax adviser, and that includes us — on this market more than most.

What the system does about it, concretely:

What the system does about a moving base

• The rate is a configuration value, not a hardcoded assumption baked into the receipt renderer. It is set on the tax profile. That is what makes a rate change an edit rather than a release.
• The tax registration number field exists on the merchant profile and prints in the receipt header when populated.
• Line-level breakdown prints in Arabic and English, so a receipt shows net, tax, and gross per line rather than a single tax figure at the foot.
• Reports separate net, tax, and gross, per branch, which is the shape an accountant wants and the shape a filing needs.
• Tax is computed against the sale as recorded, with the booking rate frozen on the transaction — so a report run three months later reproduces the same figures rather than re-translating history at a newer rate. On this market that property is the difference between books that reconcile and books that argue with themselves.
• Zero-rated and exempt items are handled as their own treatment, not as a 0% hack on a standard-rated product — the distinction matters on a return.

E-invoicing in Lebanon, as of 2026

On e-invoicing: there is no mandatory framework in Lebanon as of 2026. That means the receipt and the report are the record, which raises rather than lowers the bar on getting them right the first time — there is no downstream government system that will catch a mistake for you.

What we do not do: file on your behalf, generate a submission document, or connect to a government portal.

What POS software actually costs in Lebanon

Software priced in dollars is not unusual here; software with a published dollar price is. The local vendor pages quote on request, and in a market where the same product has been sold at very different numbers to different buyers, that opacity is not accidental. So, plainly: Sandooq is 29 US dollars per month for a single store, and 79 for up to 5 stores. Billed annually those become 24 and 66. That is the whole price.

What a published dollar price includes

Larger chains are quoted individually. Three things are worth saying out loud about that price.

• It is the same number everywhere. A shop in Hamra pays what a shop anywhere else pays. There is no Lebanon rate, up or down, and nothing about the figure depends on who is asking or how the conversation went.
• What is included is the whole back office, not a starter tier that upsells: inventory with stock counts and transfers between branches, purchasing and supplier orders, customer accounts and on-account balances, staff permissions per branch, and the sales and closing reports your accountant needs. The plan boundary is scale — stores, staff, products — not features you discover are missing in month two.
• Hardware is yours, not ours. Sandooq runs in the browser on tablets and standard computers, works with commodity ESC/POS receipt printers and USB or Bluetooth barcode scanners, and does not require a proprietary terminal. That matters more here than elsewhere: importing a proprietary terminal is expensive, replacing one is worse, and a system that ties you to specific hardware ties you to whoever can still supply it. Confirm your specific models during setup rather than taking a compatibility promise on trust.

Two currencies at one counter

This is the section that decides whether a POS system is usable in Lebanon at all, and it is where most of them fail — not by refusing to handle two currencies, but by handling them as a display conversion rather than as two real tenders.

How the counter handles two currencies

• Prices in either currency, tenders in both. A product can be priced in pounds or in dollars. A single sale can be settled partly in pounds and partly in dollars, and the receipt shows what was actually handed over in each rather than a single translated total. Both halves belong to the same sale, so the sale is one record rather than two.
• Separate drawers, separate reconciliation. Cash in pounds and cash in dollars are counted and reconciled independently at end of day. That is the practical requirement — a cashier closing a shift needs to know that the pound drawer balances and the dollar drawer balances, not that some blended figure looks approximately right.
• One rate, set by you, frozen on the sale. The owner sets the pound-to-dollar rate in the dashboard. Change it once and it applies across every store, every terminal, and every receipt from that point on. Each transaction stores the rate that was in force when it was rung, so a report run months later reproduces the sale as it happened instead of re-translating it at a newer number.
• Being explicit about what that is not: there is no rate feed, no connection to your bank, and no automatic tracking of any published rate. The number is yours and updating it is your job. We would rather say that plainly than let "multi-currency" imply a data source we do not have — and you should ask any vendor claiming automatic rates exactly where the number comes from and what happens on the day the source stops publishing.
• On margin reporting, the consequence of frozen booking rates is the useful one: cost and revenue are compared using the rate that applied at the time, so margin figures do not silently rewrite themselves when the rate moves. Reports can be read in either currency.

Power cuts, thin connectivity, and what actually keeps selling

Lebanese retail runs on generator schedules and a network that follows them. This is the operating reality every local vendor page mentions, so the useful thing this page can add is not that we know about it — it is precision about which parts of the system survive it.

What keeps selling on a generator schedule

• What keeps working without a connection. The checkout loop: building a cart, attaching a customer, and taking a cash sale, in either currency. Those are captured on the terminal and queued locally. When the connection returns the queue replays in order, with deduplication on the server, so queued sales aren't lost and nothing gets double-counted from a retry.
• What needs the network. Signing in, manager and device PIN checks, opening and closing a cash session, looking up an earlier receipt, voids, exchanges, and card payments. These are online-only by design — each one either moves money through a third party or changes control state the server has to arbitrate between terminals.
• The practical shape of that, for a shop working around a cut: open the cash session while the connection is up, at the start of the day rather than opportunistically, because opening it is one of the online-only operations. A drop mid-shift does not stop cash checkout. Reloading the browser tab while offline will sign the cashier out, so don't — this is the single most common way to turn a survivable outage into a stopped counter. Take card payments and process returns once the connection is back.

On bilingual operation, Arabic is the primary interface and English is the fallback, switchable per session without restarting. Receipts print in Arabic, English, or both, which covers a counter serving Lebanese, Syrian, and visiting customers in the same hour. A layout that reads right to left is the default the product was built around, not a mirrored afterthought.