Free Zone vs Mainland: ERP Setup in UAE

A group has four companies. Two mainland LLCs, a free zone entity in one of the industrial zones, and a holding company in a financial free zone. One customer base, one warehouse, one finance team of six people who move between all four books without thinking about it.

The ERP has been configured as one company with a department field.

I have seen this more times than I would like, and the people who built it were not careless. They were solving the problem in front of them, which was that management wanted a single view of the group and the entities were an administrative detail. The trouble is that the entities are not an administrative detail. They are separate taxable persons, separately licensed, separately audited, each capable of being examined on its own — and a department field is not a wall.

The reverse mistake is equally common and more expensive: four completely independent installations, four charts of accounts that share no structure, and a group consolidation assembled by hand every month by someone who is the only person who understands the mapping.

This is about the middle path, and about the three separate boundaries people collapse into one when they set up a system in this country.

Three lines, not one

The phrase "free zone versus mainland" describes a licensing distinction. People then reason from it to conclusions about tax that do not follow. There are three lines and they do not sit on top of each other.

The licensing and commercial line. A free zone entity is licensed by its zone authority; a mainland entity by the relevant emirate's economic department. This governs what activities you may carry out and where you may carry them out. Historically it is also the line that determined how you could sell into the local market, which is why so many groups hold both. It has consequences for your ERP mostly in terms of which entity is allowed to be on which document.

The VAT line. This is the one that gets mangled. Being in a free zone does not, by itself, change your VAT position. The great majority of free zone companies are treated for VAT exactly as a mainland company is: registered, charging on standard-rated supplies, filing returns. The special treatment attaches to designated zones, which are a specific list set by Cabinet Decision, and even then it applies principally to supplies of goods within and between those zones. Services are generally treated as supplied in the UAE regardless. The list is amended from time to time; read the current one rather than assuming your zone is on it because somebody said so in 2019.

The corporate tax line. A qualifying free zone person can benefit from a preferential rate on qualifying income, subject to conditions, activity tests and de minimis limits set out in the published guidance. This is a third boundary again — an entity can be in a designated zone for VAT and fail the qualifying tests for corporate tax, or the other way round.

Three lines. Your ERP has to respect all three, and they are drawn in different places.

The practical consequence is that the question "is this a free zone company?" is not a configuration input. The useful inputs are: which zone, is it a designated zone for VAT purposes, what does the entity actually sell, to whom, and where does the customer take delivery.

What actually changes in the system

Legal entities are entities, not dimensions

Every registered legal entity gets its own company in the ERP. Not a branch, not an analytic tag, not a filter on a report.

This is not a preference. It is what makes it possible to produce a balance sheet that belongs to one legal person, to keep separate tax registrations, to issue documents in the correct company's name and sequence, and to answer an audit that is scoped to one taxable person rather than to your group. If you have modelled entities as a dimension, then every legal report you produce is the output of a filter, and a filter is only as good as the discipline of whoever last entered a transaction.

The counter-argument is always the same: multi-company means more work, more licences, more inter-entity friction. That is true. It is also the cost of the structure you chose when you incorporated four companies, and the alternative is not saving that cost — it is deferring it to the point where it is paid under time pressure with an auditor present.

Modern platforms handle this reasonably well. Odoo, for instance, has a multi-company model where a user can operate across entities from one login and inter-company documents can be generated automatically. It is one of the genuine strengths of the product for groups of this shape, though it comes with sharp edges around record rules and default company that are worth understanding before you rely on them — the broader view of where Odoo is strong and where it is not in this market sets out the same trade-off across the rest of the suite.

One chart of accounts, with local extensions

The instinct in a mixed group is to let each entity have the chart that suits it. Resist it.

Use one group chart of accounts, defined once, applied everywhere, with a governed process for adding an account. The reason is not tidiness. It is that consolidation is either a mapping exercise you perform every month forever, or a structural property of your ledger. If two entities book the same kind of cost to accounts that do not correspond, somebody rebuilds the correspondence at every close, and that person becomes a dependency.

