UAE E-Invoicing and VAT Groups: What the Grace Period Means for NetSuite

The UAE Ministry of Finance has confirmed a 24-month grace period for intra-VAT group transactions under the national e-invoicing mandate. Running from January 1, 2027 to December 31, 2028, this provision has attracted significant attention from finance and IT teams at holding groups operating on NetSuite. The relief is real, but narrower than many assume. For businesses running multiple subsidiaries on a single NetSuite account, the grace period does not remove the compliance obligation: it defers one specific subset of it. Understanding exactly what falls inside and outside that boundary is the difference between a well-scoped implementation and a costly second integration cycle in late 2028. This post covers how UAE e-invoicing integration guide for NetSuite architecture decisions interact with VAT group structures, and what your build plan should account for from the outset.

What the Grace Period Actually Covers

The grace period applies exclusively to supplies made between members of the same UAE VAT group. A VAT group is a formal registration with the Federal Tax Authority (FTA) where multiple legal entities are treated as a single taxable person and share one Tax Registration Number (TRN). Transactions between those entities are treated as outside the scope of VAT, and the 24-month grace period extends that logic to e-invoicing: from January 1, 2027 through December 31, 2028, those intra-group supplies do not need to travel through the Peppol network.

That is the entire scope of the relief. It does not cover:

• Transactions between related companies that are registered separately for VAT (different TRNs)
• Sales from any VAT group member to external customers
• Purchases from external suppliers received by any VAT group member
• Intercompany flows between subsidiaries that are not part of the same formal VAT group registration

Every other transaction is subject to full e-invoicing obligations from your phase go-live date. Businesses that conflate “intercompany” with “intra-VAT group” risk leaving a substantial volume of taxable transactions outside their compliance scope.

How UAE VAT Groups Work and Why They Complicate E-Invoicing

Under UAE VAT law, a VAT group registration consolidates multiple entities under a single TRN. This is common in large holding structures: a parent company and its wholly owned subsidiaries may apply to be treated as one taxpayer. The FTA grants the registration, and from that point, supplies between group members are disregarded for VAT purposes.

The complication for e-invoicing arises from how the Peppol network identifies senders and receivers. Each participant on the UAE Peppol network has an endpoint identified by a Peppol ID, which in the UAE scheme uses the format 0235:TIN. If two subsidiaries share a TRN because they are in the same VAT group, they share the same Peppol identifier by default. The network cannot distinguish between them as separate sender-receiver pairs in the standard configuration.

This is not a theoretical edge case. Many large UAE conglomerates have five to fifteen entities under a single VAT group registration. Each may be a separate legal entity with its own NetSuite subsidiary. When those subsidiaries exchange goods or services, the document flow that would normally constitute an e-invoice involves two endpoints with identical TINs, which creates a structural conflict in Peppol routing. Refer to the UAE FTA e-invoicing requirements and phase thresholds for the full FTA technical specification context.

The NetSuite Multi-Subsidiary Problem

NetSuite’s OneWorld architecture allows each subsidiary to be configured as a distinct operating entity with its own tax registration, currency, and reporting structure. In a standard UAE e-invoicing implementation, each subsidiary that issues or receives e-invoices connects to an Accredited Service Provider (ASP), which in turn handles the Peppol network submission.

When two subsidiaries share a TRN, the ASP configuration becomes non-trivial. The ASP must be able to accept documents from both subsidiaries and route them correctly, even though both present the same Peppol ID. Some ASPs handle this through subsidiary-level identifiers appended to the TRN, others through separate ASP accounts mapped to the same TRN. The specific mechanism depends on the ASP’s technical implementation of the UAE Peppol profile.

What this means in practice for a NetSuite implementation:

• Each subsidiary in the VAT group needs its own ASP connection configuration, even if the TRN is shared
• Intercompany transaction workflows in NetSuite (IC journals, IC sales orders) must be mapped to the correct document type for e-invoicing purposes
• The ASP must be configured to suppress or handle intra-group documents during the grace period, then activate them from January 1, 2029
• Testing environments need to replicate the shared-TRN scenario accurately to catch routing errors before go-live

