VAT Functional Gap Analysis

The impact assessment is systems-focused: it maps which systems generate invoices, where structured data fields exist or are missing, and how large the technical transition gap is. The functional gap analysis is tax-focused: it tests whether the VAT treatment your systems currently apply — the tax codes, the zero-rating logic, the reverse-charge handling — is actually correct and will remain correct once every invoice is reported to the FTA in near real time rather than reviewed before periodic filing. Both are needed; neither substitutes for the other.

Today, if a transaction is miscoded, a business typically has until its next periodic VAT return to catch and correct it internally before the FTA sees the summarised figure. Under the UAE's Continuous Transaction Control e-invoicing model, invoice data is reported through Accredited Service Providers as each invoice is issued, which narrows or removes that internal correction window for that specific transaction. A systemic miscoding pattern that previously surfaced only as a small return-level rounding difference becomes individually visible, transaction by transaction, as it happens.

Common findings include zero-rated export supplies coded without the supporting evidence FTA guidance expects, reverse-charge transactions missing their offsetting output-side entry, exempt supplies (certain financial services, residential real estate, bare land) inconsistently distinguished from standard-rated ones, Designated Zone transactions treated as ordinary mainland supplies, and credit notes not clearly linked back to their originating invoice's tax treatment.

Both, and the transaction sampling is the more revealing part. A tax-code table can look entirely correct in system settings while transactions are still being coded incorrectly in practice — by manual override, by a team member unfamiliar with the correct code, or by a transaction type the system was never properly configured to handle. We pull a representative sample of actual invoices, credit notes, and debit notes and test what was actually recorded against what should have been recorded.

The same transaction data that determines VAT treatment also feeds UAE Corporate Tax computations under Federal Decree-Law No. 47 of 2022 — taxable income figures, related-party transaction characterisation, and, for free zone entities, the Qualifying Free Zone Person qualifying-income analysis. A VAT logic gap frequently signals a parallel Corporate Tax data-quality issue, since both draw on the same underlying invoice and ledger records. We flag these overlaps as part of the review rather than treating VAT and Corporate Tax as unrelated workstreams.

Yes, and free zone entities often need it more, not less. VAT treatment of supplies into, out of, and within a Designated Zone follows specific rules that are easy to miscode in a standard chart of accounts, and where a free zone entity also holds Qualifying Free Zone Person status, related-party and cross-entity transaction characterisation adds a further layer that a generic VAT setup is unlikely to have captured correctly by default.

A Designated Zone is a specific free zone area that, for UAE VAT purposes, is treated as outside the UAE for certain supplies of goods under conditions set out in VAT law and FTA guidance, meaning the VAT treatment of goods moving into, out of, and within it can differ materially from an ordinary mainland or non-designated free zone supply. Businesses operating in or trading with a Designated Zone need their VAT logic specifically tested for this treatment, since a standard tax-code table rarely distinguishes it correctly out of the box.

For a single-entity business with moderate transaction complexity, the core analysis — configuration review, transaction sampling, and gap report — typically runs over several weeks. Businesses with multiple entities, free zone and Designated Zone exposure, or higher transaction volume across more supply types will take longer, since the transaction sampling needs to cover each distinct scenario meaningfully rather than a single generic sample.

PNPC delivers a prioritised, specific correction roadmap and can support or directly assist with implementing tax-code and process corrections in coordination with your finance and IT teams. Whether PNPC leads implementation or your internal team does, with PNPC reviewing, depends on the engagement scope agreed upfront and the client's internal capacity and system access arrangements.

Before, ideally, or at least in parallel. Correcting VAT logic after an ASP has already been selected and integration work has begun means any tax-code fix has to be retrofitted into a configuration that may already assume the old, incorrect logic. Sequencing the functional gap analysis alongside or just ahead of ASP Selection Advisory means the corrected logic is what actually gets built into the integration from the outset.

The core VAT treatment rules tested come from Federal Decree-Law No. 8 of 2017 on Value Added Tax and its associated Executive Regulations and FTA public clarifications, covering standard-rated, zero-rated, and exempt supply categories, and the reverse-charge mechanism. The e-invoicing-specific structured-data and Continuous Transaction Control requirements are drawn from Ministry of Finance and FTA public communications on the UAE e-invoicing programme, which continue to be refined as the programme's phased rollout progresses — we track current guidance rather than relying on early-stage announcements alone.

Yes, and this is a common and sensible starting point. The Ministry of Finance has indicated a phased rollout across taxpayer segments, and a business does not need a confirmed mandate date to benefit from testing whether its existing VAT logic is currently correct — that value exists independently of e-invoicing timing, and it means the business is not starting its e-invoicing-specific preparation from a position of unknown tax-logic risk.

A general VAT health check typically looks backward across historical filing periods to assess audit risk and identify past filing errors that may need voluntary disclosure. A VAT Functional Gap Analysis is forward-looking and e-invoicing-specific: it tests whether the current VAT logic embedded in your systems will continue to produce correct results once every transaction is individually and continuously reported, which is a narrower but more urgent question for businesses approaching an e-invoicing mandate.

Yes. Where entities are registered as a single VAT Tax Group, supplies between group members are generally disregarded for VAT purposes, but the group's single TRN and the correct legal entity attribution still need to be reflected accurately in the structured data each invoice carries. We test that the group's internal disregard treatment is applied consistently and that invoicing correctly identifies which member entity is the actual party to an external transaction.

Where a business makes both taxable and exempt supplies, the apportionment methodology used to determine recoverable input VAT is tested for consistency and for whether the underlying ratio has been recalculated recently enough to still reflect the business's actual current revenue mix. An apportionment ratio set up years ago and never revisited is one of the more common causes of a materially incorrect input VAT recovery position.

Yes. We test whether input VAT recovery on categories the FTA specifically restricts — most notably entertainment expenses for non-employees and, with limited exceptions, motor vehicles available for personal use — is correctly excluded, and whether staff benefit and reimbursement categories are consistently coded rather than left to individual judgement at the point of expense entry.

We extract and test the underlying tax logic regardless of the platform — the review is not tied to any specific software vendor. A heavily customised or bespoke system typically takes longer to review, since custom automation rules affecting VAT determination need to be understood on their own terms rather than compared against a standard, well-documented platform configuration.

The sample is scaled to transaction variety and volume rather than a fixed count — every distinct supply-type scenario the business handles (standard-rated, zero-rated, exempt, reverse-charge, Designated Zone, and so on) needs to be represented meaningfully in the sample, not just the highest-volume transaction type.

Yes, for most engagements. Tax-code configuration exports, transaction samples, and supporting documentation can be reviewed via secure remote access and document sharing, with scoping and findings discussions conducted over video call. On-site access is offered where a client prefers it or where system access constraints make remote review impractical.

Yes. Intercompany management fees, cost recharges, and loan arrangements between related UAE entities, or between a UAE entity and an overseas related party, are tested for correct VAT treatment — including whether disregard rules within a VAT Tax Group are being applied where relevant, and whether cross-border intercompany charges are correctly assessed for reverse-charge treatment.

Yes. Whether a cost recovered from a customer is treated as a disbursement (generally outside the scope of VAT, where the business is acting as an agent) or a reimbursable expense (generally subject to VAT as part of the underlying supply) depends on specific factual conditions, and we test whether the business's current coding practice reflects that distinction consistently rather than defaulting every pass-through cost to one treatment.

We test whether the point at which VAT becomes due on a deposit or advance payment — generally the earlier of the payment date or invoice date under the relevant tax-point rules — is correctly reflected in the system's transaction timing, rather than VAT being recognised only when the final invoice is raised.

Where relevant to the business, yes. These arrangements involve a delay between when goods are made available and when legal transfer or delivery actually occurs, and the correct VAT point of supply needs to be tested against the specific facts of the arrangement rather than assumed from the invoice date alone.

Where a business deals in goods that may qualify for the profit margin scheme, we test whether that treatment is being applied and documented correctly, since margin scheme VAT is calculated differently from the standard output-VAT-on-full-sale-price approach and needs its own dedicated tax-code and record-keeping treatment.

Each TRN is tested separately, since without a formal Tax Group registration, transactions between the related entities are not automatically disregarded for VAT and generally need to be invoiced and treated as they would between unrelated parties. We specifically test that invoicing correctly attributes each transaction to the right legal entity and TRN, rather than transactions drifting between entities informally.

