UAE E-Invoicing for Free Zone Companies Using NetSuite: What Changes

UAE e-invoicing applies to free zone companies. Being registered in JAFZA, DIFC, ADGM, DMCC, Dubai South, or any other free zone does not grant an automatic exemption. What it does mean is that your transactions may fall under a specific scenario in the UAE Electronic Invoicing guidelines that carries additional data requirements beyond those for standard mainland B2B invoices. For NetSuite users, some of those requirements need custom development to satisfy. This post covers what the free zone scenario requires, where NetSuite falls short natively, and what your implementation team needs to build. For a broader overview of the programme, see the UAE e-invoicing integration guide for NetSuite.

Does the Free Zone Scenario Apply to Your Company?

The UAE Ministry of Finance Electronic Invoicing Guidelines (V1.0, February 2026) define a specific “Free Zone” scenario. A transaction falls under this scenario when any of the following conditions are true:

• The supplier is established in a free zone
• The buyer is established in a free zone
• The beneficiary of the supply is a free zone entity
• The goods being supplied are physically within a free zone
• The goods are being exported from a free zone

In practice, this means almost every invoice a free zone company issues or receives can trigger the free zone scenario. If your company is registered in JAFZA and you sell to a mainland UAE buyer, that transaction involves a free zone supplier. The scenario applies. If a DIFC-registered professional services firm bills a DMCC-registered client, both parties are in free zones, so the scenario applies twice over.

The exceptions are narrow. Companies whose activities fall under sovereign functions, specific airline passenger transport exclusions, or other categories carved out under the relevant ministerial decisions may be excluded. For the vast majority of commercial free zone businesses, assume you are in scope.

The Beneficiary Field: A New Data Requirement

This is the element that catches most free zone companies off guard. When the customer on an invoice is a free zone entity, the electronic invoice must include details of the beneficiary in addition to the customer. This is not optional and it is not the same field.

The guidelines define these two parties precisely:

• Customer: The person or entity that issued the purchase order or is the contracting party on the transaction.
• Beneficiary: The person or entity that ultimately uses, consumes, or owns what is being supplied.

For most standard B2B transactions, the beneficiary and the customer are the same legal entity. A company orders software licences for its own use: the contracting party and the end user are identical. In that case, beneficiary details still need to appear on the invoice, but they will mirror the customer record.

Where it becomes more complex is when the customer is procuring on behalf of a third party. A holding company that orders equipment to be used by a subsidiary, a procurement agent buying on behalf of a client, or a regional headquarters purchasing services that will be consumed by a local entity: in all these cases, the ultimate beneficiary differs from the buyer. Both must be recorded. If the customer has formally declared another party as the end user, that declared party is the beneficiary for invoicing purposes.

This requirement is specific to the UAE e-invoicing mandatory fields for NetSuite and goes beyond what standard invoice templates capture. It has direct implications for how your customer master data is structured and what information you collect at the point of sale.

The Transaction Type Code Flag

Each electronic invoice in the UAE system carries an 8-character binary transaction type code. Each position in this string flags a specific invoice characteristic. Position 1, the leftmost character, is the Free Trade Zone flag.

When the free zone scenario applies to a transaction, this flag must be set to “1”. If the transaction does not involve a free zone, the flag is “0”. The full 8-character string might look like this:

A standard free zone invoice with no other special characteristics would carry the code “10000000”. The integration layer is responsible for constructing this string correctly for every invoice before submission to the accredited service provider (ASP).

The participant ID format also applies to free zone companies in the same way as all other UAE VAT-registered entities: the format is 0235:TIN, where TIN is the first 10 digits of your Tax Registration Number.

What NetSuite Does Not Handle Out of the Box

NetSuite’s standard invoice functionality was not built for UAE e-invoicing compliance. The following requirements from the free zone scenario have no native equivalent in a default NetSuite configuration:

• No field on the Customer record to mark whether that entity is a free zone company
• No separate beneficiary field on the invoice or on the customer record
• No field for the 8-character transaction type code
• No logic to detect free zone involvement and set the FTZ flag automatically
• No mechanism to output these fields in the PINT-AE XML format required by UAE ASPs

