UAE E-Invoicing Go-Live Checklist for NetSuite Businesses

Q: What Peppol ID format does the UAE use for buyer routing?

UAE Peppol participant IDs follow the format 0235:TIN, where 0235 is the UAE Peppol scheme code and TIN is the first 10 digits of the buyer's tax registration number. If a buyer has not registered on the UAE Peppol network, your invoice submission will return a routing failure and the invoice will be rejected. Your master data readiness check should confirm that every active B2B buyer has their Peppol ID loaded in NetSuite before go-live.

Most compliance failures in UAE e-invoicing do not appear during development or sandbox testing. They appear in the first 30 days of production, when edge-case transactions hit a system that everyone assumed was ready. A Peppol participant ID that was never loaded for one key buyer. An API credential that still points at the sandbox URL. A rejection email that goes unread because no one configured alerting. These are not complex problems, but they are expensive ones when they surface at month-end close or during an FTA audit.

This checklist is for NetSuite IT managers, finance operations leads, and project managers who have completed their UAE e-invoicing integration guide for NetSuite build and are now preparing to flip the switch to production. Work through each section sequentially, get a sign-off from the responsible owner for each block, and do not proceed to go-live until every box is checked.

Open laptop displaying code next to a plush toy, set in a bright room with plants.

Why a Formal Go-Live Checklist Prevents Compliance Gaps

The UAE FTA e-invoicing requirements and compliance deadlines create a clear obligation: every qualifying B2B transaction must produce a valid, FTA-accepted e-invoice with a UUID and QR code. The FTA does not offer a grace period for production mistakes that were avoidable in testing.

Teams that skip a formal pre-go-live process typically encounter three failure patterns. First, master data issues, where customer TRNs are missing or malformed and invoices are rejected at the validation layer before they reach the FTA network. Second, configuration drift, where the sandbox build does not exactly match the production environment because credentials or endpoints were never updated. Third, silent failures, where rejections occur but no one is alerted, invoices age in a pending queue, and the finance team discovers the problem weeks later when chasing payment.

A structured checklist closes each of these gaps before they become audit findings.

Section 1: Master Data Readiness

Owner: Finance Operations

Customer and Company Data

All active B2B customer TRNs are validated and stored in NetSuite in the correct 15-digit format required by the FTA schema.
Peppol participant IDs (format: 0235:TIN) are loaded for every B2B buyer you will invoice via the UAE Peppol network.
Arabic item and service descriptions are populated in the relevant NetSuite fields for all products and services that appear on UAE invoices.
Your seller TRN is confirmed and correctly entered in NetSuite’s company information settings, not just at the customer record level.
Currency configuration defaults to AED for all UAE B2B transactions; any USD or other foreign currency invoices are correctly mapped with the exchange rate field populated.
Customer billing addresses include country code AE and emirate fields where applicable.

Section 2: Integration Technical Readiness

Owner: IT / NetSuite Administrator

This is where configuration drift most often causes go-live failures. Review the step-by-step NetSuite UAE e-invoicing integration guide for the full technical architecture before completing this section.

Credentials and Endpoints

API credentials have been rotated from sandbox to production. The sandbox key is no longer present in any active SuiteScript, connector configuration, or environment variable.
Every SuiteScript and connector configuration file pointing to an endpoint URL has been updated to the production URL. Confirm this with a string search, not just from memory.
A test invocation of the production API using a draft invoice has returned a 200-class response with a valid UUID.

Error Handling and Alerting

Error logging is enabled in the production connector and has been confirmed to write to a queryable log store (SuiteScript execution log, external log sink, or your service provider’s portal).
Email or Slack alerting is configured to notify the responsible team member within 1 hour of any rejection response from the FTA network.
Submission retry logic has been tested by deliberately triggering a failure (e.g., submitting a malformed invoice) and confirming the retry mechanism fires within the defined window without duplicating the invoice.
Rate limiting behaviour is understood: if the production API has a lower rate limit than the sandbox, batch submission scripts have been adjusted accordingly.