Where entities genuinely differ, extend rather than diverge. A free zone entity may need accounts for zone-specific fees, customs deposits, or movements in and out of a designated zone that a mainland entity has no use for. Add them to the group chart and leave them unused elsewhere. An account that exists and is empty costs nothing. An account that exists only in one entity's chart costs a reconciliation every month.

Two structural details that repay attention at design time:

Keep intercompany accounts separate and paired. Receivables and payables between group entities must sit in dedicated accounts, one pair per counterparty entity, never mixed with third-party balances. Consolidation eliminations become arithmetic instead of investigation.

Do not encode the entity in the account number. The company dimension already carries it. Encoding it again produces a chart that grows with every new licence and a set of reports that break when you add one.

VAT configuration follows the transaction, not the licence

Your tax codes should be derived from what is actually happening: what is supplied, to whom, where it is delivered, and under which registration it is being sold. Not from a flag on the company record saying "free zone".

The cases that need designing explicitly, rather than left to whoever is keying the invoice:

Standard-rated domestic supply, whichever entity makes it.
Export of goods outside the country, with the evidence requirement that attaches to zero-rating.
Movement of goods into, within and out of a designated zone, where the treatment depends on the physical movement rather than on the parties.
Services, which generally do not get designated zone treatment even when both parties are inside one.
Reverse charge on imported goods and on services received from abroad.
Supplies between your own group entities, which are real supplies unless the entities are in the same tax group.

That last point deserves its own sentence. If your entities are not in a VAT group, a transaction between them is a taxable supply requiring a proper tax invoice. It is not a management recharge. A surprising number of groups discover this late, having moved goods between a free zone company and a mainland company for years on the strength of an internal transfer note.

If the entities are in a tax group, the group has one registration and one return, intra-group supplies fall away — and your ERP now has to produce a combined return from several companies while keeping their statutory books separate. That is a reporting configuration, and it needs to exist before the first return, not after.

The tax code set that comes out of this is longer than the three or four most UAE installations run on, and every one of them needs a written definition of when it applies. Anything less means the determination is a habit rather than a rule, which is precisely the weakness an audit exposes when it walks the chain from the return down to a document.

Currency, and the reporting one

Free zone entities frequently trade in dollars and account in dirhams, or occasionally the other way round. Fix three things per entity at setup, in writing: the functional currency of the books, the presentation currency for the group, and the source and frequency of the rates.

Then decide where revaluation is posted and who reviews it. Unrealised exchange differences are a favourite hiding place for errors, because they are expected to be non-zero and nobody knows what the right non-zero number is.

Intercompany: always underestimated

In a mixed free zone and mainland group, intercompany traffic is the single largest source of month-end pain, and it is worth designing rather than discovering.

Four flows need explicit handling.

Goods moving between entities. This is a sale and a purchase, generating a document pair, a tax treatment on both sides, and a margin that has to be eliminated on consolidation if the goods are still on hand at period end. If it is currently a stock transfer, it is misstated.

Shared services and management charges. Head office costs recharged to operating entities. Needs a policy, a basis, a supporting calculation and a real invoice — not a journal.

Financing. Loans and current accounts between entities, with interest where required. The balances have to agree on both sides at all times, which they will not if either side can post a one-sided journal.

Shared people and assets. The employee on one entity's payroll working on another's project, the warehouse owned by one and used by all.

Each of these needs three things decided before go-live: which document type carries it, whether the counterpart entry is generated automatically or entered by a person on the other side, and who reconciles the pair. Automatic generation is much better than discipline. Discipline decays.

Transfer pricing evidence lives in the system or nowhere

Once intercompany pricing has to be defensible, the ERP acquires a job it did not have before: it has to preserve the basis of the price, not just the price.

Practically this means the recharge calculation is a document with its inputs, not a number in a journal narration. It means the allocation basis is a stored quantity — headcount, floor area, revenue share — rather than a percentage someone remembers. And it means the policy is written down somewhere retrievable rather than living in the finance director's understanding of last year's arrangement.

Nobody enjoys building this. Everyone who has had to reconstruct three years of recharges from memory builds it afterwards.

Consolidation should be arithmetic

