Corporate Tax Did Not Arrive as a Return. It Arrived as a Data Structure.

The first corporate tax return in most mid-market UAE companies was assembled in a spreadsheet, in the fortnight before it was due, by one person with the trial balance open on one screen and an adviser's questionnaire on the other.

The questions were not difficult. They were simply unanswerable from the system. How much of last year's entertainment spend was client entertainment rather than staff welfare. What proportion of the management charge from the holding company relates to which subsidiary and on what basis. Which of these customers are related parties. How much of the free zone entity's revenue came from mainland counterparties. The answers were reconstructed by opening invoices, asking the sales manager what he remembered, and applying a percentage that felt defensible.

That return was filed. It was probably not wrong in any way that will be noticed. But it was produced by archaeology rather than by accounting, and it will be produced by archaeology every year until somebody makes a structural decision instead.

This piece is about that decision: what corporate tax actually demands of an accounting system, which of those demands are chart-of-accounts questions, which are master data questions, and why the cost of getting it wrong compounds rather than repeats.

The return asks a question your ledger was never designed to answer

Before corporate tax, a UAE general ledger had two audiences: management, who wanted to know whether the business made money and where, and the auditor, who wanted the balances supportable and the presentation compliant with the framework.

Neither cared about the distinction between a deductible expense and a non-deductible one. Neither cared whether a supplier was a related party in the legal sense, because the audit's related-party note was compiled from a list the finance director maintained separately and updated annually.

Corporate tax is a third audience asking a different class of question. It asks about the character of a transaction, not just its amount and its counterparty. And character, in almost every mid-market ledger in this country, is not recorded anywhere. It lives in the memory of the person who booked the entry.

The structural fact is this: taxable income is a computation performed on accounting profit, and every step of that computation needs an input your ledger either carries or does not. If the input is carried, the return is a report. If it is not, the return is a project.

Accounting profit is an input, not an answer

The headline arithmetic is well known. Taxable income up to AED 375,000 is taxed at zero per cent; above that, at nine per cent. A qualifying free zone person pays zero per cent on qualifying income and nine per cent on the rest. Small Business Relief has been available to resident businesses with revenue at or below AED 3 million for tax periods running to the end of 2026 — check the current position with the Federal Tax Authority before relying on it, because that relief has a stated end date and reliefs get extended, modified or allowed to lapse.

None of that arithmetic is the difficult part. The difficult part is arriving at the number the rate is applied to.

Accounting profit is where you start. Then a series of adjustments is applied, and each adjustment is a question about transactions that have already happened. Here is the shape of it, with the thing your system has to be carrying in order to answer without a reconstruction exercise.

The adjustment	What the return needs to know	Where it has to live in the system
Exempt income (dividends, qualifying participations, foreign branch profits where elected)	Which income lines are exempt, at source	Separate revenue and other-income accounts, never a single "other income" bucket
Non-deductible expenditure	Fines and penalties, donations to non-qualifying recipients, expenditure not incurred wholly for the business	Dedicated accounts, not a note in the description field
Entertainment expenditure	The portion relating to customers, suppliers and other business contacts, which is restricted	A separate account from staff welfare, decided at the point of posting
Interest limitation	Net interest expenditure for the period against the applicable cap	Finance costs isolated from bank charges and FX losses, which are neither
Related-party transactions	Aggregate value by counterparty and by category	A related-party flag on the partner master, and reporting by counterparty
Connected-person payments	Total payments and benefits to owners, directors and their relatives	The same flag, plus payroll and expense data that can be attributed to a named person
Free zone qualifying income	Revenue split between qualifying and non-qualifying activity and counterparty	A transaction-level classification, not a year-end estimate
Depreciation and asset adjustments	Book depreciation reversed, tax treatment applied	A fixed asset register that is actually a register, not a schedule in a workbook
Provisions and unrealised amounts	Movements in provisions, unrealised gains and losses where the realisation basis is elected	Separate accounts for movement rather than net closing balances

