Choosing an ERP in the UAE: integration architecture questions to ask before you sign

Digital transformation

If you are the CTO or Head of Engineering on an ERP procurement team in the UAE, the feature comparison is the easy part. Every shortlisted product does multi-currency, inventory and fixed assets. The decisions you cannot easily reverse are architectural: what API the ERP exposes, how you get operational data out for reporting and AI, and how the three to five surrounding systems connect. With UAE e-invoicing phasing in from 1 January 2027 and most mid-market firms needing an Accredited Service Provider by 31 March 2027, the ERP you sign for will either make those integrations routine or make them a multi-year tax.

Most ERP selection processes in the UAE follow the same script. The CFO owns the decision, the vendor demo covers the general ledger, inventory and fixed assets modules, and the technical person in the room gets one slide on "integration capabilities". Six months after go-live the modules are fine and the integrations are the problem: the CRM sync breaks weekly, the e-invoicing flow was bolted on with CSV files, and the AI roadmap quietly depends on a data extraction path nobody designed.

The feature list is table stakes and the vendor marketing covers it thoroughly. What this article covers is what most "best ERP in UAE" comparisons skip: the integration architecture, compared across the four products UAE mid-market procurement teams actually shortlist, and the questions that belong in the evaluation scorecard instead of another row of module ticks.

Timing makes this urgent. The UAE's e-invoicing system is in its pilot phase and the mandated rollout is fixed: businesses with revenue of AED 50 million or more must be live by 1 January 2027, and everyone else by 1 July 2027, with an Accredited Service Provider (ASP) appointed ahead of each phase deadline (31 March 2027 for phase two businesses). Late compliance carries administrative penalties. At the same time, most organisations in the region have AI ambitions on the roadmap. Both depend on the ERP's integration architecture, and both are expensive to retrofit.

The feature matrix is the wrong axis

Feature comparisons rank things that are mostly reversible or mostly irrelevant. If an ERP is missing a report, you write it. If the fixed assets module is clunky, your accountants grumble and adapt. The decisions that shape the next five to seven years are:

• What API surface the ERP exposes. REST or SOAP, whether events (webhooks) exist or everything is polled, what the rate limits are, and whether the API covers the business objects you need or only a subset.
• How operational data gets out for analytics and AI. Whether there is a native query layer you can point a warehouse or an AI pipeline at, or whether every feed is a bespoke ETL job.
• How you extend the system without forking it. The sanctioned extension language and framework, and whether extensions survive upgrades.
• Where the integration layer lives. Point-to-point scripts, an iPaaS, or middleware owned by a local partner. This is where the hidden cost of ERP ownership actually sits.

Question 1: what is the actual API surface?

Ask to see the API documentation in the demo, not a slide about it. Ask for a sandbox tenant and make one authenticated call before you shortlist. The four products differ sharply.

SAP Business One exposes the Service Layer, a REST API built on OData and running on the B1 server itself. Service Layer v2 (/b1s/v2) uses OData v4 and is the interface to build against; the earlier v1 endpoints use OData v3, so check the deprecation status of anything you inherit. The Service Layer covers essentially the full business object model, which is its strength: you can create an invoice, not just read one. There is no native webhook mechanism, so integrations poll with filters on the update timestamp. Start with the SAP Business One Open API and Web Service documentation.

Microsoft Dynamics 365 Business Central has standard REST APIs (API v2.0) enabled by default in the cloud, authenticated through Microsoft Entra ID, with a monthly API update cycle. The API covers standard entities (customers, items, sales orders and invoices, journals, general ledger entries), and you add custom APIs by writing API pages in AL, the extension language. Business Central also has native webhooks: you subscribe to entity changes and receive push notifications, with a documented handshake and retry behaviour. The Business Central developer documentation covers both the API and the extension toolchain.

NetSuite offers SuiteTalk REST web services, with an OpenAPI 3.0 definition, CRUD record operations, and SuiteQL for querying, alongside the older SOAP web services. Authentication is OAuth 2.0 or token-based. There is no general-purpose webhook system for external consumers; event-driven patterns are usually built with SuiteScript inside NetSuite calling out. One upgrade fact belongs in your notes: Oracle states that support for SOAP web services and token-based authentication ends in NetSuite 2028.2, so any integration you inherit over SOAP has a defined expiry. Start with the SuiteTalk REST web services overview, and keep the comparison of REST web services, SOAP web services and RESTlets open while you scope.

Acumatica provides a contract-based REST API where each endpoint publishes a swagger.json (OpenAPI 3.0) you can download from the instance itself, plus a legacy screen-based SOAP API. Newer contract versions use OData 4.01 query conventions. Contracts are versioned per release, so the endpoint path carries the release version, which makes upgrade behaviour explicit but means you must manage endpoint version pinning. See the Acumatica developer resources.

