The first country is invisible. Everything the system assumes about tax, currency, weekends, addresses, phone numbers and dates was decided by whoever built it, mostly without noticing they were deciding anything at all, because at the time there was only ever one possible answer to each question.
The second country makes every one of those assumptions visible at once, and it does so in places nobody was looking. That is why expansion projects scoped as translation and pricing so reliably run long. The visible work was the interface, which is the part everybody can see and estimate. The actual work was in tax, invoicing, reporting and the data model, none of which appear in a screenshot.
This covers what genuinely varies between markets, what to build once rather than repeatedly, what changes in your data rather than only your settings, and the order to do it in. It is written for the second country specifically, because that is where the capability is actually built.
One system or several
Settle this first, because everything downstream depends on it.
One system with country configuration is the right answer in almost every case.
Separate systems per country feel simpler at the moment of the decision. Each team gets what it wants, nothing existing has to change, and the second market launches faster.
The cost arrives later and does not stop arriving. Every future change has to be made twice, then three times. Within two years the systems have diverged enough that the same feature genuinely has to be built differently in each, because the code underneath is no longer the same code. Reporting across markets becomes an exercise in reconciliation rather than a query.
Separate instances genuinely make sense in three situations. A regulator requires separation. The businesses have genuinely diverged and share little beyond a name. Or one market is being prepared for sale and needs to be separable. Our guide on technical due diligence covers the last of those.
Convenience is not one of the three. Neither is a team preferring to work independently, which is the reason most often given and the one that costs most later.
Selling into a country is not the same as operating in one
Worth separating early, because the two get conflated and they carry very different obligations.
Selling into a market means customers there buy from your existing entity. Depending on the country and what you sell, this can be entirely legitimate without any local presence, and the questions are about tax treatment on cross-border supply, what your invoice must show, and whether any registration threshold applies to you.
Operating in a market means a local entity, a licence, local employment, local banking and a full local tax position.
The system consequences differ considerably. Selling into a market usually means one set of books, one reporting currency and one invoicing entity, with country-specific tax treatment applied per transaction. Operating in a market frequently means a separate legal entity that has to appear on invoices, separate accounts to reconcile, and a question about which entity a given customer belongs to that your data model now has to answer.
So establish which one you are doing before designing anything. A system built on the assumption of one selling entity, which then has to accommodate a second, is a considerably larger change than one where the entity was a field from the beginning.
And the two can be in tension. A business that starts by selling into a market and later establishes an entity there has to migrate existing customers from one entity to the other, which affects historical invoices, reporting continuity and sometimes the contracts themselves. It is manageable, and it is much easier when somebody anticipated it.
The trigger for needing a local entity is a question for a corporate adviser in that country rather than something to infer. Thresholds, sector rules and the nature of what you sell all bear on it, and the answer differs enough across the region that a rule of thumb is not worth having.
Country configuration, which is the whole trick
If there is one structural idea worth taking from this article, it is this.
Country-specific values belong in a table the system reads, not in logic scattered through the code.
Currency. Tax rate and treatment. Invoice fields required. Date format. Number format. Working week. Public holiday calendar. Address format. Supported languages. Where data is stored. Payment providers available. Support hours.
Get this right and adding a country becomes adding a row and testing it. Get it wrong and adding a country is a development project, every time, indefinitely, and the cost of each one grows as the special cases accumulate on top of each other.
What belongs in configuration is anything that differs between countries without changing how the system fundamentally works. A tax rate is configuration. A completely different invoicing workflow mandated by a regulator is not, and forcing it into the configuration table produces something nobody can safely change.
A reasonable test: could a non-developer change this safely, given a written explanation? If yes, it is configuration.
What actually varies
The list is longer than most teams expect, which is the main finding.
Tax
Rates differ. Registration thresholds differ. What is exempt or zero-rated differs. What must appear on an invoice differs.
Treat each country's tax position as a separate question for somebody qualified there. It is not a variation on what you already know, and the assumption that the neighbouring market works roughly the same way is where expensive errors originate.
Invoicing and electronic invoicing
Several countries in the region have introduced or are introducing electronic invoicing, each with its own technical format, timetable and phases. These are not interchangeable.
The UAE has its own programme, and the authoritative source on scope, timing and phasing is the Ministry of Finance rather than commentary. Our UAE electronic invoicing guide covers what is publicly stated.
The structural instruction is straightforward: make the invoice document format a country setting, so that a new requirement is a new format rather than a rewrite. The number of countries requiring this is increasing, not decreasing.
Currency
Three things get conflated and should not be.
The currency you display. Local, wherever possible, because a price in local currency reads as a price rather than a conversion.
The currency you charge in. May require a payment arrangement you do not yet have.
The currency you report in. One, consistently.
And the rule that saves the most pain: store the exchange rate on the transaction. If you convert historical figures at today's rate, last year's numbers change every time somebody runs the report. Nothing destroys confidence in reporting faster. Store the rate that applied at the moment, alongside the amount, and reporting becomes reproducible.
On prices, set them per market rather than converting automatically. A converted price arrives at an odd number and reads as an afterthought. Local prices also let you reflect genuinely different competition. The cost is maintaining several price lists, which is real but manageable. Our guide on pricing a software product covers the wider question.
The working week
This is the difference most systems miss, and it hides in places nobody thinks to check.
Anything that counts business days: service commitments, delivery estimates, escalation timers, payroll cycles, invoice due dates, report periods. If the weekend is hard-coded, all of them quietly produce the wrong answer in the second country.
Quietly is the operative word. Nothing errors. A report reconciles wrongly against another team's, or a deadline passes, and somebody eventually works backwards to the cause.
Public holidays
Same problem, worse, because holidays differ by country and some move each year rather than falling on fixed dates.
Build a holiday calendar the business can maintain without a developer. Otherwise every year becomes a small emergency, and in a multi-country system it becomes several.
Addresses, phones and names
Addresses: stop assuming a fixed set of fields. Structures differ, postal codes are used differently or not at all, and a form demanding a postcode from somebody in a country that does not use them loses you the customer at the last step. Store flexibly, validate lightly.
Phone numbers: store with the country code, always, and validate by country. Systems built for one market routinely store local-format numbers with no country code, and once a second country exists nobody can tell which country an old number belongs to. Fixing that means guessing.
Names: avoid rigid assumptions about how many parts a name has. Provide a full name field where you can. Names displayed incorrectly are an immediate signal to the customer that the system was not built for them.
Language
Across the Gulf, Arabic is worth doing properly rather than as a translation layer applied afterwards. It affects layout direction, fonts, date display and form design, not only the words. Our guide on right-to-left design covers the interface consequences, which are what gets underestimated when the work is scoped as translation.
And do not derive language from country. Many markets are genuinely multilingual, the UAE more than most. Let the user choose and remember the choice. Deriving language from location produces a confident wrong answer for a large share of users, which is worse than asking once.
Our guide on multilingual websites covers the content side.
Time zones
Store every timestamp in a single reference zone and convert only for display.
Systems that store local times without recording the zone become impossible to reason about the moment a second country exists, and cross-market reports silently compare different moments.
This is cheap to do correctly on day one and genuinely expensive to correct afterwards, because every existing timestamp is now ambiguous.
Where data lives
Requirements vary by country and sometimes by sector, with financial services and health data typically stricter than general business data. Some rules require local storage, some impose conditions on transferring data abroad, some are silent.
Establish the actual requirement per market before designing around the worst case. Assuming everything must be separated is expensive: separating data by country complicates reporting, support and every subsequent feature.
Our guide on where your data lives covers the UAE position and the questions to put to a provider.
Terms, contracts and what the customer agrees to
Easy to overlook because it is not code, and it becomes a problem at exactly the wrong moment.
Your terms probably name one jurisdiction. Governing law, where disputes are heard, and frequently a reference to a specific regulator or a consumer protection regime that applies where you are rather than where the customer is. A customer in another country agreeing to terms written for yours is a weaker arrangement than it looks.
Consumer rights are not portable. Return periods, cancellation rights and what a seller must disclose differ by market, and in most places the local rules apply to a local consumer regardless of what your terms say. Writing something more restrictive than local law does not make it enforceable; it makes it a clause that fails when tested.
Privacy notices carry the same problem. A notice describing your obligations under one country's data law does not describe your obligations under another's, and the people whose data it is are entitled to an accurate account.
The system consequence is that terms acceptance needs to record which version, in which language, for which country, at what moment. A single flag saying the customer agreed is not enough once there is more than one set of terms in circulation, and reconstructing it later from deployment history is unpleasant.
Get each market's terms reviewed locally before launch rather than translating what you have. It is a smaller expense than it sounds and a considerably smaller one than discovering the gap during a dispute or an inspection.
Payment methods
Card penetration, preferred local methods and gateway coverage all differ. A checkout that performs well in the UAE can lose a large share of transactions elsewhere purely for not offering what people expect.
Check whether one provider covers your markets properly rather than assuming. Providers differ in which countries they settle in, which currencies they support and which local methods they offer. One provider used badly across five countries can cost more in abandoned and failed payments than the overhead of using two well. Our payment gateway comparison covers the UAE options.
What this looks like in the data
The configuration table is the settings. This is the other half: what changes in the data itself.
Country belongs on the records that have one. Customers, orders, invoices, and usually users. Not as a display preference, but as a real field the system can filter and report on. Systems retrofitted for a second country frequently derive country from something unreliable, such as the currency of the order or a prefix on an address, and every report built on that inference is quietly wrong at the edges.
Amounts need a currency alongside them. A number without a currency is only meaningful in a single-country system. Store the amount, the currency, and where a conversion happened, the rate and the moment it applied.
Timestamps need a zone, or a single agreed reference zone applied everywhere. Both work. What does not work is a mixture, which is what most systems end up with when nobody made the decision explicitly.
Tax needs to be stored as applied, not recalculated. The rate that applied to a transaction belongs on that transaction. Recalculating historical tax from current configuration means that changing a rate silently rewrites your history, which is a serious problem in an audit and an avoidable one.
Invoice numbering frequently needs to be per country or per entity. Some jurisdictions expect a continuous, gapless sequence per issuing entity, and a system that skips numbers or interleaves several countries in one sequence cannot demonstrate that. This is a compliance question rather than a tidiness preference, so check the requirement in each market before assuming your existing scheme transfers.
None of these are difficult individually. They are difficult collectively when added late, because every one of them requires deciding what the existing data meant, and the honest answer for old records is sometimes that nobody knows.
The second country is the expensive one
Worth understanding, because it shapes how you budget.
The second country is where you actually build the capability to be multi-country. Everything above becomes real work: pulling hard-coded values into configuration, adding country to the data model, deciding the reporting currency, building the holiday calendar.
The third and fourth countries are much cheaper if the second was done properly, and considerably worse if it was rushed, because a second country bolted on with special cases becomes a third country with special cases on top of special cases.
So choose the second market deliberately. The best candidate is the one that exposes the most assumptions for the least commercial risk: different currency, different tax treatment, different weekend, different language. Getting those four out of the way in a market where a mistake is survivable is worth more than launching first in the market with the largest opportunity. Our guide on selling into Saudi Arabia covers the most common second market for UAE businesses.
If your system was never designed for this
Most were not. This is normal rather than a failure of foresight.
Retrofitting is a real project, but usually a smaller one than it feels, because the effort concentrates in a small number of places:
Hard-coded currency, where amounts are stored as numbers with the currency implied.
Hard-coded tax, where a single rate sits in the code.
Hard-coded weekends, in every business-day calculation.
Timestamps without zones, which is the one that gets worse the longer you wait.
Audit those four before deciding anything. The answer is frequently less alarming than the fear, and it converts an intimidating "we need to rebuild" conversation into a bounded piece of work. Our guide on systems that break when you grow covers the wider version of this assessment.
On whether to build for many countries from the start: building for a specific second country is cheaper than building for hypothetical ones. What is worth doing on day one is the cheap structural work, storing time zones and currencies properly and keeping country values in configuration. Full internationalisation before you know your markets buys flexibility you may never use.
Migrating what you already have
The new country gets a clean start. The existing data does not, and this is where retrofit projects lose time.
Every existing record now needs a country, and for old records the honest answer is sometimes that nobody knows. A customer created five years ago with a local-format phone number and a partial address may be genuinely ambiguous.
The workable approach is to default rather than guess. Set every existing record to your original country, which is correct for the overwhelming majority, and accept that a small number are wrong rather than attempting to infer each one. Then correct them as they surface through normal use, which they will, rather than through a data cleansing project that costs weeks and finishes at ninety-five per cent anyway.
Timestamps are the harder case, because an existing timestamp with no zone recorded cannot be repaired by defaulting. It has to be interpreted, and the interpretation is only safe if you know which zone the system was assuming when it wrote them. Usually you do, because there was only one. Write that assumption down as part of the migration, because in three years nobody will remember and the records will look like they were always stored correctly.
Historical invoices should not be reissued to match a new format. They were correct when issued under the rules that applied. Changing them retrospectively creates a worse problem than the inconsistency it removes, and any auditor would rather see a documented change of format on a date than a set of documents that no longer match what the customer received.
Plan the migration as its own piece of work with its own testing, rather than as a step inside the country launch. Migrations that run as an afterthought on launch weekend are the ones that go wrong, and the failure mode is discovering at month-end that a proportion of historical records are now categorised wrongly in reports that people are already acting on.
Launching a country properly
Test the whole cycle, not the screens. Configure the country fully in a test environment, then create a customer, take an order, apply the correct tax, produce a compliant invoice, run a report, and process a refund.
Most problems appear at the invoice and the report. Testing that stops at the interface misses them, which is why they are so often found by a customer or an auditor instead.
Get four sign-offs before launch, from named people rather than teams. Finance on tax and invoicing. Legal or compliance on data and terms. Operations on the working week and support hours. Product on language and interface.
The absence of a named finance owner is the single most common cause of an invoicing problem discovered by a customer.
Decide the support model and publish it. Local working hours or one central set of hours are both legitimate. What generates complaints is a stated response time that ignores a market whose weekend differs from yours, so a Thursday evening request is answered on Monday against a one-day commitment.
What breaks first
Invoices and reports, consistently, and in that order.
The interface tends to survive, because problems there are visible and somebody fixes them in the first week.
Invoices fail quietly against a requirement nobody read.
Reports fail quietly by mixing currencies, time zones or working weeks without saying so anywhere on the page.
Both are found late, by somebody outside the team, which is the expensive way to find anything.
On keeping reports comparable: fix one reporting currency and one reporting time zone, store the conversion rate on each transaction, and then decide explicitly which metrics are meaningful across markets at all. Revenue per customer across markets with different pricing and tax treatment frequently is not, and comparing it anyway produces confident conclusions that are wrong.
The cost that keeps arriving
Budgeting for expansion usually covers the build and stops there. The build is the bounded part.
What recurs, per country, every year:
Tax filings and the compliance calendar. A second set of deadlines, a second adviser, and a second set of records to keep in whatever form that country requires.
A second holiday calendar, maintained annually, plus the operational planning around it.
Support coverage across a different working week, which is either additional hours or an explicit and published limitation.
Reconciliation. More currencies, more payment providers, more bank accounts, and a month-end that takes measurably longer than it did with one market. This is usually somebody's existing job getting harder rather than a new hire, which is why it goes unbudgeted.
Testing on every release. This is the one that gets missed most often. Every change now has to be verified against every configured country, or you accept the risk of shipping something that works in one market and quietly breaks in another. In practice that means either automated checks per country or a longer manual pass before each release, and both cost something every single time rather than once. The cost also grows with each country added, which is the part that catches teams out at the fourth market.
And a quieter one: decisions take longer. Every product question now carries a country dimension. Does this apply everywhere? Does it need to differ? Who signs it off, and in which market? That overhead is small on any single decision and substantial across a year of them, and it is felt by the people least likely to report it as a cost.
None of this is an argument against expanding. It is an argument for costing the second country as an ongoing operational commitment rather than a project with an end date, because the project ends and the commitment does not.
The document nobody writes
One page per country. Currency, tax treatment, invoice requirements, data storage position, languages, working week, holiday source, payment providers, support hours, and who signed off each.
Unglamorous, and it prevents the recurring situation where nobody can explain why the system behaves a particular way for one market and the only person who knew the reason has left the business. Keep it next to the configuration table so the two are updated together, because a setting without a recorded reason eventually gets changed by somebody who assumed it was arbitrary.
The expensive mistake
Treating the second country as a translation and pricing exercise.
That framing produces a project that ships an interface in another language sitting on top of tax, invoicing, date, weekend and data assumptions that all still belong to the first country. Everything looks correct. The problems surface months later in finance and compliance, which is where they are hardest to fix and most costly to have been wrong about.
Start instead by writing the differences down. Take your intended second country and list every difference from your current one: tax, invoice requirements, currency, language, working week, holidays, address format, phone format, data rules. Then check your system against that list, item by item.
It usually takes a day, and it turns a vague expansion plan into a specific and generally much smaller piece of work than anybody feared.
If you want help with it, a multi-country readiness review covering what in your system assumes one country, what has to change, what belongs in configuration, and the tax and data questions to put to specialists starts from around AED 8,000 with us. Implementation is quoted separately by scope. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- Ministry of Finance, UAE
- Federal Tax Authority, United Arab Emirates
- The Official Portal of the UAE Government, value added tax
- SKIMBOX, UAE electronic invoicing guide
- SKIMBOX, data residency and where your data lives
- SKIMBOX, selling into Saudi Arabia from the UAE
- SKIMBOX, right-to-left website design for Arabic
- SKIMBOX, multilingual website development in the UAE
- SKIMBOX, UAE payment gateway comparison
- SKIMBOX, when your system breaks as you grow
- SKIMBOX, how to price a software product
Tax, invoicing and data rules differ by country and change. Nothing here is tax or legal advice; confirm each market's position with the relevant authority or a qualified adviser in that country before launching there.
