Running One Restaurant POS Across Multiple GCC Countries: Multi-Currency, Multi-VAT, One Set of Books
For restaurant groups and franchisees opening a second country · 9 min read
A multi country restaurant POS is what you need the day your second branch opens across a border. The moment a Kuwait brand signs a lease in Manama or Doha, three things stop being the same: the currency the till rings in, the tax printed on the receipt, and the card network the guest taps. Most operators solve this by buying a second POS in the second country — and then spend every month-end stitching two exports together in a spreadsheet. This guide shows the alternative: one restaurant system where each branch runs in its own currency and tax regime, accepts its own local tenders, and still rolls up into one profit-and-loss in your group currency. It covers what actually changes at each GCC and Iraq border in 2026, the three configuration decisions that make a single system work, and a numbered example of a Kuwaiti group running branches in Bahrain and Qatar — with every conversion shown.
- The GCC and Iraq use seven currencies — KWD, IQD, QAR, BHD, OMR, SAR and AED — and five of the six GCC currencies are pegged to the US dollar (SAR 3.75, AED 3.6725, QAR 3.64, BHD 0.376, OMR 0.3845 per USD); the Kuwaiti dinar is pegged to an undisclosed basket and trades near KWD 0.307 per USD, while Iraq's 2026 budget rate is IQD 1,300 per USD.
- VAT differs at every border: 15% in Saudi Arabia, 10% in Bahrain, 5% in the UAE and Oman, and no VAT in Kuwait, Qatar or Iraq as of September 2026 — Kuwait's four-year plan rules VAT out before 2028, and Qatar approved a draft e-invoicing law in May 2026 that is widely read as a precursor.
- E-invoicing is arriving in waves: Saudi Arabia's ZATCA Phase 2 already covers VAT-registered businesses above SAR 375,000 turnover; the UAE opened a voluntary pilot on 1 July 2026 with mandatory adoption from 1 January 2027 (AED 50 million+) and 1 July 2027 for the rest; Oman's Fawtara reaches all VAT-registered businesses on 1 October 2027; Bahrain is preparing a phased mandate but has published no platform yet.
- The GCC foodservice market is estimated at about USD 69 billion in 2026 and forecast to reach roughly USD 122 billion by 2031 (around 12% a year), with chained outlets holding about 60% of the market — cross-border expansion is now the normal growth path, not the exception.
- One system can do it if it separates three things per branch: the currency and tax the till rings in, the tenders and bank accounts it settles to, and the company the books post to — then converts everything into one reporting currency at a maintained exchange rate.
Why one system, not one per country
Cross-border growth is the default in Gulf foodservice now: market researchers put the GCC market at about USD 69 billion in 2026, growing around 12% a year toward USD 122 billion by 2031, with chained brands holding roughly 60% of it. The problem is that a brand's second country usually arrives with a second POS — often a local product chosen because it 'does VAT' or 'takes BENEFIT'. Six months later the owner has two menus that drift apart, two recipe databases, two loyalty lists, and a finance team that converts foreign sales by hand into the home currency at whatever rate was in the spreadsheet last month. Consolidated food cost becomes an estimate, and the question 'which branch is actually the most profitable?' cannot be answered with confidence. The fix is not a bigger spreadsheet; it is a POS whose accounting backend already understands multiple companies, currencies and tax templates — which is exactly what an ERP-based restaurant system provides.
What changes at every border in 2026
Before configuring anything, be precise about what is different in each market. Rates and dates move, so treat this table as a September 2026 snapshot and re-verify when you sign a lease:
| Market | Currency (per USD) | VAT on meals | E-invoicing status | Local card / wallet rail |
|---|---|---|---|---|
| Kuwait | KWD ~0.307 (basket peg) | None (ruled out before 2028) | None | KNET |
| Iraq | IQD 1,300 (2026 budget rate) | None | None | Cash; Qi Card, Zain Cash, FastPay |
| Qatar | QAR 3.64 | None (draft e-invoicing law May 2026) | Law approved, not yet in force | Himyan / NAPS |
| Bahrain | BHD 0.376 | 10% | Phased mandate in preparation, no platform yet | BENEFIT |
| Oman | OMR 0.3845 | 5% | Fawtara: 1 Apr 2027 (>OMR 5M) / 1 Oct 2027 (all) | OmanNet / Maal |
| Saudi Arabia | SAR 3.75 | 15% | ZATCA Phase 2 live (waves by turnover) | mada |
| UAE | AED 3.6725 | 5% | Pilot 1 Jul 2026; mandatory 1 Jan 2027 / 1 Jul 2027 | Cards, wallets |
Three of these columns — currency, VAT and tender — must be set per branch, never globally. The fourth, e-invoicing, is the reason the branch's invoices should live in a real accounting ledger from day one: every mandate in the region is a connector on top of an existing invoice record, not a new till.
Three decisions that make a single POS work across countries
1 — One profile per branch, carrying its own currency, tax and price list
The unit of configuration should be the branch, not the installation. Each branch needs its own selling currency, its own tax template (10% inclusive in Manama, none in Doha), its own price list — because a shawarma is not priced by converting KWD 1.500 into riyals — and its own warehouse so cashiers only see their store's stock. In Culina this is the Culina Profile: each profile carries a company, warehouse, price list, currency, a Sales Taxes and Charges Template with a tax-inclusive flag, and the list of users allowed to open it. The invoice is created in the profile's currency and the General Ledger is posted in the company's currency at the active Currency Exchange rate. There is deliberately no currency picker at checkout — the Bahrain cashier always rings in dinars, the Doha cashier always in riyals — which removes the single most common source of cross-border posting errors.
2 — Local tenders per country, each posting to its own account
KNET in Kuwait, BENEFIT in Bahrain, Himyan in Qatar, Qi Card and Zain Cash in Iraq: the guest's tap is different in every market, and so is the acquirer that settles it. Set every tender up as its own mode of payment with a default account per company, so a BENEFIT settlement in Bahrain reconciles against a Bahraini bank account and never mixes with KNET receipts in Kuwait. In Culina every tender is an ERPNext Mode of Payment with an account row per company; taking a payment posts a Payment Entry that debits exactly that account, and each cashier shift closes with expected-versus-counted per tender on the Z-report — so a mismatch in Manama is caught in Manama, that evening.
3 — One group currency for reporting, at a maintained rate
Once every branch posts to its own company in its own currency, group reporting is a consolidation, not a re-keying exercise. ERPNext, the accounting backend underneath Culina, supports multiple companies under a parent and produces consolidated financial statements — profit and loss, balance sheet and cash flow — converting each subsidiary into the parent's currency. The one operational discipline this demands is keeping the Currency Exchange record current: if a branch sells in a currency other than its company's, posting will fail or use a stale rate, so the exchange record needs an owner and a schedule. With dollar-pegged currencies this is easy — the BHD/KWD and QAR/KWD crosses barely move — but it still has to be entered.
Because recipes and depletion run per branch, the Menu Engineering report and branch P&L show real ingredient cost in each local currency, and the consolidated view converts them — so a food-cost gap in one country stands out against the group instead of hiding inside a blended average.
A worked example: a Kuwaiti group with branches in Bahrain and Qatar
Take a casual-dining brand headquartered in Kuwait — call it Diwan Grill — with one branch in Kuwait City, one in Manama and one in Doha. Group reporting is in Kuwaiti dinars. Using cross rates derived from the dollar pegs (KWD 0.307 per USD; BHD 0.376 per USD; QAR 3.64 per USD), one Bahraini dinar is about KWD 0.8165 and one Qatari riyal about KWD 0.0843. Here is one trading day, then the month:
| Line | Kuwait (KWD) | Bahrain (BHD) | Qatar (QAR) |
|---|---|---|---|
| Orders per day | 150 | 120 | 140 |
| Average ticket (as printed) | 4.500 | 5.500 (10% VAT-inclusive) | 55.00 |
| Daily gross sales | 675.000 | 660.000 | 7,700.00 |
| Net of VAT | 675.000 | 600.000 (660.000 ÷ 1.10) | 7,700.00 |
| VAT collected per day | 0 | 60.000 | 0 |
| Exchange rate to KWD | 1 | 0.8165 | 0.0843 |
| Daily net in KWD | 675.000 | 489.900 | 649.110 |
| Food cost % (recipe-based) | 30% | 34% | 31% |
| Daily food cost (local) | 202.500 | 204.000 | 2,387.00 |
| Daily food cost in KWD | 202.500 | 166.566 | 201.224 |
Consolidated, the group sells KWD 1,814.010 net per day (675.000 + 489.900 + 649.110), or KWD 47,164.260 across a 26-day month. Group food cost is KWD 570.290 per day (202.500 + 166.566 + 201.224), which is 31.4% of net — a number that looks acceptable until the per-branch view shows Bahrain running four points above its 30% target. That gap is BHD 24.000 a day (4% × 600.000), BHD 624.000 a month, or about KWD 509.496 in group terms — invisible in the blended figure, obvious in the branch report. Two compliance lines fall out of the same numbers: the Bahrain branch collects BHD 1,560.000 of VAT a month (BHD 4,680.000 a quarter) and, at BHD 187,200 in annual net supplies, sits well above Bahrain's BHD 37,500 mandatory registration threshold. And one cautionary line: if someone leaves the BHD rate at a round 0.80 instead of 0.8165, the Bahrain branch's monthly net is understated by KWD 257.400 (15,600 × 0.0165) — small per month, but it compounds and it distorts every cross-branch comparison, which is why the exchange record needs an owner.
The bottom line
Running one restaurant POS across multiple GCC countries is a configuration problem, not a software-shopping problem, provided the system separates three things per branch — currency and tax, tenders and accounts, and the company the books post to — and then consolidates at a maintained rate. Culina, a restaurant management system built on ERPNext and used across the GCC and Iraq, treats each branch as a profile with its own currency, tax template, price list, warehouse and users; posts every KNET, BENEFIT, Himyan or wallet tender to its own account; and rolls every company up into one set of consolidated statements — so the second country adds a branch to your reports, not a second system to your month-end.
Opening in a second country? See it configured live
A restaurant POS built on ERPNext — one profile per branch with its own currency, VAT template and price list; KNET, BENEFIT, Himyan, OmanNet, mada and Iraqi wallet tenders each posting to their own account; bilingual Arabic/English receipts; KOT/KDS, floor plan and QR menu; recipe costing with depletion per branch; and consolidated multi-company reporting in your group currency.
Book a demoFrequently asked questions
Can one restaurant POS handle multiple currencies in the GCC?
Yes, if it is built on an accounting backend that supports multiple companies and currencies. In Culina each branch is a profile with its own selling currency; the invoice is created in that currency and posted to the general ledger in the company's currency at the active exchange rate. The cashier never picks a currency at checkout — the branch's currency is fixed by its profile, which prevents mis-posted sales.
How do you handle different VAT rates across GCC countries in one POS?
Assign a tax template per branch, not per system. A Bahrain profile carries a 10% VAT-inclusive template, an Oman profile 5%, a Saudi profile 15%, and Kuwait, Qatar and Iraq profiles carry no VAT. The cart shows the tax line and the receipt prints the breakdown for that branch only, and each country's VAT return is drawn from its own company's ledger.
Do I need a separate company in ERPNext for each country?
In practice, yes — one legal entity per country is normal for licensing, banking and tax registration, and a company per country in ERPNext mirrors that. Each company holds its own chart of accounts, bank and tender accounts and VAT registration, and ERPNext's consolidated financial statements roll the subsidiaries up into the parent's currency for group reporting.
How do I consolidate restaurant sales from different countries into one report?
Post every branch's sales to its own company in its own currency, keep an up-to-date Currency Exchange record for each currency pair, and run the consolidated profit-and-loss in the parent's currency. In the example above, Kuwait, Bahrain and Qatar branches selling KWD 675.000, BHD 600.000 and QAR 7,700 net per day consolidate to KWD 1,814.010 per day at rates of 0.8165 and 0.0843.