Compliance

UAE Corporate Tax for Groups: Consolidation, Transfer Pricing Records and the ERP Setup That Makes It Easy

Corporate tax turned every UAE group's intercompany activity into a reportable fact. Management fees, shared staff, loans between sisters, goods moved at cost: each one is now a related-party transaction that must be priced at arm's length and documented. The ERP either captures that as it happens or finance reconstructs it at year end.

Before corporate tax, most UAE groups treated their internal structure as an administrative matter. A holding company, a few trading entities, a free zone company for international business, a services entity employing the shared staff: money moved between them as cash flow required, and the year-end accounts tidied it up. That approach no longer works. Under the corporate tax regime, each entity is a taxable person, every transaction between related parties must be at arm's length, and the group must be able to show the authority how it priced and recorded them.

The groups that find this easy are the ones whose ERP already treats each entity as a company, records intercompany transactions as paired documents and tags related parties. The groups that find it painful are the ones with one accounting file per entity, intercompany balances that never agree and a year-end exercise to reconstruct what happened. This guide sets out the ERP configuration that makes the difference, with the regulatory points framed as the published framework currently indicates. Your tax adviser should confirm the positions for your group.

Key takeaways

  • Each legal entity should be its own company in the ERP with its own ledger, sequences and tax registrations, under one shared database.
  • Related parties must be tagged in the partner master so every transaction with them is identifiable at source.
  • Intercompany transactions should be created as paired documents, an invoice in one entity and a bill in the other, with a shared reference.
  • Transfer pricing documentation needs the transaction, the pricing basis and the agreement reference, which the ERP can hold and report.
  • Consolidation and eliminations should be a report run from aligned charts of accounts, not a spreadsheet exercise.

What the regime asks of a group

Under the published corporate tax framework, UAE resident entities are taxed at 9 percent on taxable income above the AED 375,000 threshold, with a 0 percent rate on qualifying income for qualifying free zone persons who meet the conditions. Groups face several additional considerations.

RequirementWhat it means for the ERP
Each entity files, or a tax group files onceEntity-level ledgers that can also be consolidated with eliminations
Related-party transactions at arm's lengthEvery related-party transaction identifiable, with its pricing basis recorded
Related-party disclosure with the return above a thresholdA report of related-party transactions by counterparty and type, from the system
Master file and local file for larger groupsTransaction-level detail and agreement references retrievable per entity
Qualifying free zone person conditionsSeparation of qualifying and non-qualifying income in the free zone entity's books
Record retentionEntity-level records kept for the statutory period

Entity structure in the ERP

The first configuration decision is to run every legal entity as a separate company in a single ERP database. Each company has its own ledger, journals, document sequences, VAT and corporate tax registrations, bank accounts and financial year. Users can be given access to one or several companies, and group management sees across all of them. Running separate databases or separate accounting files per entity is the root cause of most intercompany problems, because the two sides of every transaction are recorded independently and reconciled afterwards.

The second decision is chart of accounts alignment. Entities can have different charts, but consolidation is far simpler if the group uses one chart with entity-specific accounts only where genuinely needed. Where a legacy entity has its own chart, map it to the group chart in the system rather than in a spreadsheet.

Tag related parties at source

A related party is a counterparty, and counterparties live in the partner master. Every group entity, every shareholder-controlled business, every foreign affiliate and every connected person should be flagged as related in the partner record, with the relationship type. From that moment, every invoice, bill, payment, loan and journal entry involving that partner is identifiable as a related-party transaction without anyone remembering to classify it.

Add a transaction category to intercompany documents: management fee, shared services recharge, goods at transfer price, loan and interest, rent, royalty or licence, cost sharing. The combination of related-party flag and category is what the disclosure report and the transfer pricing file are built from.

Intercompany transactions as paired documents

The discipline that removes year-end reconciliation is simple: an intercompany transaction is created once and produces a document in each entity. A management fee invoice raised by the services company automatically creates a supplier bill in the trading company, with the same reference, amount and date. A goods transfer from the free zone entity to the mainland distributor creates a sales invoice on one side and a purchase on the other, at the agreed transfer price, with VAT treated correctly for the parties involved.

Odoo's multi-company intercompany rules do this natively, and SAP Business One, NetSuite and Dynamics 365 have equivalent mechanisms. The configuration questions are which transaction types to automate, which approvals apply and how intercompany balances are settled. With paired documents the intercompany receivable in one entity equals the payable in the other by construction, and the monthly intercompany reconciliation becomes a check for exceptions rather than a search for differences.

Transfer pricing records in the system

Arm's length pricing is a judgement your tax adviser supports with benchmarking. The ERP's role is to record what was charged, on what basis and under which agreement, so the judgement can be evidenced. For each intercompany transaction type, hold the following in the system.

  • The agreement reference, such as the intercompany services agreement or the loan agreement, attached to the partner or the recurring contract.
  • The pricing basis: cost plus a stated margin, a percentage of revenue, a fixed fee, a market rate, with the parameters stored on the product or contract rather than typed into each invoice.
  • The cost base for cost-plus charges, which means shared costs tagged by cost centre so the recharge can be traced to the underlying expenses.
  • Interest on intercompany loans, accrued on a schedule at the documented rate rather than booked when someone remembers.
  • Allocation keys for shared services, such as headcount or revenue, maintained with effective dates.

With these in place the local file narrative, the disclosure form and any authority query can be answered from system reports. Without them the group is reconstructing the basis of charges made eighteen months earlier.

Consolidation and eliminations

Whether or not the group forms a tax group, management wants consolidated numbers and the tax adviser wants entity numbers with the intercompany effect visible. The consolidation report in the ERP should take the aligned charts, sum the entities, eliminate intercompany revenue and expense, intercompany receivables and payables, and unrealised profit on intercompany stock, and present the result alongside the entity columns.

Eliminations are only reliable if the intercompany transactions are tagged at source, which is why the earlier steps matter. Groups with foreign subsidiaries add currency translation at the consolidation level. Groups with free zone entities that are qualifying free zone persons must additionally keep qualifying and non-qualifying income separate within that entity's books, which is an analytic or account-level split configured before the year begins, not after.

The year-end pack

When the configuration above is in place, the year-end deliverables for the tax adviser come out of the ERP as reports: entity trial balances on the group chart, intercompany reconciliation with zero unexplained differences, the related-party transaction schedule by counterparty and type, the consolidation with eliminations, the qualifying income analysis for free zone entities and the fixed asset and provision schedules. Our broader guide to corporate tax and your ERP covers the single-entity fundamentals that sit underneath.

How Kaido approaches it

We start with the group chart: every entity, its registrations, its ownership, its role and the flows of money and goods between them. From that we agree the multi-company structure, the group chart of accounts, the related-party register and the list of intercompany transaction types to automate. We work alongside the group's tax adviser on the pricing bases and the documentation requirements, so what the system records is what the adviser will defend.

The implementation is usually on Odoo for groups of up to a few dozen entities, using its multi-company, intercompany and consolidation capabilities, and on the client's existing platform where a larger system is in place. We run the first intercompany month-end with the finance team to prove the paired documents and the reconciliation, and the first year-end pack with the adviser to confirm the reports answer the questions asked. After that the process is a monthly routine rather than an annual rescue.

Running several entities and rebuilding the intercompany picture every year end?

Talk to a senior consultant about a multi-company ERP setup that captures related-party transactions, supports consolidation and produces the records your tax adviser needs. We will start with your group chart.

Book a discovery call →