UAE E-Invoicing & Peppol Compliance

The UAE is moving business-to-business invoicing off the emailed PDF and onto a structured document that has to be produced, validated, transmitted through an accredited service provider, and reported to the tax authority, with a response coming back that your finance team can be asked to produce during an audit. The topology is a Peppol five-corner model: your ERP, your accredited access point, the buyer access point, the buyer, and the tax authority as the fifth corner receiving the reporting copy. None of that is satisfied by exporting a report at month end.

Inside Dynamics 365 Finance and Operations the gap is specific rather than vague. A posted customer invoice lives across CustInvoiceJour, CustInvoiceTrans and TaxTrans, and it holds the amounts you need, but not in the shape a compliant document demands. Buyer and seller identifiers have to resolve to a scheme, not a free-text field. Tax has to be expressed per line as a category with a rate and a reason, not summarised at the header. The registration details of the legal entity have to come from the registration ID records rather than a print management footer. Every document needs a stable identity, a transmission state that survives an AOS restart in the middle of a batch, and a link back to the voucher so a rejection can be traced to its source. Teams that improvise with a data export and a spreadsheet discover this at the worst possible moment: a rejected document that nobody can correlate to the invoice it came from.

ECOSIRE builds that compliance layer as a Finance and Operations extension model, using event handlers, extension classes, and table and form extensions. There is no overlayering, so it installs beside your existing customisations and survives platform updates.

What ECOSIRE builds

### Document generation from posted transactions The extension subscribes to posting events on the customer invoice, the project invoice and the free text invoice, then assembles a document model from CustInvoiceJour, CustInvoiceTrans, TaxTrans, the customer record and the legal entity registration data. Mapping is configuration rather than code: tax categories, unit of measure codes, currency codes, item identification schemes and allowance or charge reasons live in setup tables, so a rule change does not require a redeploy. The document itself is produced through the Electronic reporting framework where you already use it, or through a dedicated builder class where you do not, which means the output format can be revised without disturbing the transmission logic.

### Transmission and response handling Outbound delivery runs on the batch framework as a SysOperation service with a bounded retry policy and a parked queue for permanent failures, so a network fault at 23:50 does not silently swallow a day of invoices. Each document carries its own state, from built to queued, sent, accepted, rejected or cancelled, held on a transmission table alongside the voucher, invoice account, legal entity and the message identifier returned by your provider. Message level and business level responses are captured back onto the same record, so a rejection arrives with a reason, a timestamp and the raw payload attached to it instead of living in somebody inbox.

### Master data, validation and the pre-flight gate Most rejections are master data problems, not format problems. The build adds participant identifier, scheme and endpoint fields to the customer record, adds registration and endpoint configuration per legal entity, and runs a validation pass before a document is ever queued. Validation results appear as an actionable list, naming the customer with no endpoint identifier, the line with no tax category, the item with no unit code. The same validation runs as a batch job across open sales orders, so the finance team fixes data before the invoice run rather than after it.

### Archiving, corrections and audit The transmitted payload and the signed response are stored against the invoice as document management attachments with retention flags, so an audit request becomes a lookup instead of an excavation. Credit notes and corrections reference the original document identifier, and re-issued invoices keep their history rather than overwriting it. Where financial dimensions matter for reporting, the ledger dimension combination on the source voucher is carried onto the transmission record so compliance data can be sliced the same way the general ledger is.

### Monitoring and integration surface Transmission status is exposed as data entities over OData so it can be read by Power BI, a Power Platform app, or your own monitoring stack. Business events fire on acceptance and rejection, which is usually the cheapest route to an alert in Teams or a shared mailbox through Power Automate without adding another polling job. Where Dual-write is already in place, the status is surfaced on that side too instead of building a parallel integration.

Who this is for

This is for organisations posting UAE customer invoices out of Finance and Operations, particularly where more than one legal entity is involved and each has its own registration, endpoint and numbering. It suits shared service centres that invoice on behalf of several entities and need one operational view of what was sent, what was accepted and what is stuck. It suits groups with mixed obligations, where UAE entities need Peppol exchange while sister entities keep their existing process, because configuration is per legal entity rather than global.

It is a poor fit if you post only a handful of invoices a year and are content to key them into a portal by hand, or if your invoicing does not originate in Finance and Operations at all.

How delivery works

Everything here is built to order. There is no download and no trial, because the software does not exist until we build it for your environment.

1. Scoping call. We walk your invoicing flows, legal entities in scope, the accredited provider you have selected or intend to select, your tax setup, and your platform and application version. We also look at what already exists in your environment so the extension fits around it. 2. Fixed quote. You receive a written scope and a fixed price before any code is written. If the scope changes later, the change is quoted separately rather than absorbed silently. 3. Build. We develop the extension model in a development environment, against your version, with unit and integration testing on representative invoices from your data. 4. Install in test, then production. The deployable package goes into your sandbox first through your LCS pipeline, where we run the documented test pack with your finance team against your provider test endpoints. Production deployment happens only after that sign-off, on your change window. 5. Support. An agreed support window follows go-live, covering defects in what we built, with a documented route for raising them.

Typical lead time from signed quote to a package ready for your sandbox is two to four weeks, depending on the number of legal entities and how much master data remediation is needed.

What this is not

ECOSIRE is not an accredited service provider and does not act as your access point. You contract with your chosen provider; we build the layer that produces compliant documents, transmits to that provider, and records the outcome inside Finance and Operations. We also do not give tax advice. Where a mapping decision has a tax consequence, we implement what your tax advisor or auditor confirms, and we make that mapping configurable so it can be corrected without a code change.