Section 3: FTA Sandbox Testing Sign-Off

Owner: Project Manager + IT

Test Coverage

At least 20 invoices have been submitted through the FTA sandbox environment, covering: standard B2B tax invoices, credit notes, invoices with mixed tax rate lines (standard rate and zero rate), AED-denominated invoices, and at least one USD-denominated invoice with exchange rate field populated.
Every test invoice returned a valid UUID and a scannable QR code. Both values were confirmed to be stored in the correct NetSuite custom fields.
At least two deliberate rejection scenarios were tested: one with a missing or invalid TRN, one with a schema validation error. The error response was captured, parsed, and the correction workflow was walked through end-to-end.
FTA sandbox test results, including submission logs, UUIDs returned, and screenshots of acceptance responses, have been saved in a shared location and attached to the project record as an audit trail.
A sign-off from the project sponsor or finance director confirming sandbox testing is complete has been obtained in writing (email is sufficient).

Section 4: NetSuite Configuration Sign-Off

Owner: NetSuite Administrator

Custom Fields and Status Workflow

Custom fields for UUID storage and QR code storage are present on the Invoice record, confirmed as non-mandatory at creation time (to avoid blocking manual invoices), and confirmed as auto-populated on successful submission.
The e-invoicing status custom field on the Invoice record transitions correctly through: Pending, Submitted, Accepted, and Rejected. Each status has been reached at least once during sandbox testing.
The invoice PDF template includes a rendered QR code image that is populated from the QR code field. The PDF output has been visually reviewed for a submitted invoice.
The AR team has completed a walkthrough of the submission status monitoring workflow: how to identify a rejected invoice, where to find the rejection reason, and how to initiate a correction and resubmission.
A saved search or dashboard widget showing the current e-invoicing submission queue (count by status: Pending / Submitted / Accepted / Rejected) has been built and shared with the AR manager.

Section 5: Service Provider Sign-Off

Owner: Project Manager

Provider Readiness

Production API credentials have been received from your e-invoicing service provider and have been successfully tested against the live production endpoint (not a pre-production or UAT environment).
A named go-live support contact at the service provider has been confirmed, along with their direct contact details and available hours on go-live day.
The SLA for rejection turnaround notification (the time from FTA rejection to provider alerting your system) is confirmed in writing. Any SLA above 2 hours should be escalated before go-live.
Log retention of at least 5 years has been confirmed in writing with the provider, in line with FTA record-keeping requirements. If the provider cannot confirm this, local log archiving must be configured.
The provider’s data residency position for UAE transaction data has been reviewed and accepted by your legal or compliance team.

Section 6: Post-Go-Live Monitoring Plan (First 30 Days)

The first month of production carries the highest risk. Volume increases, edge cases not seen in testing emerge, and the AR team is still building muscle memory around the new workflow. Define your monitoring cadence before go-live, not after.

Cadence	Activity	Owner
Daily (first 2 weeks)	Review submission queue dashboard. Confirm zero invoices have been stuck in Pending for more than 24 hours.	AR Manager
Daily (first 2 weeks)	Check service provider portal or log for any rejection responses received overnight.	NetSuite Admin
Weekly	Calculate rejection rate as a percentage of total invoices submitted. Flag anything above 2% to the project manager.	Finance Ops
Weekly	Review error log for recurring error codes. Patterns indicate a systemic data issue, not a one-off.	IT / NetSuite Admin
Monthly	Confirm log archive is running. Verify UUID and QR code fields are populated on all accepted invoices from the prior month.	NetSuite Admin

Escalation Path

The escalation path for production issues is documented: AR team member contacts NetSuite Admin, who contacts service provider go-live support contact, who escalates to the FTA portal if the issue is network-level.
The first-month AR contact responsible for following up on each rejected invoice is named and has confirmed availability.

