Every Compliance Obligation You Have Is a Report Your System Can Produce, or Cannot

Every compliance obligation a UAE business has is, inside your system, one question asked seven ways: is the fact it needs already on the transaction, or will somebody reconstruct it afterwards?

VAT, corporate tax, e-invoicing, the Wage Protection System file, record retention, Arabic documents and free zone status look like seven filing exercises with seven deadlines. They are seven demands on one ledger, one set of master data and one archive, each met — or not — by decisions taken at configuration. Which account. Which classification. Which field cannot be left blank.

If the input is carried, the obligation is a report. If it is reconstructed, the obligation is a project, and it is the same project again next period.

That is the whole answer. The rest is which input each obligation needs, where it has to live, and the three master-data facts behind most failures.

Everything written about UAE compliance stops where the work starts

Tax firms explain the regulation and stop; that is where their responsibility ends. Vendors say "fully compliant" and stop; they are describing a feature list, not your data. Between those two full stops sits the part that takes the time: the chart of accounts, the invoice layout, the customer and item masters, the provider integration, the archive.

Nobody owns that gap. Your adviser cannot decide whether customer entertainment and staff welfare are one account or two. Your vendor cannot decide whether the address on a customer record is the mainland entity or the free zone one, because only you know which signed the contract. Those are configuration decisions with tax consequences, and they are what an ERP implementation here ought to be about.

A return is a report, or it is a project

Pick one figure on any return and trace it backwards. There are three places it can have come from.

The ledger. The number is a balance or a sum of transactions, and producing it costs nothing. More figures can reach this state than most finance teams assume.

A report built specially. The data exists but not in the shape the obligation wants, so someone writes a query. Survivable, and free the moment the special report becomes a standing one.

A person's judgement applied to a list. Somebody opened the transactions, decided which were which, and applied a classification that exists nowhere in the database. This costs the same time every period, answers differently depending on who does it, and leaves no evidence of how the answer was reached. That last part is the whole difficulty on the day an authority asks you to prove a figure rather than state it.

The seven obligations, and what each demands

Read the right-hand column as configuration decisions, not features: no product ships it filled in, and every entry is cheap at setup and expensive a year later.

VAT: the tax point is a field, not a policy

The return is arithmetic. What decides whether it is right is a set of facts recorded at the moment of the transaction, and the one most often wrong is the date.

Most systems hold one date on an invoice and call it the invoice date. The law gives you several, and which fires is settled by your contract and by what the document says. Contractors meet this hardest, because the VAT on retention falls due long before anyone pays the retention.

That is not a construction rule. It is the general date-of-supply rule landing on the industry that defers the most money, and any business invoicing in stages or taking payment in advance meets a version of it. The system consequence is small to build and expensive to retrofit: the date driving the return has to be its own field, populated from the event that triggered it, rather than whatever date the posting run stamped.

Rate and recovery are line-level facts, not header ones. One invoice can carry standard-rated lines, zero-rated export lines and lines outside the scope entirely, and a header tax code cannot express that. Where determination is left to a person choosing from a dropdown the error rate is never zero, and the errors surface in the worst possible order: as a pattern in a return, months after the habit formed.

The purchase side has a document trap rather than a tax one. Whether a cost paid on a client's behalf is a disbursement or a recharge is decided by facts existing at the moment somebody takes the receipt, and a system that cannot attach that cost to an engagement the same afternoon has already answered by default.

Corporate tax: the chart of accounts decides the return

Corporate tax asks about the character of a transaction — deductible or not, related party or not, exempt or not. Character is the one thing most mid-market charts of accounts record nowhere; it lives in the memory of whoever booked the entry.

The instinct is to add a field: a tick box, a tag, a note for the analysis later. It fails for a reason that has nothing to do with software — a field whose absence stops nothing gets left blank, and a blank field means nothing three months on.

Segregation works because it is not optional. If entertainment and staff welfare are two accounts, the person posting has to choose one. They may choose wrong, which is a training problem with a visible symptom. They cannot choose nothing. So anything taxed differently gets its own account, even where management reporting would happily see it combined. The chart gets longer, which people resist until the year somebody tries to unsplit an account. What corporate tax demands of a chart of accounts takes the adjustments one at a time.

E-invoicing: the invoice stops being a document you control

This is the obligation that changes the most, and it is routinely mis-sold as a connector.

The UAE has adopted a five-corner model built on Peppol, which means you do not file invoices with the tax authority yourself. The invoice leaves your system, goes to an Accredited Service Provider you appoint, is validated, is transmitted to your customer's provider, and is reported from there. There is no portal where you upload a spreadsheet at month end, and no arrangement where your ERP posts directly to the government.

What that changes is not the file format. It is when an invoice comes into existence, what must be true before it can leave, and what happens to it afterwards. A document that fails validation has not been issued, which makes a rejection a revenue event rather than a technical one — the whole mechanism, and what breaks first.

