Custom ERP Integration with UAE FTA E-Invoicing via API

You Have an ERP No One Has Heard of

Plenty of UAE businesses run something other than the mainstream ERPs. In-house Java or .NET apps built fifteen years ago. Locally-popular but globally-obscure packages. A spreadsheet-based system that has been "the ERP" for the last decade. None of these have a pre-built connector to your Accredited Service Provider. The good news: every reasonable ASP can integrate with a custom or legacy system via a published API, provided your team can produce the data in a structured form.

This post explains the integration pattern, the data contract you need to fulfil, and what a well-run custom integration looks like end to end.

The Integration Contract

Whatever ERP you run, the ASP needs four things on the outbound (AR) side:

1. Invoice records in a structured format (JSON or XML) with all PINT AE-relevant fields populated.
2. A trigger that fires when an invoice is ready to be sent.
3. A way to write status back so your ERP knows whether the invoice was accepted by the FTA.
4. An authentication layer to keep the channel secure.

On the inbound (AP) side, the contract is reversed: the ASP delivers a structured supplier invoice to your ERP and your ERP creates an AP record.

The Outbound Pattern

Three patterns work. Pick based on your ERP's capabilities:

Pattern A — Webhook + REST Pull

When you post an invoice, your ERP calls the ASP webhook URL with the invoice ID. The ASP then calls back to your ERP's REST API to fetch the full invoice payload. This is the cleanest pattern because it keeps your ERP the system of record and avoids duplicating data.

Requires: an outbound HTTP capability in your ERP and a published read API.

Pattern B — Push (You Send Full Payload)

Your ERP posts the full invoice JSON to the ASP's API as soon as the invoice is finalised. Faster than Pattern A because no callback round-trip. Best when your ERP cannot expose a callable read API but can construct an outbound HTTP request.

Requires: an outbound HTTP capability and an ability to assemble the full payload at the moment of sending.

Pattern C — Polled File Drop

Your ERP writes invoice JSON or XML files to an SFTP folder. The ASP polls every few minutes and processes new files. Slowest pattern but works with any ERP that can export to a file. Useful for legacy systems with no real-time HTTP capability.

Requires: scheduled job that produces structured files. Falls back to a manual upload UI for the rare error path.

The Minimum Viable Payload

The ASP will tell you their exact schema. The PINT AE-relevant fields you must produce are:

• Document header - invoice number, issue date, due date, currency, document type code (invoice/credit note/debit note), reference to original invoice for credit/debit notes
• Supplier party - your legal name, TRN, address (emirate, area, building, P.O. Box), Peppol participant ID
• Customer party - same fields for the buyer
• Line items - description, quantity, unit code, unit price, tax category code, tax rate, line total
• Tax totals - subtotal per VAT rate, total tax amount, total amount due
• Payment terms - IBAN, due date, payment means code
• Allowances/charges if present - discount, retention, surcharge

Custom ERPs often have these fields scattered across multiple tables or stored as free text. The mapping work is to surface them cleanly in your payload.

Status Write-back

For every invoice you send, the ASP returns:

• Submission state - Accepted, Rejected, Pending
• FTA reference (if accepted)
• Peppol Message ID (delivery to customer ASP)
• Error detail (if rejected)
• Timestamp of each state change

Your ERP needs a place to store these. Even legacy systems can usually accommodate four or five additional fields on the invoice header. Without status write-back, your finance team has no visibility into compliance state and AR aging will get confused.

Authentication

For modern ERPs, OAuth 2.0 with a service account is standard. For legacy systems that cannot do OAuth, API keys or mutual-TLS work. Whatever you use, treat the credentials like database credentials - rotate quarterly, store encrypted, never embed in source code.

The Inbound (AP) Side

Two patterns work for receiving supplier invoices into a custom ERP:

• Pull pattern - your ERP polls the ASP's API every few minutes for new inbound invoices and creates AP records from them. Simple, works with any ERP that can make outbound HTTP calls.
• Push pattern - the ASP calls a webhook URL on your ERP when a new inbound invoice arrives. Faster but requires your ERP to expose a publicly-reachable HTTP endpoint (with authentication).

What Could Go Wrong

• Field drift. Custom ERPs accumulate one-off fields. Your "customer address" might actually live in three different tables for different customer types. The mapping layer must consolidate these.
• Currency precision. Legacy systems sometimes store amounts in cents or fils as integers, sometimes as decimals with varying precision. PINT AE expects two decimal places on AED amounts with consistent rounding.
• Encoding. Older databases may use non-UTF8 character sets. Arabic customer names and addresses are a common breakpoint - test with real Arabic data, not just English.
• Time zones. Document timestamps must be unambiguous. UAE local time (UTC+4) without DST is the safe choice; store with timezone, not just naked datetime.
• Duplicate prevention. Webhook delivery may retry; your ERP must be idempotent against the same invoice ID arriving twice.

A Realistic Timeline for a Custom ERP

Custom integrations vary widely, but a typical path:

1. Weeks 1-2 - Discovery. Map your ERP's invoice schema to the ASP's payload. Identify gaps in source data.
2. Weeks 3-5 - Source data fixes. Add missing fields, normalise tax codes, clean customer master.
3. Weeks 6-9 - Build the integration layer. Outbound webhook/push/poll, payload assembler, status write-back. Authentication.
4. Weeks 10-12 - Sandbox testing with real invoice patterns, including credit notes, multi-currency, free zones.
5. Weeks 13-14 - User acceptance, exception-path testing, parallel run.
6. Week 15+ - Go live and hypercare.

Custom integrations typically take 3 to 4 months. Start early — Phase 1 (Jan 2027) and Phase 2 (Jul 2027) come faster than you think.

What to Demand from Your ASP

• Published API documentation with example payloads
• A sandbox environment for end-to-end testing
• Postman collection or OpenAPI spec to accelerate development
• Webhook signature verification (so your ERP knows the call really came from the ASP)
• Idempotency support on both sides
• Rate limit specifications and bulk-replay tooling
• Named technical contact for your build period

How InvoiceNet Handles Custom Integrations

InvoiceNet provides a documented REST API with OAuth 2.0, webhook delivery, and idempotency tokens for custom integrations. We ship Postman collections, an OpenAPI 3 specification, and signed webhook payloads. Our integration team works directly with your developers during the build. Talk to us for a custom-ERP-specific scoping call.