Real-Time vs Near Real-Time FTA Reporting: What the UAE Mandate Actually Requires

The Terminology Confusion

Vendors selling e-invoicing solutions for the UAE love to say "real-time FTA reporting". It is shorter than the more accurate phrase, and it sells. But the UAE mandate does not require true real-time reporting (synchronous, sub-second), and it does not require post-period batch reporting either. It requires near real-time reporting through the Peppol 4-corner exchange model with simultaneous metadata submission to the FTA. The distinction is not pedantic - it has real consequences for system design, latency budgets, and what you should expect from your ASP.

What "Real-Time" Means in Other Mandates

Some countries (notably some Latin American regimes) require pre-clearance: the supplier sends the invoice to the tax authority, the authority validates and returns an authorisation code, and only then can the invoice be issued to the customer. That is true real-time, synchronous reporting. It puts the tax authority in the critical path of every transaction.

The UAE has explicitly chosen not to do this. Pre-clearance scales poorly and creates regulatory risk if the authority's system is slow or down.

What "Near Real-Time" Means in the UAE

Under Ministerial Decisions 243 and 244 of 2025, the UAE adopted the Peppol 4-corner exchange model:

• The supplier issues an invoice through its Accredited Service Provider (ASP).
• The supplier's ASP transforms it to PINT AE, signs it with XAdES, and routes it through Peppol to the customer's ASP.
• Both ASPs simultaneously report the invoice metadata to the FTA.
• The customer's ASP delivers the invoice to the customer's AP system.

The FTA receives the report at roughly the moment the invoice is exchanged - typically within seconds, certainly within minutes. It is not pre-clearance: the invoice does not wait for the FTA's OK before being delivered. But it is not batch either: there is no end-of-day or end-of-month aggregation.

Why This Matters for System Design

1. No Synchronous Dependency on the FTA

Your ERP does not need to wait for an FTA response before it considers the invoice posted. The ASP handles reporting asynchronously. This means a brief FTA outage does not stop your business from invoicing.

2. The ASP Must Have Resilient Queuing

Because the ASP's job is to report in near real-time, it needs robust queuing and retry behaviour. If the FTA endpoint is briefly unavailable, the ASP must queue and retry, not drop the message. Ask any candidate ASP how they handle FTA endpoint downtime.

3. Status Visibility Is on a Delay

Because reporting is asynchronous, the FTA acknowledgement for a given invoice may arrive a few seconds to a few minutes after the invoice was sent. Your ERP's status write-back should treat the initial state as "Submitted" and transition to "Acknowledged" when the FTA confirms.

4. Reconciliation Is Easier Than Pre-Clearance Models

Near real-time means you can issue an invoice now and reconcile the FTA acknowledgement later. You do not need a synchronous validation step in your customer-facing workflow. This keeps invoicing user experience identical to today.

What the ASP Must Do Within the Window

The ASP's job between you posting an invoice and the FTA acknowledging it includes:

1. Receive the invoice data from your ERP (via API, webhook, file drop, or connector)
2. Map ERP fields to PINT AE elements
3. Validate against PINT AE cardinality and FTA business rules
4. Apply XAdES digital signature with trusted timestamp
5. Look up the customer's Peppol participant ID
6. Route the document to the customer's ASP via the Peppol network
7. Submit invoice metadata to the FTA
8. Receive and process FTA acknowledgement
9. Write status back to your ERP

For most invoices, the entire pipeline completes in single-digit seconds. Edge cases (large invoices with many lines, complex multi-currency conversions, customer-side ASP latency) may take a minute or two.

What Latency Budget to Expect

• P50 (median): 2-5 seconds end to end
• P95: 10-30 seconds
• P99: 1-2 minutes (typically limited by customer ASP throughput or network)
• Hard failures: Should be in the order of 0.01 percent or lower for a well-run ASP

These are typical industry expectations, not regulatory targets. Ask any candidate ASP for their published latency SLOs.

What "Near Real-Time" Does NOT Mean

• It does not mean the FTA pre-approves each invoice before issuance.
• It does not mean the customer's ASP is in your transactional critical path.
• It does not mean any human review at the tax authority.
• It does not mean batch upload at end of day or end of month.
• It does not mean you must keep open network sessions to the FTA from your ERP.

What This Means for Your Architecture

1. Your ERP can post invoices the way it does today. No synchronous external call needed.
2. The ASP handles all asynchronous orchestration. You delegate the regulatory communication.
3. Your status fields should reflect three states: Submitted (sent to ASP), Acknowledged (FTA confirmed), Rejected (validation failed).
4. Your AP team should expect inbound invoices to land seconds after the supplier posts them. Same near-real-time pattern, mirror image.
5. Your monitoring should alert on rejection rates above 1 percent or on submissions stuck in Submitted for over an hour - either is a sign of a real problem.

Why the UAE Chose This Model

Three reasons make near real-time the right choice for the UAE:

• Scalability. The Peppol network was designed for high-volume international interoperability. Pre-clearance would force every invoice through a single national bottleneck.
• Resilience. No single point of failure can stop the entire economy from issuing invoices.
• Interoperability. The same architecture works for cross-border invoices with EU, Singapore, Australia, and other Peppol countries.

How InvoiceNet Implements Near Real-Time Reporting

InvoiceNet is built on a queued, resilient pipeline with published latency SLOs and retry semantics that survive transient FTA or customer-ASP outages. Status write-back to your ERP happens in two phases (Submitted, then Acknowledged) so your finance team sees compliance status in near real-time. Talk to us about latency expectations specific to your invoice volume profile.