Master data becomes the constraint. A structured invoice is a set of assertions, each drawn from a field, each validated by machine before the document is allowed to move. Counterparty tax registration numbers must be present, in the right field, and fifteen digits — a data-cleaning exercise across every customer you have ever invoiced, not a configuration step. Units of measure must be coded rather than typed. Items must carry a tax classification decided by somebody rather than inferred from a product name by whoever happens to be invoicing.

That work runs in sequence rather than in parallel, and the sequence is why the timeline is longer than the quotation says. Tax determination cannot be tested until the item master is classified, the item master cannot be classified until somebody decides which supplies are genuinely zero-rated exports, and nobody can decide that without reading the contracts those supplies were made under. So the critical path runs through the commercial team, not the implementer. The readiness work nobody quotes for is exactly this.

Sequencing matters too. Businesses at or above AED 50 million in annual revenue appoint a provider by 30 October 2026 and go live on 1 January 2027, with later dates below that threshold — read those from the Ministry of Finance's own pages rather than from a slide, because the appointment deadline has already moved once.

Payroll: a statutory date on a file whose format is not yours

Payroll is the module every programme defers, for the same reasons every time: it works today, it is sensitive, HR is not ready, phase two. Together they leave a company that cannot state what a completed job cost, and that has a statutory payment date attached to a spreadsheet one person maintains.

The Wage Protection System file is not a report. It is a fixed-format file transmitted through an agent bank or exchange house, carrying establishment and employee identifiers and pay components. Your system either produces it correctly or produces something rejected by a party with no interest in your month end. Behind the file sits a liability nobody models: gratuity is not a straight-line accrual, the rate steps after five years of service, and an annual journal from the auditor's schedule never shows a workforce about to cross that line together. Why leaving payroll last is expensive is largely an argument about a single record.

Free zone status: three lines that do not sit on top of each other

"Free zone or mainland" is a licensing distinction, and people reason from it to conclusions about tax that do not follow.

There are three lines. Licensing, set by the zone authority or the emirate's economic department. VAT, which does not use the free zone list at all but its own list of designated zones, set by Cabinet Decision and amended from time to time. And corporate tax, where a qualifying free zone person can benefit from a preferential rate on qualifying income, subject to activity tests and de minimis limits. An entity can sit in a designated zone for VAT and fail the corporate tax tests, or the reverse.

So "is this a free zone company?" is not a configuration input. The useful inputs are which zone, whether it is designated for VAT, what the entity sells, to whom, and where the customer takes delivery. What free zone and mainland actually change in an ERP is settled in entity design, months before configuration starts.

The divergence reaches the warehouse, and there it becomes physical. Customs treats a free zone as outside the customs territory, with duty suspended until goods cross into the mainland. VAT ignores that boundary and applies its own designated-zone list to its own question, which is about what the goods are used for and where they go next. The same pallet can therefore be duty-suspended and VAT-relevant at once, and neither status is visible on a stock report that only counts quantity.

The system consequence is a location structure carrying two independent statuses rather than one: duty status, and VAT status. Most warehouse configurations carry neither, because the locations were named after aisles by whoever set up stock, years before anyone asked a tax question of a bin. So a business that has internalised one rule as "we are outside the UAE" gets the other consistently wrong, and one building holds two populations that must never be added together on a document leaving the company.

Arabic is a document problem, not an interface problem

Ask a vendor whether the system supports Arabic and the answer is yes, and the answer is true. It is answering a question you did not ask.

Three things travel under that one word and they fail independently. The interface — menus, labels, the direction the screen runs — arrives with the software, and it is what every demo shows. The data is what your company put in: product names, account names, unit names. None of it arrives translated, because none of it arrived at all. The document is what leaves the building, drawn by a different engine from the one drawing your screen, its language decided by a field on the customer record rather than by whoever presses print.

A demonstration of the first proves nothing about the third. Where an Arabic document is genuinely required, the work is a second value on every master record that reaches a printed line — a data project with a person's name on it, growing every month it is deferred. What Arabic support actually means separates the three cleanly.

Imports: the box on your return that somebody else fills in

There is one figure on a trading company's VAT return that the company does not calculate. The import box is populated from customs declarations filed against its tax registration number, by clearing agents, on dates it did not choose, from values it did not enter. Every other line comes out of the accounting system, which is why this one is the line nobody has a working paper for.

Those are two records of the same goods. One is built from the declaration, dated at clearance, valued on a customs basis and filed by an agent. The other is built from the supplier invoice, dated on receipt, valued at your own exchange rate and entered by your team. They will not agree, and they are not supposed to: the two measure different events, under different rules, on different days. The question worth asking is not whether they agree but whether anybody is required, monthly, to explain why not — because the reconciliation nobody owns is the one an auditor eventually asks for, cold, four periods late.

Money: a currency position, and a second regime

The peg hides the first of these. The dirham has been pegged to the dollar for a generation, which teaches a trading company that foreign exchange is not something it has to think about, and nothing changes on the day it starts buying in euros. The purchase order is raised the same way. The margin is quoted to the salesperson the same way. The rate used to book the receipt is whatever the system had loaded, from whenever somebody last loaded one, so nobody has decided anything and a default has decided it for them. It is never a large number in any single month, which is exactly why it is nobody's job. Somewhere between the order and the payment a position nobody chose to take is opened, held for two or three months, and closed into an account at the bottom of the profit and loss that nobody can read.

The second is a second regime entirely. A group with a Saudi entity meets a clearance model rather than a reporting one — the invoice is cleared by the authority before the customer sees it — and the proposal that follows is always a separate accounting package bought locally, already compliant. It solves this month and creates a decade of them: two item masters, two customer masters, two versions of what the group sold, and a consolidation assembled by hand by the one person who understands both. When that person leaves, the group's reported revenue rests on a spreadsheet nobody else has read, and the cost of the decision lands on whoever inherits it rather than on whoever made it. That is the pattern worth refusing at the point the local package is proposed, because it is close to unpickable afterwards. Holding two e-invoicing regimes inside one ERP is the better answer, but only once you know exactly where the two regimes differ.

The three master-data facts underneath almost all of it

The failures above collapse into a short list. Almost every compliance answer a UAE system cannot give is missing one of three facts, none of which lives on a transaction.

Who the counterparty is, and where they are established. Not an address as free text — an establishment, as a classification. That one fact decides the place of supply, whether an export is genuinely zero-rated, whether a sale is qualifying free zone income and whether an invoice can be transmitted. In most systems it is a line of an address somebody typed years ago.

What the thing being sold or bought actually is. A tax classification on the item or service master, decided once rather than inferred each time from a product name. It decides the rate, the customs treatment and half the fields in a structured invoice, and most item masters were built to make stock work, not to answer that.

Whether the counterparty is related to you. A flag on the master record, never on the transaction: related-party status belongs to the counterparty, and a per-transaction flag is wrong within a quarter.

The archive, which your provider does not solve for you

The Federal Tax Authority stated on 28 August 2025 that both Taxable Persons and Exempt Persons must retain relevant records for at least seven years following the end of the tax period to which they relate. Obligations change, so confirm the current position before designing around it. Read the shape rather than the number: seven years outlasts your ERP version's supported life, most provider contracts, and the tenure of whoever set it up.

Retention also runs in the opposite direction from a second obligation, and the two are rarely held in one head. Tax law says keep it for seven years; the personal data regime asks what you hold about identifiable people, why, and for how long — and an ERP holds far more of that than anyone assumes, because payroll, recruitment, customer contacts and CCTV integrations all land in it. Where personal data actually sits in the systems you already run is a mapping exercise, and the answer to "may we delete this" is frequently no for the tax record and yes for the copy of it somebody exported.

Three things get mistaken for an archive. The transaction database is not one: it holds rows a later version of the software will reinterpret, and a reinterpreted row is not the document you issued. The PDF you emailed is not one either, once the transmitted artefact is the document. And your provider's retention is not yours. It is theirs, governed by a contract with an end date, which is why the archive and exit clauses are the ones you will need years after everyone who negotiated them has left, and why choosing that provider deserves more scrutiny than three quotes.

What to do before the next deadline

The test for an archive is not whether you have backups. It is whether you can produce one named document, in the form it was issued, on request, without a person and a week. Replace a system, keep the old one "for the records", let the licence lapse, and you have an archive nobody can open.

The window for the rest is narrow — after the audit closes, before the new financial year is far enough along that changes mean restatement. In order.

Trace last period's figures. Take the last VAT return and the last corporate tax return with the working papers, and for every figure write down which of the three sources it came from. That gives a ranked list with a defensible reason for each item. The exercise usually ends at the same place — a spreadsheet standing between the ledger and the return — and which specific transactions force that spreadsheet to exist is a short and fixable list rather than a permanent condition.

Fix the three master-data facts. Counterparty establishment, item classification, related-party flag. Deduplicate first, or you will classify duplicates separately and disagree with yourself.

Make those fields mandatory. Every classification decided above is worthless if it can be left blank — the cheapest step on the list and the most often skipped, because it draws complaints in week one and shows nothing for a quarter.

Decide where the archive lives, and write it down. Not the backup policy — the retrieval path for one named document, seven years out, on software that does not exist yet.

Put the recurring obligations somewhere other than a person's head. Each needs a trigger, a lead time, a named owner and evidence it was done, and most firms hold three of those four in one person's memory until the month that person takes leave.

Only after those five is a system question worth asking, and the answer is rarely the product. Software gets replaced on the strength of a demonstration and the same returns get produced the same way afterwards, because nothing in the demonstration touched the point. The point is whether the facts a return needs are captured by somebody, at the moment of the transaction, in a field they cannot skip. Everything else is decoration on that one question, and a vendor who cannot name those fields against your own data has not looked at it.

Where nobody captures them, and no configuration decision has ever been taken about it, that is not a compliance problem with a tax adviser's name on it. It is a systems programme with a filing date attached, sequenced around the returns it has to keep producing while it runs, and how we would run one is published in full rather than described in a meeting.