A UAE customer tells you: “We need Business Central to send our invoices to the FTA.”
That sounds like an integration requirement. It’s also a dangerous place to start the architecture.
UAE e-invoicing isn’t:
Business Central → FTAThe UAE has adopted a 5-corner model built on the Peppol network. Supplier and buyer exchange invoices through Accredited Service Providers (ASPs), while tax data flows to the Federal Tax Authority through those same providers. For a Business Central implementation, that one structural fact changes almost everything: where validation belongs, who generates the compliant document, how failures get handled, and how much UAE-specific logic should actually live inside your extension.
This article is about that boundary — what Business Central should own, and what it shouldn’t.
The Five Corners
| Corner | Participant | Typical responsibility |
|---|---|---|
| 1 | Supplier | ERP/accounting system, source invoice data |
| 2 | Supplier’s ASP | Validation, transformation, Peppol transmission, tax reporting |
| 3 | Buyer’s ASP | Receipt, validation, delivery to buyer, also reports to the FTA |
| 4 | Buyer | ERP/accounting system receiving the invoice |
| 5 | Federal Tax Authority | Receives tax-reporting data |
┌─────────────┐
│ FTA │ Corner 5
└──────▲──────┘
│ Tax Data
┌────────────┴────────────┐
┌────────┴────────┐ ┌───────┴────────┐
│ Supplier's ASP │───────▶│ Buyer's ASP │
│ Corner 2 │ │ Corner 3 │
└────────▲────────┘ └───────┬────────┘
│ │
┌────────┴────────┐ ┌───────▼────────┐
│ Business Central│ │ Buyer ERP │
│ Corner 1 │ │ Corner 4 │
└─────────────────┘ └────────────────┘
For a Business Central customer acting as supplier, BC is normally Corner 1 — nothing more. It’s easy to collapse four separate concerns into one project: creating the accounting invoice, producing compliant electronic invoice data, transporting it across Peppol, and reporting tax data to the FTA. Business Central owns the first. Your extension might own part of the second. The ASP owns the rest. Keep those boundaries explicit and the design gets much easier to reason about.
PEPPOL Support ≠ PINT-AE Compliance
A common assumption: “Business Central already supports PEPPOL, so this should work out of the box.” Not quite. Microsoft documents PEPPOL BIS 3.0 as the newest PEPPOL format shipped in the default (W1) version — and PINT-AE is not just a renamed BIS 3.0.
PINT (Peppol International Invoice) is a common model that jurisdictions specialize. The UAE’s specialization — PINT-AE — adds its own semantic model, code lists, business rules, and Schematron validation on top. Passing generic PEPPOL validation says nothing about whether a document satisfies the UAE rules.
It’s also actively versioned, and the two things that get versioned aren’t the same thing. As of this writing, PINT-AE Billing 1.0.4 is the current final specification, released 2 June 2026 with a set of Schematron validation corrections and validator-stability fixes. The documentation package that renders those specs (PDK 1.4.4) was separately updated 29 July 2026. Don’t treat either date as a permanent baseline — validate against whatever specification and validation artifacts your ASP actually requires at implementation time, and design your mapping layer to absorb the next point release without a code change:
BC Business Data → Mapping Layer → PINT-AE Generation → Validation → Transport
If a validation rule changes, sales posting shouldn’t need to change. If your ASP swaps its API, invoice calculation shouldn’t need to change.
The One Decision That Matters: Who Generates PINT-AE?
This is the real architecture call, and it comes down to two legitimate options.
Option 1 — Business Central generates PINT-AE directly. You control field mapping, XML generation, and pre-submission validation, and you’re less locked to one ASP’s proprietary format. The tradeoff: you now own regulatory maintenance. Every Schematron correction, code-list update, or new mandatory field is a potential extension update.
Option 2 — Business Central sends structured data; the ASP transforms it. The UAE’s own guidance explicitly supports this — Corner 1 can submit in an agreed format, and Corner 2 converts it to UAE-standard XML. Your BC solution becomes less coupled to Schematron and transport-rule changes. The tradeoff: you’re more coupled to that ASP’s API contract, and switching providers can mean real rework.
| BC generates PINT-AE | ASP generates PINT-AE | |
|---|---|---|
| Compliance mapping control | High | Lower |
| Regulatory maintenance burden | On you | On the ASP |
| Switching ASPs later | Usually easier | Can require rework |
| Best fit | Reusable UAE localization/ISV product | Single implementation, capable ASP |
Don’t decide this before you’ve shortlisted an ASP. Ask them directly: which Corner 1 formats do they accept, do they perform PINT-AE validation and against which release, is submission synchronous or async, how are statuses queried, how do they handle inbound purchase invoices. Their answers decide your architecture — not the other way around.
Building It: BC’s E-Document Framework
This is where Business Central already gives you real structure. The E-Document Core module separates document format (“what are we creating?”) from service integration (“how are we sending it?”) — and Microsoft’s extensibility model for both is genuinely solid, not a stub.
A UAE format implementation extends the format enum and implements a handful of well-defined methods — Check (validate source data before release/post), Create (build the outbound blob), GetBasicInfo and PrepareDocument (handle inbound documents):
enumextension 50100 "UAE E-Document Format" extends "E-Document Format"
{
value(50100; "PINT-AE")
{
Implementation = "E-Document" = "PINT-AE EDocument";
}
}
The ASP connector lives behind a separate integration interface — IDocumentSender and IDocumentReceiver for send/receive, plus IDocumentResponseHandler when the ASP responds asynchronously:
enumextension 50101 "UAE ASP Integration" extends "Service Integration"
{
value(50100; "UAE ASP")
{
Implementation =
IDocumentSender = "UAE ASP Integration",
IDocumentReceiver = "UAE ASP Integration";
}
}
Neither snippet is a complete implementation — no such universal “UAE ASP API” exists, and your provider’s actual authentication, endpoints, and callback design have to come from their spec. What matters architecturally is that ASP-specific code stays behind that integration boundary instead of getting scattered through posting logic and sales document code. Note also: Microsoft doesn’t currently ship a UAE localization out of the box (UAE is listed as Partner/W1), so this framework is what you build on, not something already done for you.
Posting Success Isn’t Invoice Success
This is the part that bites in production. A sales invoice posts successfully. An E-Document gets created. BC sends it toward the ASP. The network times out.
What’s the status? Not “invoice failed” — the accounting transaction is done and correct. What’s uncertain is the electronic invoice lifecycle, which is a separate state entirely:
Accounting: Posted
Electronic: Created → Exported → Submitted → Processing → Accepted / Rejected / Unknown
The genuinely hard case isn’t “the API returned 200.” It’s “we don’t know whether the ASP accepted the invoice” — did the request never arrive, or did it arrive and the response get lost? Retry blindly in the second case and you risk submitting the same invoice twice. This needs the same discipline as any serious API integration: correlation IDs, provider transaction IDs, status lookup, and a manual-recovery path for outcomes that are genuinely ambiguous. BC’s E-Document framework already gives you Document and Integration Logs to build this on — use those before inventing a parallel logging system.
One architectural opinion, clearly labeled as a recommendation rather than a platform requirement: don’t call the ASP from inside your posting event subscriber. Doing so makes one of BC’s most important transactions depend on ASP availability, authentication, and response time. Keep the business transaction and the external communication lifecycle separate, even while respecting whatever timing the UAE rules and your ASP impose.
What Not to Build Yourself
- A custom FTA API. Corner 2 (and, after validation, Corner 3) already owns tax-data reporting to Corner 5. Your job is supplying Corner 2 with complete, correct data — not recreating that reporting pipeline in AL.
- A PDF as “the invoice.” The Ministry’s guidance is explicit: the compliant document is structured XML. PDFs, scans, and images aren’t eInvoices, however useful they remain for a human to read.
- UAE modeled on ZATCA, or on Dynamics 365 Finance’s e-invoicing. Saudi’s ZATCA is a direct-reporting, clearance-adjacent model; UAE is decentralized and ASP-mediated, and — worth calling out explicitly — UAE e-invoices carry no QR code or barcode, unlike ZATCA’s. And Business Central’s own Clearance framework (used for Spain, India, Mexico, Italy) doesn’t apply here either; don’t reach for it just because it exists.
- Hard-coded ASP logic sprinkled through Sales Header fields, posting subscribers, and Job Queue recovery. Keep the provider swappable behind the E-Document abstraction.
Before You Start Building
A short list of things worth knowing the answer to before writing code, not after:
Regulatory — which entities are in scope, what’s each one’s deadline, is participant/TIN data correct, which invoice and credit-note scenarios apply.
ASP — which accredited provider, what Corner 1 format they accept, do they own PINT-AE transformation and against which release, sync or async submission, how are inbound documents delivered.
Business Central — is E-Document Core in use, who owns the format implementation vs. the service integration, are tax/currency/unit-of-measure mappings actually complete (structured e-invoicing exposes master-data gaps immediately — a missing legal entity identifier or tax category that was invisible on a PDF becomes a validation failure).
Operations — how are failed transmissions recovered, can support reproduce an outbound payload, what’s safe to auto-retry vs. requires a human.
If any of these are unknown, having working XML generation doesn’t mean you’re ready.
The Timeline You’re Actually Working Against
| Group | Appoint ASP by | Mandatory from |
|---|---|---|
| Revenue ≥ AED 50 million | 30 Oct 2026 | 1 Jan 2027 |
| Revenue < AED 50 million | 31 Mar 2027 | 1 Jul 2027 |
| In-scope government entities | 31 Mar 2027 | 1 Oct 2027 |
The large-business ASP deadline was originally 31 July 2026 and was extended to 30 October 2026 in a Ministry of Finance amendment announced 10 May 2026 — the 1 January 2027 go-live didn’t move. Confirm current dates against the Ministry’s portal for each engagement rather than reusing dates from an older project; this program has already moved once.
The Actual Decision
The hard part of UAE e-invoicing in Business Central was never generating XML. It’s deciding who owns what:
Business Central → the accounting transaction
E-Document framework → document generation, status, extensibility
UAE mapping (yours/ASP's) → PINT-AE transformation
The ASP → Peppol exchange, Corner 5 tax reporting
Get that boundary explicit before the first integration line of code, and the rest of the implementation — validation, retries, ASP switching, the next PINT-AE point release — stays maintainable instead of becoming a rewrite.
