UAE E-Invoicing Compliance (Peppol PINT AE)

The problem

The UAE e-invoicing mandate moves invoicing off PDF and email and onto a structured, network-delivered model. Invoices and credit notes have to be produced as PINT AE documents — the UAE specialisation of the Peppol International Invoice — with mandatory business terms, correct code lists, participant identifiers for both parties, and a document reference structure that a validation engine will check before anything reaches your customer or the tax authority. Delivery happens through an accredited service provider on the network, and the reporting obligation sits alongside it.

Native NetSuite has the invoice record, the tax engine, the customer and subsidiary structure — and none of the above. There is no PINT AE payload, no participant identifier registry, no network transmission, and no place to store the delivery acknowledgement or the validation errors that come back. The common workaround is a CSV or XML export pushed into a provider portal by hand. That works until volume rises, until a document fails validation and nobody can tell which NetSuite record produced it, or until finance is asked to prove what was transmitted and when.

The second problem is inbound. Once you are on the network you receive supplier documents in the same structured format, and dropping them into a mailbox rather than into NetSuite defeats the point.

What ECOSIRE builds

We build a NetSuite customization — SuiteScript 2.1, SuiteFlow, custom records and saved searches — that lives inside your account and makes PINT AE generation and transmission part of the normal invoicing flow. Nothing here is pre-built and downloadable. We scope it against your subsidiaries, item types, tax codes and provider relationship, quote a fixed price, then build and deploy it.

PINT AE document generation

A User Event script on Invoice and Credit Memo records builds the PINT AE payload at approval. It maps NetSuite data to the mandatory business terms: seller and buyer legal names, TRN, participant identifiers and address subrecord data; line-level item identification, quantity, unit of measure, net price and allowances or charges from the transaction line sublist; and the tax breakdown by category from the tax detail sublist. Document type and invoice type codes are derived from the transaction type and a configuration record rather than hardcoded.

Validation before transmission

Documents are validated against the required business rules before they leave NetSuite. Missing TRNs, absent participant identifiers, unmapped tax categories and unit-of-measure gaps are surfaced on the transaction as a blocking or warning condition, so the correction happens on the record where the data lives instead of in a provider portal after rejection.

Accredited service provider transmission

A RESTlet and Map/Reduce pair handles outbound delivery to your chosen accredited service provider over their REST API, with credentials held on a restricted custom record. The queue batches, retries with exponential backoff, respects NetSuite governance limits, and records every request, response, message identifier and acknowledgement against the originating transaction. We build to your provider's published API contract — the provider relationship and contract remain yours.

Inbound document handling

Where your provider supports inbound delivery, we build the receiving RESTlet that accepts supplier documents, stores the raw payload in the file cabinet, and creates or matches a Vendor Bill with the parsed line data for your AP team to review. Matching rules against purchase orders and vendor records are agreed during scoping.

Participant identifiers and master data

A custom record holds participant identifiers and scheme codes for customers and vendors, with a validation utility and a saved search that lists counterparties still missing an identifier — so master-data cleanup is a tracked task, not a discovery made at cutover.

Operational visibility

A Suitelet dashboard and saved searches show generated, transmitted, acknowledged, rejected and pending documents with their status codes and timestamps. Rejected documents can be corrected and retransmitted from the record. The transmitted payload and the acknowledgement are attached to the transaction as the evidentiary copy.

Who this is for

Businesses running NetSuite with a UAE entity in scope for the mandate — including OneWorld groups where the UAE subsidiary needs PINT AE while other subsidiaries continue unchanged. It fits companies with meaningful B2B invoice volume, customers who will themselves be on the network, or an AP function that will start receiving structured supplier documents.

It is not the right purchase if you issue a very small number of invoices and are happy to key them into a provider portal.

How delivery works

1. Scoping call. We review your NetSuite account: subsidiaries, tax codes, item and unit-of-measure setup, transaction forms, approval roles, the accredited service provider you have selected, and the state of your customer and vendor master data. 2. Fixed quote. A written scope and a fixed price before development starts. Anything added later is quoted, not absorbed quietly. 3. Build. Development happens against your sandbox as an SDF project, on your real record structures. Typical lead time is 2–4 weeks depending on scope, inbound handling, and how quickly sandbox and provider test credentials are available. 4. Install in sandbox, then production. We deploy the unmanaged bundle/SDF project to sandbox, run end-to-end tests against your provider's test environment using your own transactions, and only then promote to production and switch endpoints. 5. Support. A defined support window after go-live covering defects, provider response-code triage and configuration changes.

You own the SuiteScript and all customizations. No runtime licence to us, no per-document fee to us, no dependency on us continuing after the support window.

What we do not claim

We do not accredit you, and we are not a service provider — transmission runs through the accredited provider you contract with. We do not promise that no document will ever be rejected; we build the pre-transmission validation, the error surfacing and the retransmission path so rejections are visible and fixable. When the specification or your provider's API changes, we say clearly whether it falls inside your support window or needs a new quote.