We document the basis for our finding against current VAT law and FTA guidance and discuss it directly with the client, and with the prior advisor where that relationship is still active, rather than silently overriding an existing position. Tax treatment can be genuinely debatable in edge cases, and we are explicit about where a finding reflects a clear technical error versus a defensible but different interpretation.

Both. Clients receive a written, prioritised gap report documenting each finding against its specific tax code, transaction type, or process, plus a walkthrough session with the finance and tax team to discuss the findings, answer questions, and agree the correction roadmap in the same conversation rather than leaving the report to be interpreted in isolation.

The ASP's validation layer checks that an invoice is structurally complete and schema-compliant; it does not check whether the underlying VAT treatment applied to a line item is substantively correct. A VAT Functional Gap Analysis addresses the substantive correctness question directly, so that by the time ASP integration testing begins, the tax logic being validated structurally is also the tax logic that is actually right.

There is no single fixed interval — PNPC recommends re-testing whenever the business's transaction mix changes materially (new products, new markets, new entities), or when the FTA or Ministry of Finance publishes further e-invoicing scope guidance, rather than treating the initial analysis as permanently valid.

Yes. Reverse-charge accuracy and input VAT recovery both depend on how inbound invoices are received, coded, and matched against purchase orders, so the review tests both directions of transaction flow rather than only the sales side that is most visible under a sales-invoicing-focused e-invoicing rollout.

There is still value in an early tax-logic diagnostic as part of registration readiness — testing how the business's systems would determine and code VAT treatment before both the registration obligation and any future e-invoicing mandate apply, so the systems are not being configured for VAT compliance and e-invoicing readiness at the same time under time pressure.

Where related-party transactions carry both a VAT treatment question and a transfer pricing question — an intercompany management fee, for example — we flag the overlap so the pricing basis being used for Corporate Tax related-party documentation is consistent with how the same transaction is being invoiced and VAT-coded, rather than the two workstreams developing inconsistent positions independently.

Yes, where agreed as part of the engagement scope. Briefing sessions for the finance team on corrected tax codes, updated transaction-entry procedures, and how to handle transaction types that previously relied on manual override help the corrections actually stick, rather than the old informal workarounds quietly returning within a few months.

We flag the finding for consideration under the FTA's Voluntary Disclosure process through the EmaraTax portal, since proactively disclosing a discrepancy is generally treated more favourably than having the FTA identify it independently. We do not recommend silently correcting the position only in a future period without addressing the historical discrepancy.

Yes, where relevant to the business. Certain free supplies of goods or services can trigger a deemed-supply VAT obligation under specific conditions set out in VAT law, and we test whether the business's current practice correctly identifies and codes these situations rather than treating every free giveaway as automatically outside the scope of VAT.

We test whether currency conversion is applied consistently and whether the AED-equivalent value is correctly and completely captured on tax invoices as FTA rules require, since a structured e-invoice needs a complete, consistent currency treatment rather than a converted figure calculated inconsistently invoice to invoice.

Yes, where relevant. Certain government or statutory fees disbursed on a customer's behalf may sit outside the VAT base if the disbursement conditions are genuinely met, and we test whether the business's current practice reflects that correctly rather than defaulting every pass-through charge to a single, potentially incorrect treatment.

Yes, at a process level. We test whether the business has a mechanism to identify and track receivables that may qualify for bad debt VAT relief under the conditions set out in VAT law, since relief depends on specific conditions being met and evidenced, and a business with no tracking process in place is unlikely to be claiming relief it may be entitled to, or worse, may be claiming it without meeting the conditions.

Where relevant to the business, we test how sales made through a third-party marketplace or platform are being VAT-coded, including how platform fees and the underlying sale to the end customer are treated, since marketplace arrangements can introduce agency and disclosed-versus-undisclosed-principal questions that a standard direct-sale tax code does not address.

Where relevant, yes. Retention amounts and milestone billing on long-term contracts raise specific questions about when VAT is actually due — on invoicing, on milestone certification, or on eventual retention release — and we test whether the business's current practice applies the correct tax point consistently across its contracts.