Read that right-hand column as a list of design decisions. Every one of them is cheap to make when you are configuring a chart of accounts and expensive to make once eighteen months of transactions have been posted against the old one.

The chart of accounts decision: segregate rather than annotate

There is a persistent instinct, when a new reporting requirement arrives, to add a field. A tick box on the journal. A tag. A note. Something to be filled in later by whoever does the analysis.

It does not work, for a reason that has nothing to do with software. A field that is not required in order to complete a transaction gets left blank by a busy person on a Thursday, and a field whose absence stops nothing means nothing three months later. This is the same disease that produces dashboards which are technically correct and tell you nothing: a number computed faithfully from data nobody was obliged to enter faithfully.

Segregation works because it is not optional. If entertainment of customers and staff welfare are two different accounts, the person posting the invoice has to choose one. They may choose wrong, which is a training problem with a visible symptom. They cannot choose nothing.

So the rule for a corporate-tax-ready chart of accounts is uncomfortable and simple: anything that receives different tax treatment gets its own account, even where management reporting would happily see it combined. Fines separate from other administrative costs. Donations separate, and split between qualifying and non-qualifying recipients. Interest on borrowings separate from bank charges and separate from foreign exchange differences, because the interest limitation applies to one of those three and not the others. Dividend income separate from other income.

This makes the chart of accounts longer, which people resist. But a management pack is a presentation layer and grouping is free, whereas an account that was never split cannot be unsplit without going back through every transaction.

Where dimensions do the rest of the work

Not everything belongs in an account code. Analytical dimensions — cost centre, project, business unit, entity — slice a single account many ways without multiplying the code list, and they are the right home for anything that is a property of the transaction's context rather than of its nature. The failure mode is using a dimension for something that should be an account, because dimensions are easier to add. A dimension can be left blank. An account cannot.

Related parties are a master data problem wearing a tax costume

The disclosure obligations attached to related parties and connected persons are, mechanically, reporting requirements. In practice they are the single most common reason a tax return cannot be produced from the system.

The reason is that "related party" is not a property your customer and supplier records carry. It is a fact about ownership and control that lives in a corporate structure chart, usually a PDF, usually held by one person, usually out of date because a shareholding changed last year and nobody told finance.

The FTA's disclosure framework, at the time of writing, requires related-party transactions to be disclosed where the aggregate value across all related parties exceeds AED 40 million, with category-level disclosure above AED 4 million per category, and a separate schedule for payments or benefits to a single connected person above AED 500,000. Confirm the current thresholds and category definitions against the FTA's own guidance rather than a summary, because these are set by decision and have been refined more than once.

What matters more than the figures is the shape of the requirement: an aggregation by counterparty, across categories of transaction, for a full tax period. Trivial if the counterparty is flagged and the flag is accurate. A fortnight of work if it is not.

Three things to do, none of which need a consultant:

Put the flag on the master record, not on the transaction. Related-party status is a property of the counterparty. Flag it once and let every transaction inherit it. A flag on the transaction will be wrong within a quarter.

Deduplicate first. A group entity that appears three times in the customer master under three spellings will be flagged once and missed twice. This is the same data problem that kills ERP projects during migration, and it does not change because the reason for caring about it changed.

Give the flag an owner and a review date. In most groups the honest owner is whoever deals with the corporate service provider, not the person in finance who will be asked for the report.

Free zone qualifying income is a classification, not an estimate

If any entity in your group is claiming qualifying free zone status, this section is the one that costs money.

The regime is unusually unforgiving in its architecture. Qualifying income is taxed at zero per cent and non-qualifying income at nine — but there is a de minimis test, and breaching it does not simply tax the excess. It removes qualifying status for the tax period and for a number of subsequent periods. The de minimis is expressed as the lower of a percentage of total revenue and an absolute amount; verify both figures with the FTA before relying on them, because they are the sort of parameter that gets adjusted.