The PINT-AE standard (the UAE flavour of the Pan-European Invoice Norm) defines the XML structure that all electronic invoices must conform to for submission. NetSuite cannot generate this format without custom development or a certified integration solution. This is not unique to free zone requirements; it applies to UAE e-invoicing broadly. But the free zone scenario adds specific XML elements, particularly for the beneficiary, that must be populated correctly.

NetSuite Customizations Required for Free Zone Compliance

To make NetSuite compliant for free zone e-invoicing, your implementation team needs to build the following. See also the detailed technical guidance on how to integrate NetSuite with a UAE e-invoicing service provider.

Customer Record Fields

Two custom fields on the Customer record are required:

• Free Zone Entity: A checkbox or Yes/No dropdown. When checked, this tells the integration script that any invoice involving this customer as buyer triggers the free zone scenario and the FTZ flag must be set to “1”.
• Beneficiary Name (and related contact details): A text field, or a reference to a separate entity record, capturing the beneficiary when the end user is different from the contracting customer. This field is optional for transactions where the beneficiary is the same as the customer, but the integration script must always output beneficiary data in the XML, defaulting to the customer’s own details when no separate beneficiary is specified.

Invoice Record Fields

• Invoice Transaction Type Code: A text field, 8 characters, auto-populated by a SuiteScript that runs at invoice save or before submission. The script reads the customer’s Free Zone Entity flag, determines whether the supplier (your company) is itself a free zone entity, and assembles the binary string accordingly.

The Integration Script Logic

The SuiteScript or middleware connector responsible for PINT-AE XML generation must do the following for every invoice:

1. Check whether the selling entity (your company subsidiary in NetSuite) is classified as a free zone entity.
2. Check the customer record’s Free Zone Entity flag.
3. If either is true, set position 1 of the transaction type code to “1”.
4. Read the beneficiary field on the customer record. If populated, use those details for the beneficiary XML element. If not populated, copy the customer’s legal name, address, and TRN to the beneficiary element.
5. Output the complete PINT-AE XML with all mandatory fields, the transaction type code, and the beneficiary block.

Companies with multiple subsidiary legal entities in NetSuite, some in free zones and some on the mainland, need subsidiary-level configuration. The free zone flag for the supplier must be set at the subsidiary or legal entity level, not at the invoice level.

Data Capture at Point of Sale

The technical customizations only work if the underlying data is accurate. Your sales and accounts receivable teams need a process to:

• Confirm whether each new customer is a free zone entity at the time of customer record creation
• Ask, at order or contract stage, whether the contracting party is procuring for its own use or on behalf of a third party
• Record any declared beneficiary before the invoice is issued, not after

Retroactively adding beneficiary data after invoice submission is not a compliant approach. The XML submitted to the ASP must be correct at the time of submission.

Compliance Deadlines and What to Do Now

The compliance timeline under Ministerial Decision No. 244 of 2025 applies to free zone companies on the same basis as all other UAE businesses:

The ASP appointment deadline is earlier than the go-live date because the ASP needs time to onboard your business, configure your connection, and test the integration. For companies in the first wave, the July 2026 deadline for selecting and appointing an ASP is now less than two months away. For full detail on what these dates require, see the UAE e-invoicing compliance deadlines 2027.

For free zone companies specifically, the preparation steps are:

1. Confirm your revenue threshold and which wave applies to you.
2. Map all transaction flows: which involve free zone buyers, which involve third-party beneficiaries, which cross between free zones and mainland.
3. Assess your current NetSuite configuration against the free zone-specific field requirements.
4. Engage your NetSuite implementation partner to scope the custom fields and integration script work.
5. Select and appoint an ASP before the applicable deadline.
6. Run end-to-end testing with the ASP using representative free zone invoices, including cases where the beneficiary differs from the customer.

Free zone companies have specific obligations under the UAE e-invoicing framework that go beyond the standard mandatory fields. The beneficiary requirement and the transaction type code flag are not complex concepts, but they do require deliberate attention in how your customer master data is structured and how your integration layer generates XML. Starting the NetSuite customization work now, alongside ASP selection, is the practical path to meeting the applicable deadline. NetSuite implementation and integration services from a partner with UAE compliance experience will reduce the risk of gaps in your free zone invoice data at go-live.