A quick illustration of the difference in developer experience. Creating a sales invoice in SAP Business One through the Service Layer:

POST https://b1server:50000/b1s/v2/Login
Content-Type: application/json

{"CompanyDB": "PROD", "UserName": "integration", "Password": "***"}

POST https://b1server:50000/b1s/v2/Invoices
Content-Type: application/json

{"CardCode": "C-2001", "DocumentLines": [
  {"ItemCode": "A0001", "Quantity": 24, "UnitPrice": 185.00}
]}

And registering a webhook in Business Central, the mechanism that removes polling from your CRM sync entirely:

POST https://api.businesscentral.dynamics.com/v2.0/production/api/v2.0/subscriptions
Content-Type: application/json

{
  "notificationUrl": "https://int.example.ae/hooks/bc",
  "resource": "/api/v2.0/companies({id})/customers",
  "clientState": "change-me"
}

Note the operational detail hiding in that second example: Business Central webhook subscriptions expire after three days unless they are renewed, and notifications are delayed by around 30 seconds to coalesce changes. Someone on your team owns a renewal job. That is exactly the kind of fact that should be in your evaluation notes and never is.

Question 2: how does data get out for analytics and AI?

Every AI roadmap eventually needs the ERP's data: cash flow forecasting needs AR ageing, procurement agents need item and vendor history, and management reporting needs everything. The question is whether extraction is a query or a project.

• SAP Business One: on HANA, analytical views and SQL access give capable analysts direct query paths. Without HANA, you are more dependent on Service Layer OData feeds for reporting extracts.
• Business Central: OData feeds into Power BI are the standard pattern, and because custom API pages are cheap to write in AL, you can expose purpose-built read models for AI workloads. Dataverse integration opens the wider Microsoft data platform.
• NetSuite: SuiteQL through REST web services, SuiteAnalytics workbooks, and ODBC or JDBC access. The SuiteTalk REST API can execute workbook datasets directly, which is a genuine advantage for feeding a warehouse or a retrieval pipeline. Note the ceiling: a SuiteQL query through REST returns a maximum of 100,000 results, and beyond that Oracle points you at SuiteAnalytics Connect with the NetSuite2.com data source.
• Acumatica: the contract-based REST API with OData 4.01 conventions serves both operational integration and analytics; for large-scale history you will land extracts in your own warehouse.

The UAE-specific angle is the e-invoicing data itself. Invoice-level data will flow through your ASP under the five-corner model, and the PINT AE document structure gives you a canonical invoice record. If your ERP choice makes that data easy to retain and query, you have a clean dataset for VAT reconciliation, buyer analytics and any AI you build on top. We covered the ERP-side work for PINT AE in a previous article; the short version is that appointing an ASP solves transport, not data.

Question 3: how do you extend the system without forking it?

You will extend the ERP: a custom approval flow, a WPS payroll export, a PINT AE field mapping. What matters is the sanctioned extension model.

The test to apply in evaluation: write a trivial extension (add one custom field to the sales order and expose it through the API) in each product during the proof of concept, and time it. That hour of effort predicts integration cost better than any RFP response.

Question 4: where does the integration layer live?

A typical UAE mid-market company runs three to five systems alongside the ERP:

• CRM (Zoho, Salesforce or Dynamics): quotes and orders must flow into the ERP, and invoice status must flow back.
• Payroll and WPS: the UAE's Wage Protection System, supervised by MOHRE, means payroll output must reach your bank in the compliant format each cycle, and the payroll system must reconcile with the ERP's general ledger.
• E-invoicing ASP: the ERP-side flow for PINT AE under the five-corner model, including credit notes and idempotent submission.
• Banking: payment files out, statement feeds in, reconciliation into the ERP.
• Sometimes e-commerce or a WMS, which add item, order and stock movement interfaces.

The architectural choice is between point-to-point integrations, an iPaaS, and middleware. Our recommendation: put a thin integration layer of your own between the ERP and everything else, even when each individual integration is simple. Point-to-point scripts multiply (five systems is up to twenty one-way interfaces), and an iPaaS owned by an implementation partner is a dependency you pay for at every change. Your layer should own the mapping logic, the idempotency keys and the retry queues, so that swapping the ASP, the bank or even the ERP later touches one adapter, not the whole estate.

Worked example: a distributor with AED 45 million revenue

Take a realistic case. A Dubai-based distribution company, 120 staff, AED 45 million annual revenue, running a ten-year-old on-premises ERP with a Zoho CRM, outsourced payroll and two main banks. They issue roughly 400 sales invoices and 220 purchase invoices a month, about 7,400 AR and AP documents a year.