Section 7: What to Do When an Invoice Is Rejected After Go-Live

Rejections after go-live are not exceptional events. Even well-configured systems receive rejections when buyers have not updated their Peppol registration or when a data entry error slips through. The key is to resolve and resubmit within the FTA’s allowed window. Here is the step-by-step process your team should follow:

Rejection Resolution Workflow

Identify the error code. Open the service provider response log or the e-invoicing status field on the NetSuite invoice record. Note the FTA or Peppol error code returned. Common codes cover TRN mismatch, schema validation failure, and Peppol routing failure (buyer not found on network).
Correct the underlying data issue in NetSuite. Do not edit the original invoice directly if it has already been submitted; create a credit note to reverse it and issue a corrected invoice. For Peppol routing failures, update the buyer’s Peppol participant ID in the customer record before resubmission.
Resubmit within the FTA resubmission window. Confirm the resubmission deadline with your service provider. Trigger resubmission through the connector or manually via the provider portal if the connector does not support selective resubmission.
Update the e-invoicing status field. Confirm the status field on the NetSuite invoice has moved from Rejected to Submitted and then to Accepted after the corrected invoice is processed.
Log the rejection in your audit record. Record the original invoice number, the error code, the correction made, the resubmission date, and the UUID returned for the accepted corrected invoice. This record supports FTA audit readiness and internal reconciliation.

Aaxonix provides hands-on NetSuite implementation and integration services for UAE businesses preparing for e-invoicing go-live, covering master data readiness, integration configuration, sandbox testing sign-off, and post-launch monitoring setup. Book a free consultation to get a go-live readiness review for your NetSuite environment.

Book a free consultation

Frequently Asked Questions

How many test invoices should we submit in the FTA sandbox before going live?

A minimum of 20 test invoices is a practical baseline, but volume alone is not the measure. Your test set must cover all transaction types you will submit in production: standard invoices, credit notes, zero-rated lines, mixed-rate invoices, AED invoices, and at least one foreign currency invoice. You also need to deliberately trigger and resolve at least two rejection scenarios to confirm your error handling works before production traffic starts.

What is the difference between the sandbox API credentials and the production credentials?

Your e-invoicing service provider issues separate credential sets for sandbox and production environments. The endpoints are different URLs, the API keys are different strings, and submissions to one environment are not visible in the other. A common go-live error is leaving sandbox credentials in one SuiteScript file while updating others, which causes that script to silently submit to the sandbox instead of the FTA production network. Always do a full string search for the sandbox URL across all your NetSuite scripts before go-live.

What happens if an invoice is rejected and we miss the FTA resubmission window?

The FTA’s position on late resubmission is that the transaction may be treated as non-compliant. In practice, you should contact your service provider immediately if you have missed the window, as some providers have escalation paths to the FTA for genuine technical failures. The better preventive measure is daily monitoring of your rejection queue in the first month, so rejections are caught and resolved within 24 hours, well within any resubmission deadline.

Do we need to store the UUID and QR code for every invoice we submit?

Yes. The UUID is the FTA’s unique identifier for each accepted invoice and is required for any subsequent amendment or credit note referencing that transaction. The QR code must appear on the invoice PDF provided to the buyer. Both must be retained for a minimum of 5 years in line with FTA record-keeping requirements. In NetSuite, these are stored in custom fields on the Invoice record and should be included in any invoice PDF template you issue to customers.

What Peppol ID format does the UAE use for buyer routing?

UAE Peppol participant IDs follow the format 0235:TIN, where 0235 is the UAE Peppol scheme code and TIN is the first 10 digits of the buyer’s tax registration number. If a buyer has not registered on the UAE Peppol network, your invoice submission will return a routing failure and the invoice will be rejected. Your master data readiness check should confirm that every active B2B buyer has their Peppol ID loaded in NetSuite before go-live.