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.

Fee is driven primarily by transaction variety — how many distinct supply-type scenarios the business actually handles — not by headline revenue. A single-entity domestic business is priced differently from a multi-entity group with free zone, Designated Zone, and cross-border exposure. The number of TRNs and entities involved, the quality and exportability of the tax-code configuration, and whether the accounting system is a standard platform or heavily customised are the other primary drivers. PNPC confirms a fixed or capped fee in the engagement letter once scoping is complete, not before.

Yes. A single mainland trading entity with simple domestic supplies is typically the fastest to review. A free zone entity, particularly one with Designated Zone exposure or Qualifying Free Zone Person status, adds a dedicated testing layer for zone-specific treatment. An offshore holding entity, such as a JAFZA Offshore or RAK ICC vehicle with no direct VAT-registered trading activity of its own, generally has limited functional gap analysis scope, since the review depends on there being actual invoiced transactions to test — the analysis instead focuses on any operating subsidiary sitting underneath it.

Where deregistration or wind-down is already underway, the priority shifts from forward-looking e-invoicing readiness to confirming that the final VAT returns filed before deregistration are correctly coded, since a historical VAT logic gap in a final return can still generate an FTA query after deregistration is complete. A full forward-looking functional gap analysis scoped for e-invoicing readiness is generally not warranted for an entity that will not be operating through the e-invoicing mandate's go-live date.

It can be either. Most clients engage PNPC for an initial diagnostic ahead of their e-invoicing mandate date, followed by periodic re-testing triggered by a material change in transaction mix, a new entity, or updated FTA/Ministry of Finance guidance, agreed at handover. Some larger or multi-entity groups with frequent structural change prefer a standing arrangement with a defined annual review point rather than waiting for a specific trigger event.

India's GST e-invoicing operates on an Invoice Registration Portal model, where invoices above a specified turnover threshold are reported and receive an Invoice Reference Number before or shortly after issuance — a materially different technical and legal architecture from the UAE's Peppol-based, Accredited Service Provider Continuous Transaction Control model, under an entirely different tax law, Federal Decree-Law No. 8 of 2017, rather than India's CGST/IGST framework. We flag this distinction specifically for India-UAE groups, since finance staff experienced with the Indian model sometimes assume UAE requirements or timing will mirror it, which they do not.

We work with what is available — a spreadsheet-based tax-code mapping, manual invoice templates, or a hybrid of systems can all be tested, though the review takes longer since the 'configuration' itself is less centralised and more prone to inconsistent manual application than a true ERP tax-code table. This is common among smaller and mid-sized UAE businesses and is not itself a barrier to running the analysis.

English-language system exports, invoices, and supporting documentation are generally sufficient for the review, since PNPC's UAE practice operates bilingually and FTA-facing documentation is commonly maintained in English for VAT purposes. Where a specific document — a customs export declaration, for example — is only available in Arabic, we work with it directly rather than requiring a separate translation exercise, unless the client's own process requires a translated record for internal purposes.

Where relevant to the business, yes. Drop-shipping and triangulation — where goods move directly from a supplier to an end customer without passing through the invoicing party's own possession — raise specific questions about the correct place of supply and whether the transaction is properly a UAE-taxable supply at all, and we test whether the business's current coding reflects the actual physical and contractual flow of goods rather than defaulting to a standard domestic sale treatment.

We test whether a cost recharge for seconded or loaned staff between related entities is treated consistently with its actual substance — whether it constitutes a taxable supply of staff services or a genuine disbursement of payroll cost — since UAE group structures frequently move staff between related entities informally without applying consistent VAT treatment to the recharge.

Yes, where relevant. Commercial property leasing is generally standard-rated while qualifying residential leasing is generally exempt, and mixed-use developments can require a defensible apportionment between the two. We test whether the business's tax-code configuration correctly distinguishes commercial from residential space and applies the corresponding treatment consistently across its property portfolio.

Yes, for clients operating in those sectors. Certain healthcare and education services qualify for zero-rating under specific conditions in VAT law, and we test whether the business's current coding correctly distinguishes qualifying services from ancillary or unrelated supplies that do not meet the zero-rating conditions, since the two are frequently bundled together on a single invoice without being separately coded.

Where relevant, yes. Islamic finance products such as Murabaha, Ijara, and Sukuk-related structures can involve multiple contractual legs standing in for what is economically a single financing arrangement, and VAT treatment needs to reflect the underlying economic substance rather than each contractual leg in isolation — a genuinely specialist area we test with particular care for regulated financial free zone clients.

We report the residual gap immediately rather than treating pre-go-live validation as a formality, identify whether it reflects an incomplete correction, a new issue introduced during implementation, or a transaction type the original correction did not anticipate, and recommend whether go-live should proceed with a defined workaround for the affected transaction type or be delayed until it is resolved.

The dated gap report, the specific transaction sample tested, and the documented basis for each finding and correction form a durable evidentiary record that can be produced years later to demonstrate the business took a proactive, structured approach to VAT accuracy at a specific point in time — materially more persuasive to an FTA reviewer than an undocumented assertion that 'VAT has always been handled correctly.'

Yes. A UAE branch of a foreign company is generally treated as an extension of the same legal person for tax purposes but still needs its own VAT registration and correct invoicing where it makes taxable supplies in the UAE, and we test whether the branch's invoicing and tax-code setup correctly reflects its own UAE supply activity rather than being conflated with the foreign parent's home-jurisdiction tax position.

Yes, where relevant. Certain precious metal and stone transactions between VAT-registered businesses can fall under a reverse-charge special scheme distinct from the general import reverse-charge mechanism, and we test whether the business's tax-code configuration correctly applies this scheme rather than defaulting to standard-rated or general reverse-charge treatment.

Each TRN's tax-code configuration and transaction sample is tested individually, since errors are not automatically shared or corrected across entities, but findings are then consolidated into a single group-level correction roadmap prioritised by entity risk, so the client sees both entity-specific detail and an overall group picture rather than five disconnected reports.

The UAE VAT functional gap analysis and any India GST-side review are distinct engagements under different tax laws, but PNPC coordinates them where the same intercompany transactions and pricing appear on both sides, since an intercompany charge tested for UAE VAT purposes and that same charge's Indian GST and transfer pricing treatment should be viewed as one connected commercial arrangement, not two unrelated tax questions handled by disconnected teams.

The core testing scope and fee are set at the outset based on transaction variety and entity complexity, not on how many gaps are ultimately found — a business that turns out to be largely compliant is not charged less retroactively, since the value of the engagement is the assurance itself, confirmed through the same testing effort regardless of outcome. Where a client wants a lighter-touch, lower-cost review because they believe their VAT logic is already simple and well-controlled, that should be discussed and scoped explicitly at the outset rather than assumed after the fact.

Waiting for a confirmed mandate date before starting, on the assumption there is no urgency until then. Because the underlying VAT logic testing has value independent of e-invoicing timing, and because correction, staff training, and pre-go-live validation all take real time once gaps are identified, businesses that wait for their specific mandate date to be announced before beginning routinely end up compressing correction and validation work into a much shorter window than is comfortable.