If you are working through how to integrate NetSuite with a UAE e-invoicing service provider, the VAT group configuration should be surfaced as a requirement in the scoping phase, not discovered during UAT.

What Happens After December 31, 2028

When the grace period expires on January 1, 2029, all supplies between VAT group members become subject to the standard e-invoicing obligation. At that point, every intercompany invoice between entities sharing a TRN must travel through the Peppol network via an ASP, just like any invoice issued to an external customer.

The volume implications can be significant. For a holding group with ten subsidiaries that trade internally, the intra-group invoice count may match or exceed external customer invoices. Finance teams that have relied on the grace period as a reason to exclude intra-group flows from their implementation will face a compressed build timeline in the second half of 2028, with the added complexity of modifying a live production system.

There are also data retention obligations that apply from the moment e-invoicing goes live. UAE FTA requires e-invoice records to be retained for 5 years (7 years for real estate transactions). If intra-group invoices are not processed through the Peppol network during the grace period, those records exist only in NetSuite and ERP exports, not in the FTA-accessible audit trail. When the grace period ends, the retention clock for post-2029 intra-group invoices starts, but there is no retroactive capture of 2027 and 2028 intra-group flows. This is an acceptable outcome under the current rules, but businesses should document it explicitly as part of their compliance posture.

For a full picture of the timelines involved, see our post on UAE e-invoicing deadlines for 2027.

Phase Thresholds and VAT Group Aggregate Revenue

One aspect of the VAT group rules that directly affects go-live dates is how the FTA applies the revenue threshold for phase assignment. The threshold is AED 50 million in annual revenue. Businesses at or above that figure fall into Phase 1, with a mandatory go-live of January 1, 2027. Those below the threshold fall into Phase 2, with a go-live of July 1, 2027.

For VAT groups, the FTA assesses the threshold against the group’s aggregate revenue, not each member entity’s individual revenue. This has a material consequence: a holding group where no single subsidiary exceeds AED 50 million, but whose combined group revenue does, is a Phase 1 taxpayer. All group members must comply by January 1, 2027, regardless of their individual size.

NetSuite implementations for Phase 1 VAT groups are already in scoping and build. The window to complete configuration, ASP onboarding, UAT, and parallel-run testing before January 1, 2027 is tighter than it appears, particularly for multi-subsidiary structures with complex intercompany flows.

The Case for Building Intra-Group Capability Now

The grace period is a legitimate compliance relief measure. It is not a reason to defer the technical work of configuring intra-group e-invoicing flows in NetSuite.

The technical scope of connecting two VAT-group subsidiaries to the Peppol network is substantially similar to connecting any two trading parties. The ASP configuration, document mapping, NetSuite workflow triggers, and error handling all need to be built and tested regardless of when the obligation takes effect. Building this during the Phase 1 or Phase 2 implementation means the work happens once, within the same project, using the same integration team and test environment already in place.

Deferring it means a separate project in 2028, touching a production system, with less runway before the January 1, 2029 deadline. The cost and risk profile of that second cycle is materially worse than absorbing the intra-group scope into the initial build.

Aaxonix’s standard recommendation for VAT group clients on NetSuite implementation and integration services is to configure subsidiary-level ASP connections for all entities, including intra-group pairs, during the initial implementation. The grace period configuration then becomes a switch in the ASP routing rules, not a structural gap in the integration.

The intra-VAT group grace period gives holding structures breathing room on one specific set of transactions. It does not simplify the underlying NetSuite architecture decisions, and it does not extend to the broader intercompany landscape. Businesses that scope their e-invoicing implementation around the full entity structure, including VAT group subsidiaries, will be in a materially better position when the January 1, 2029 deadline arrives, without the cost and disruption of a second build cycle.