System integration · ERP
ERP integration: connect your ERP with CRM, e-commerce, portals and government platforms
ERP integration connects the ERP to the other systems that create or need its data: CRM, online stores and customer portals, warehouse and HR systems, and national platforms. Done well, an order, an invoice or a customer record is entered once and reaches every system that needs it, on time and checked. Interkey integrates ERPs with the systems around them for organisations in Saudi Arabia, through an API layer, events, files or real-time replication, with a written contract and a named owner for every interface.
Published 5 min read
In short
- What gets connected: the ERP and every system that creates or consumes its data.
- How: one pattern per interface: API layer, event streaming, files and batches, point to point, or replication.
- Which ERP: we build against the interfaces your ERP product documents: its APIs, events, files or database.
- National platforms: built against each platform's published specification; Interkey has delivered a Nafath integration.
- New ERP programmes: we run the integration workstream alongside the vendor implementing the ERP.
- After go-live: every interface monitored, with a named owner; Interkey can operate the estate from Riyadh.
Common ERP interfaces and the pattern that usually fits
| Interface | Data that flows | Pattern that usually fits | What to watch |
|---|---|---|---|
| ERP and CRM | Customers, quotes, orders, credit status | API layer, or events when several systems need the change | Which system owns the customer record |
| Online store or customer portal and ERP | Orders, stock, prices | API layer; events for stock changes | An order sent twice must not be booked twice |
| ERP and warehouse or logistics | Picking lists, shipments, receipts | Events, or files on a schedule | Messages arriving out of order |
| ERP and HR or payroll | Postings, cost centres | Files and batches | Cut-off times and reconciliation |
| ERP and a reporting database | Most ERP tables | Continuous replication | Load on the ERP's own database |
| ERP and national platforms | Invoices, identity checks, contracts | API built to each platform's specification | Version changes, expiring credentials, duplicate submissions |
None of these is fixed. The pattern is chosen per interface, from how many systems consume the data, how fresh it must be and who owns it. An estate with three interfaces is often better served point to point; one with dozens usually shares an API layer and common transformations.
Why ERP interfaces fail
Most ERP interface failures trace back to the same cause: nobody wrote down what the interface sends, when, in what format, and what happens on error. The interface works on go-live day. Then the ERP is upgraded, a field changes meaning, or a retry books an order twice, and nobody knows who owns the fix.
The remedy is a contract per interface, agreed before building, that becomes the test baseline.
What each interface contract must say
- Fields and meaning: what each field means, which system owns it, and how codes map between systems.
- Trigger and frequency: what starts the exchange, how often, and how fresh the data must be.
- Format and validation: what a valid message is, and what happens to an invalid one.
- Errors and retries: how failures are reported, retried and escalated.
- Duplicates: how a message sent twice is recognised and ignored.
- Change notice: how much notice either side gives before changing the interface, including ERP upgrades.
- Monitoring and owner: what is watched (volume, failures, staleness) and who is alerted.
ERP integration with national platforms
Many submissions to national platforms start in the ERP: e-invoices to ZATCA's e-invoicing platform (Fatoora) are an example. Each platform has its own specification, credentials and onboarding, so each is its own integration, and the registration and credentials remain your organisation's. Interkey scopes, builds, tests and operates integrations against platforms' published specifications, and has delivered a Nafath integration. Our guide to integrating with Saudi digital platforms covers the steps and the failure modes to design for.
Moving to a new ERP
When a new ERP goes live, the interfaces around it are often the riskiest part of the programme. Interkey works alongside the vendor implementing the ERP, on the part they are least interested in: the interface inventory, the contracts, the build, the parallel run and the cutover. The vendor remains accountable for its own platform.
Each interface is moved on its own and runs in parallel with the old one until the outputs agree. Only then does it switch. There is no single weekend on which everything changes at once.
Tools behind the patterns
- API layer: a governed gateway on Kong, with one policy for authentication, rate limits and versioning, delivered by our API management practice.
- Replication: iblync, Interkey's own platform, for keeping records in step between systems in real time. See data integration services.
- Files, batches and events: built and monitored by the system integration team.
- Legacy systems without an API: integrated through the database, files, screens or message queue, in roughly that order of preference.
Relateddata integration services
How an ERP integration engagement runs
-
Integration assessment.
The inventory of interfaces, the ownership map and the gaps in data definitions, for the ERP and the systems around it.
-
Contract per interface.
Payloads, frequency, failure handling and change notice, written before anything is built.
-
Build and test against the contract.
Tests use realistic data, including malformed records, Arabic text, mixed scripts and legacy encodings.
-
Cut over one interface at a time.
Each interface runs in parallel with the old one until the outputs agree, then switches.
-
Operate and watch.
Volume, failures and staleness are monitored and the owner is alerted. Interkey can operate the interface estate as a managed service from Riyadh.
Questions buyers ask
Which ERP products do you integrate?
We build against the interfaces your ERP product documents: APIs, events, file exports or database access. We confirm the route for your ERP and version in the integration assessment.
Our ERP is old and has no API. Can it still be integrated?
Almost always: through its database, its files, its screens or its message queue, in roughly that order of preference. What matters most is that the interface is documented, owned and monitored.
Do you replace our ERP implementation partner?
No. We work alongside them on the integration workstream, while they remain accountable for the ERP itself.
Do we need middleware?
It depends on the number of interfaces. Estates with many interfaces sharing transformations benefit from a shared layer; a handful of interfaces is often cheaper point to point.
Can the integration run inside the Kingdom?
Yes, where that is required. Kong can run self-managed on infrastructure you operate in Saudi Arabia, and iblync can be deployed on-premise. Where each component runs is recorded in the interface contract.
Who looks after the interfaces after go-live?
A named owner per interface, on your side or on ours. Interkey can monitor and maintain the interface estate as a managed service.
Next
Read next
Next step
Start with an interface inventory
Tell us which ERP you run, which systems need its data, and which interfaces cause the most trouble today. We will propose the scope of an integration assessment and the pattern we would expect for each interface.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia