Why the Tax Data Problem Is Bigger Than Your ERP, and What to Do About It

There is a conversation that happens with remarkable regularity during enterprise resource planning (ERP) implementation projects across the Gulf Cooperation Council (GCC). The tax team asks about tax functionality. The systems integrator reassures them that it will be handled. “The tax module will be switched on,” they are told, or some variation of that phrase. And the tax team, under pressure and trusting the process, moves on.

What “switching on” the tax module typically means in practice is that the system has been configured to record a tax code against a transaction. It does not mean the tax determination logic has been reviewed by a tax professional. It does not mean the chart of accounts has been structured to produce the data a compliance team needs. It does not mean the gap between what the system records and what a value-added tax (VAT) return, a Corporate Tax computation, or a Transfer Pricing file requires has been examined, let alone closed.

The tax module is switched on. The tax data problem has just begun.

The ERP Was Never Built for Tax

This is not a criticism of ERP vendors or the system integrators. It is simply a reflection of what these systems were designed to do. An ERP exists to run the business, close the books, manage the general ledger, process transactions, and report numbers to management and auditors. Tax is not its first language. It is a language bolted on later, and different systems, built for different kinds of businesses, speak it with very different levels of fluency.

The data a tax function depends on, the correct classification of a transaction, the split between qualifying and non-qualifying Free Zone income, the right withholding tax treaty rate, and the related-party flags a Transfer Pricing analysis lives or dies on, sits in fields that were never configured with tax in mind and that no one is monitoring. Often, the system could do better: there is tax functionality, along with broader system capabilities, that could be put to work. The integrator building your system is an expert in ERP, not in the United Arab Emirates (UAE) Corporate Tax regime or in the way the Federal Tax Authority (FTA) reads a VAT return, so much of that capability sits dormant and the configuration defaults to accounting logic.

The tax logic is left for someone to reconstruct later. That someone is your tax team.

The Data Isn’t Even All in One Place

Suppose for a moment that the ERP was configured perfectly for tax. The problem would not disappear because the data a tax function needs rarely lives in the ERP alone. It is scattered across a point-of-sale system, a project-management platform, a separate billing engine, and an expense tool, each capturing a slice of the picture at a level of detail that never fully feeds through into a single place.

There are usually two paths to this fragmentation, and they arrive at the same destination. The first is acquisition: a group grows by buying other businesses and inherits a patchwork of systems that were never meant to reconcile, different charts of accounts, different configurations, and different settings, held together by data feeds bridging the gaps. The second is organic: modules and tools added over years, each configured by whoever happened to be in the room that quarter, with no one holding the thread for tax. With different histories, identical outcomes, and no single source of truth, the tax team is left to stitch the picture together every reporting cycle.

Why Tax Ends Up Working Outside the System

Faced with a system that cannot give them what they need, tax teams do the rational thing. They build spreadsheets. This is not a sign that the team is behind the times; it is a sign that the system cannot keep pace with them.

Tax moves quickly, a change in law, a new position on Free Zone income, or a one-off restructuring, but the system moves slowly. Changing something as simple as a rate or a band can sit in an IT queue for weeks, behind customer-facing work that will always be judged more urgent. These systems can hold rules-based logic, and many now include a growing layer of AI capability, but both are only as good as the data already inside them, and improving that data is precisely the kind of request tax struggles to get prioritised. So tax fills the gap the only way it can at speed: in a workbook.

Take one example any group of size will recognise. Most maintain two sets of books, one under local rules and one under International Financial Reporting Standards (IFRS), and the two must be reconciled, foreign-exchange movements tracked, and deferred tax computed across the areas where tax and accounting diverge. Depreciation is the classic case: the rate the authority allows is rarely the rate the accountant books, so the difference must be calculated and then carried forward, year after year. The ERP does not hold that logic because it was never asked to, so it lives in a model that one person updates each cycle.

The real tax computation, the adjustments, the deferred-tax roll-forwards, and the judgement the system was never built to hold, ends up on one person’s laptop, which brings us to the risk almost no one prices. If that person leaves, the logic leaves with them: undocumented, unreviewed, gone. We asked a version of this question in the first article of this series, and it bears asking again. If the person who builds your computation resigned tomorrow, would your next filing survive?

There is a quieter cost, too, paid every cycle. When a tax function spends most of its energy extracting and cleaning data, little is left for the work that creates value, the analysis, the planning, the judgement a business is really paying for. The split we see repeatedly is roughly 80/20: 80% spent wrestling data into shape and 20% spent doing tax. It should be the other way around.

The Digital Trail Regulators Will Demand

In the previous article, we argued that the government has, in effect, joined your finance team, permanently. E-invoicing and real-time reporting mean the regulator increasingly sees your transactions as they are created, not months later in a tax return. What that changes is the nature of the review.

Authorities here, as they already do globally, will reconcile not just within a single tax but across taxes: e-invoicing data against the VAT return, Pillar Two data against country-by-country reporting, and both against the Corporate Tax provision. The numbers are expected to tie up automatically and at scale. This is where a computation built in a spreadsheet, sitting outside the system, becomes a liability: when a number cannot be traced cleanly back to the transaction that produced it, that gap is exactly what an auditor looks for, and exactly what you will struggle to defend.

When the single version of the truth has to live outside the ERP, and for the reasons above it often must, the discipline is to reconcile or journal it back into the system wherever you can and, at the very least, keep an unbroken digital trail: from source data, through every test, change, and calculation, to the number you finally submit. The audit trail has stopped being a matter of good housekeeping. It is now what determines whether a position holds when a regulator looks closely.

What Good Looks Like

None of this is an argument to tear out your ERP. Treat it as what it is: a source of data, an important one, but not the only source and not, on its own, your single version of the truth. The work that turns scattered data into something tax can rely on happens in the layer between your systems and your tax function.

In practice that means the unglamorous but decisive work of data plumbing: pulling data from the ERP, blending it with data from other sources where it resides, then automating the repetitive testing, validation, and reconciliation that today consumes your team’s week. Build drill-down dashboards so the numbers can be interrogated, apply machine learning to surface insights buried in the data, and feed the result straight into your tax software or the government portal. The encouraging part is how much of this is unlocked from systems you already own. In business as usual, the task is simply to help tax get the most out of what it has.

But there is one moment when far more is possible, and most businesses miss it: the implementation of a new ERP. That is tax’s single best chance to design quality from the start, and the striking thing is how much can be achieved without adding cost, complexity, or time, provided someone in the room knows what good looks like. Better still, the work is funded by the broader programme budget, not tax’s own. The mistake is to let the system be built and then ask it to do tax’s job. Get tax into requirements gathering, ideally, into vendor selection, and you change what the system is capable of before a line of it is configured. That is the difference between tax inheriting a problem and tax designing it out.

Where to Start

Start honestly with three questions:

1. Could we run a return straight from the system with no spreadsheets and trust that it would be right?
2. Do we have a single source of truth for tax data, or is it scattered across systems and laptops?
3. If the person who builds our computation left tomorrow, would the next filing survive?

If the answer to any of these makes you uncomfortable, you do not have a people problem. You have a data problem, and data problems are fixable, usually without replacing a thing.

The data is there. In most cases, it always has been. It just needs someone who understands tax to go and find it.

If this article raised questions about your own tax function, we welcome the conversation. Reach out to Nimish Goel or Andrew Burman to discuss how these ideas apply to your organisation