A cliff-edge test means you need to know where you stand during the year, not after it. A percentage computed in March, on the prior year, is not a control. It is a post-mortem.

So classification has to happen at the moment of transaction. Every sales line implicitly carries three facts that determine treatment: what activity generated it, who the counterparty is and where they are established, and whether the goods moved through a designated zone. In most free zone entities I open, none of the three is recorded in a way a report can read. The activity is inferred from the product name, the counterparty's establishment sits in a free-text address field, and the designated-zone movement is in the logistics provider's paperwork.

The fix is unglamorous: a qualifying-activity classification on the product or service master, a counterparty category on the partner master, and a report that runs monthly and shows the non-qualifying percentage as a trend. When that percentage starts drifting towards the limit in month seven, somebody can still do something about it. This is one of several reasons free zone and mainland entities need genuinely different configurations rather than a copied company with the name changed.

Transfer pricing documentation is evidence, and evidence has to be contemporaneous

Related-party transactions must be priced at arm's length. Above certain group and entity revenue levels — the master file and local file thresholds, which you should read from the current FTA guidance rather than from any article including this one — formal documentation is required and must be produced on request. Below those levels, the principle still applies to the transaction itself. A management charge from the parent, a loan between entities at a rate somebody chose, a sale of stock from the trading company to the manufacturing company at a margin nobody documented: each is a position you may one day have to defend.

The system's role here is narrower than people expect and more important than they think. It is not to compute an arm's length price. It is to make the transaction identifiable and quantifiable after the fact: which entity charged which, for what, how much, on what basis, and against what agreement. If intercompany charges are posted as a single monthly journal with the narration "MGT FEE", there is no evidence. If they are raised as intercompany invoices, with lines, against a documented allocation basis, there is.

The habit worth forming is that every intercompany flow is a document, not a journal. It costs a little more effort each month and it is the difference between a file and an argument when an authority asks your system a question.

Tax groups are not consolidation, and your ERP knows the difference

Groups that form a corporate tax group file a single return for multiple entities. It is tempting to assume this makes the entity structure less important inside the system. It makes it more important.

A tax group's taxable income is computed by aggregating members and eliminating transactions between them, which requires that intercompany transactions be identifiable as such, on both sides, at line level. It also requires that the group's composition be tracked over time, because entities join and leave.

Meanwhile the members remain separate legal persons with separate books, separate VAT positions in some structures, and separate free zone status. So the ERP has to hold the entity boundary rigidly and produce the aggregate on top of it — exactly the architecture a multi-company setup gives you and exactly the architecture a single company with a "branch" dimension does not. Groups that took the dimension shortcut to save licence cost discover it here, and unwinding it means restating history.

What to build before the next return

If you have filed once and are dreading the next one, the useful work sits in a narrow window: after the audit closes, before the new financial year is far enough along that changes mean restatement.

Take last year's return and the adviser's working papers and, for every adjustment, write down where the number came from. You will end up with three piles. Numbers that came from the ledger, which need nothing. Numbers that came from a report built specially, which need an account split or a dimension so the report becomes standing. And numbers that came from a person's judgement applied to a list of transactions — the expensive ones, which need a classification decided at the point of entry.

Then do the master data. Flag related parties and connected persons. Deduplicate the counterparties. Classify products and services by qualifying activity if a free zone entity is in scope. Validate the fields that matter so a blank stops a transaction rather than surfacing eleven months later.

None of this is a software purchase. It is configuration, master data and a decision about what the chart of accounts is for. It is also the least popular work in a finance function, because it produces nothing visible until the moment it produces everything. The alternative is to rebuild the same reconstruction every year, with a different person each time, and hope nobody ever asks you to prove it.

If you want a structured view of whether your current system can carry this without rework, the ERP readiness assessment covers the same ground question by question. And if the honest answer is that the ledger was never designed to be asked these questions, that is not a tax problem — it is an ERP implementation with a filing date attached to it.