Because revenue is under AED 50 million they are in phase two: appoint an ASP ahead of the 1 July 2027 go-live, with the phase deadline of 31 March 2027 as the hard checkpoint. The board has also approved an AI roadmap that starts with cash flow forecasting and vendor performance analysis. They are choosing the ERP now.

How the integration architecture plays out for each candidate:

If they choose SAP Business One, every CRM and analytics integration is OData over the Service Layer: workable but poll-based. Their nightly CRM sync needs $filter=UpdateDate gt ... queries and incremental state tracking, and near-real-time status updates to the sales team are effectively out of scope. The upside is a mature partner ecosystem: most UAE implementation partners know B1. On the e-invoicing side, ask each shortlisted ASP for a named, live B1 connector rather than a roadmap promise. Analytics lands on HANA views. Extensions require either an SDK add-on or disciplined use of user-defined fields.

If they choose Business Central, the CRM question inverts: if the CRM is Dynamics 365 Sales, the two share Entra ID and Dataverse lineage and the integration is largely native; if it stays Zoho, they write webhook-driven sync with push notifications and no polling. The standard API v2.0 covers their entities, and monthly updates mean integration code is tested on a sandbox copy first. Verify the ASP connector the same way: ask for a named UAE connector, live today, with references. AI workloads read OData feeds into a lakehouse, with custom API pages for purpose-built read models.

If they choose NetSuite, their 7,400 documents a year flow through SuiteTalk REST with SuiteQL for extraction, and the finance team gets SuiteAnalytics out of the box. WPS output is a build-or-buy decision here as on any platform: ask the implementation partner to show a payroll export they have shipped, not a capability statement. The constraint to weigh is deployment: NetSuite is multi-tenant cloud, so if the board has data residency expectations, get Oracle's written position on where UAE tenant data sits before procurement, not after. That also makes governance of ERP data for AI workloads a question about Oracle's data platform rather than your own.

If they choose Acumatica, the .NET extension model lets their two in-house C# developers build the WPS payroll bridge and the custom e-invoicing mapping themselves, using custom endpoints with OData 4.01 query conventions. Acumatica is available for private deployment, so hosting, including in a UAE data centre, can settle the residency question on their terms. The trade-off is ecosystem size: confirm with each shortlisted ASP that a certified Acumatica connector exists for the UAE, because connector coverage differs by product and must be verified rather than assumed.

None of these is the wrong answer. What would be wrong is choosing on module features, then discovering the API model in month four of implementation with the e-invoicing deadline eight months away.

Questions for the vendor that are not on their checklist

Bring these to the next procurement session:

1. Show us the API reference in the product's own documentation, and give us the rate limits and concurrency caps for the API in writing.
2. Is there a sandbox tenant we can integrate against before contract signature, and for how long?
3. How do we get event notifications on record changes, and what is the operational burden (renewal intervals, retry behaviour)?
4. How does a certified e-invoicing ASP connect to this product: a connector, an API integration, or professional services each time? Ask for the named connectors already live in the UAE.
5. What is the sanctioned extension path for a new field on a sales document, and how does that extension survive the next major version upgrade?
6. Can we extract full historical data through a query interface ourselves, or does every bulk export require a support ticket or a partner engagement?
7. What changed in the last three product versions that broke third-party integrations, and how much notice were customers given?

If a vendor cannot answer these in detail, that is itself an answer.

What to do next

If you are mid-procurement, the sequence is: get sandboxes for the two or three finalists, run the one-field extension test and one authenticated API call in each, and score integration architecture with the same weight as functionality. If you already have the ERP and are working backwards from the e-invoicing deadline, prioritise the ASP appointment ahead of your phase date (31 March 2027 for phase two businesses), then design the ERP-side mapping and idempotent submission flow, then extend the same integration layer to CRM and banking rather than starting fresh per system.

We do this work from the UAE side: Azrty is a Dubai-based company, and our own team runs the mapping, deployment and support. That can mean connecting the ERP to the systems around it and bringing the data together, or building the AI applications that sit on top of that data, or the wider transformation programme. If it would help to have the integration questions pressure-tested before they go into the scorecard, that is a conversation worth having early, not after the contract is signed.

https://www.azrty.com/blog/choosing-an-erp-in-the-uae-integration-architecture-questions-to-ask-before-you

<a href="https://www.azrty.com/blog/choosing-an-erp-in-the-uae-integration-architecture-questions-to-ask-before-you">Choosing an ERP in the UAE: integration architecture questions to ask before you sign</a> (Azrty)