If the chart of accounts is common, the entity dimension is real, and intercompany balances sit in paired accounts, consolidation is: sum, eliminate the pairs, translate the currencies, remove unrealised margin on intra-group stock. That is a process a system performs.

If any of those three preconditions is missing, consolidation is instead a monthly reconstruction performed by a person in a spreadsheet, and it will be late, unauditable and impossible to explain when the person is away. The choice between those two outcomes is made at configuration time, months before anyone feels the consequence — which is exactly the pattern behind deciding how the business will run before choosing what runs it.

One warning on the group view. Management reporting almost always wants the consolidated picture, and it should have it. But the consolidated picture is not a legal picture, and the moment somebody starts making entity-level decisions from a group report — pricing, credit, tax position — the boundary you built has been quietly bypassed by the reporting layer.

Documents, numbering and identity per entity

Each entity needs its own document sequences, its own invoice layout carrying its own licence and registration details, its own bank accounts mapped to its own ledgers, and its own approval matrix. Sequences must not be shared across entities, for the obvious reason that a gap in one entity's sequence is a question you do not want to answer.

Users need a default company and clear visibility rules. The most common practical error in multi-company installations is a user with access to everything and a default set to the wrong entity, quietly booking transactions into the wrong company for a week before anyone notices.

E-invoicing multiplies by entity

Under the phased mandate published by the Ministry of Finance, each registered entity that is in scope needs its own identity on the network, its own onboarding, and its own configuration. Businesses at AED 50 million or more in annual revenue must appoint an Accredited Service Provider by 30 October 2026 and go live on 1 January 2027; below that threshold, appointment is by 31 March 2027 and go-live is 1 July 2027. Government entities go live on 1 October 2027. Voluntary participation opens on 1 July 2026, and non-compliance carries a penalty of AED 5,000 per month.

Two things follow for a group.

First, the threshold question is about the taxable person, so a group with several entities may find them landing in different waves. Plan for a period in which some of your companies transmit structured invoices and others do not, because your internal processes will have to tolerate both at once.

Second, intercompany invoices between separately registered entities are B2B invoices. They go across the network like any other. If your intercompany documents are currently journals with no invoice behind them, that practice has an expiry date, and the practical detail of what the mandate requires of the system that issues them applies to them in full.

When you come to appoint a provider, entity handling is a specific thing to test rather than assume. Ask how multiple registrations are onboarded, whether they are priced separately, and what happens when you add a fifth company next year. This is one of the questions worth putting near the top of the list when selecting an Accredited Service Provider.

The decision underneath all of it

Before any of the above can be configured, one question has to be answered by a person with the authority to answer it: is finance centralised or is it at the entity?

Centralised means one shared service operating all books, one approval matrix, one close calendar, users who work across companies, and a system optimised for cross-entity efficiency. Entity-level means each company runs its own finance function with its own controls, and the group receives reporting rather than operating the books.

Almost every group says centralised and configures neither. The result is a system that assumes a shared service while the actual work is done by four separate teams who each want their own way, or the reverse. This is the single most consequential input to a multi-entity ERP design, it is not a technical decision, and it should be settled in writing before the first configuration workshop — the same way any serious ERP selection in this market should settle its operating model before it compares products.

Seven questions worth answering this week

Is each legal entity a real company in your ERP, or a value in a field?
Is your free zone entity in a designated zone for VAT, and can someone show you the decision that says so?
When goods move between your entities, does the system produce a sale and a purchase, or a transfer?
Are your entities in a VAT group? Does everyone who enters transactions know the answer?
Do intercompany balances agree on both sides today, without adjustment?
Can you produce a standalone statutory set for the smallest entity without touching a spreadsheet?
Which of your entities falls into which e-invoicing wave, and who is tracking that?

The ones you cannot answer quickly are not knowledge gaps. They are configuration gaps wearing a disguise, and each of them is cheaper to close now than during a close, an audit or an onboarding queue.

If you are carrying a structure across zones and are not confident the system underneath it reflects the structure, the way we work through this kind of diagnosis starts by writing down what is actually there before anybody proposes changing it.

Free Zone or Mainland: What It Really Changes in Your ERP