One company, branches in Dubai, Riyadh and Kuwait: running multi-country books in the GCC

The shape of the problem

A group with an outlet in Dubai, a trading arm in Riyadh and a branch in Kuwait City is not three businesses in the eyes of its owner. It is one business whose numbers must add up. But the three sit in three different tax positions and three different currencies, and most software forces a choice between two bad answers: one workspace per country, which means consolidating by spreadsheet, or one workspace with a “region” setting that quietly changes behaviour for everyone.

The workable answer is a platform where the country-specific parts are configuration and the shared parts — chart of accounts, clients, products, financial year — are genuinely shared.

Three tax positions, one tax engine

As of September 2026, the three states differ as follows.

Country defaults should ship out of the box — UAE VAT at 5% and 0% with the registration label “TRN”, Saudi VAT at 15% and 0%, a Kuwait profile with no rate because none is in force — and then be yours to change. That last part matters more than the defaults, because rates in this region are not permanent. Bahrain and Oman also sit in the same group at 10% and 5%; if you expand, adding a branch should be a configuration exercise, not a second system.

Whatever the rate, the behaviour underneath must be identical: every sale, purchase, expense and POS settlement posts a balanced double-entry voucher with the tax split to its own ledger, and tax summary reports read from those postings. That is what makes a group consolidation meaningful — three branches on three rates, one method.

Inclusive and exclusive pricing needs to work per branch too. A Dubai shop shows shelf prices including VAT; the Riyadh trading arm quotes exclusive; the Kuwait branch shows a price with no tax component at all. Same catalogue, different presentation.

Currencies, and one base to read in

Three currencies means exchange rates are not an occasional inconvenience but everyday data. A foreign-currency transaction should carry its rate into the books at the moment it is posted, so that the group’s reports read in a single base currency without anyone re-valuing anything by hand.

Two details that catch people out. First, the Kuwaiti dinar has three decimal places — as do the Bahraini dinar and the Omani rial — so put a three-decimal amount through any vendor’s documents, receipts and ledger, ours included, and check the three agree before you buy. Second, group reporting and branch reporting are different questions: the Riyadh manager wants his numbers in riyals, the owner wants the group in one currency, and both should be available from the same postings rather than from two sets of books.

Access that is scoped, not filtered

The rule to insist on: branch scoping is enforced by the platform itself. A staff member in Kuwait should be unable to retrieve a Riyadh invoice, not merely unlikely to see it because a filter defaults that way. A filter is a convenience; scoping is a boundary, and only one of them survives a curious user or an exported report.

In practice that means every record carries its branch, staff are assigned the branches they may work in, and ownership and finance are scoped across all of them. It also means reports come in two shapes — per branch and consolidated — from the same data. See reports for what that looks like in use.

Documents that look local

Each branch has its own trade licence details, its own address, and often its own logo treatment. Document templates should carry branding per branch so a Riyadh invoice is unmistakably from the Riyadh entity, while remaining the same template family across all 24 printable document types — no maintaining three parallel sets that drift apart.

In all three countries, paired Arabic and English labels on one page is the right default: the customer reads one half, the accountant the other, and there is only one document to file. The bilingual documents guide has the full test.

One financial year, one lock

A configurable financial year with lock dates on closed periods keeps a corrected entry from landing in a quarter already reported — across every branch at once. Where local statutory reporting needs a different treatment, that is a question for your accountant rather than a reason to split the platform.

What stays country-specific

Filing formats and e-invoicing mandates differ by country and are changing across the region right now: the UAE has a phased Accredited Service Provider model running to 2027, Saudi Arabia has ZATCA Phase 2 waves already live, and Kuwait has no VAT at all. No platform should be assumed to cover any of it. Ask every vendor for their integration status in writing — including ours; Flowyana claims no e-invoicing clearance integration, ASP accreditation or ZATCA certification — and let your accountant confirm your obligations. See the UAE and ZATCA Phase 2 guides for the questions to ask.

A demo you can run in twenty minutes

1. Create three branches. Give one 5% VAT, one 15%, one none.
2. Sell the same product from each. Open all three vouchers and compare the tax splits.
3. Sign in as Kuwait staff. Try to open a Riyadh invoice.
4. Buy in US dollars from the Dubai branch. Show the posting in the group base currency.
5. Print an invoice from each branch and check the branding and the paired Arabic–English labels.
6. Read the P&L per branch, then consolidated. Lock last quarter and try to post into it.

To try that with your own branches and rates, book a demo.