System Integration Consultant, Jordan

The e-invoicing connection as an interface, not a checkbox

Jordan's tax department runs a national e-invoicing system, and for companies in scope each relevant invoice has to reach it. Selection discussions tend to ask only whether a connector exists. The integration questions go further, because this interface touches every sale you make.

I specify the connection like any other critical interface:

• Where it runs. A module inside the ERP, a separate service hosted by the implementer or a third-party provider. Each has different failure points and different owners.
• When it fires. On posting, in batches or on a schedule, and what users can do with an invoice while its submission is pending.
• What comes back. Acceptance references, any code the printed invoice must carry and rejection reasons, all written back to the invoice record where finance can see them.
• How failures are handled. A queue of failed submissions, retry rules for connection errors and a correction route for data errors that does not create duplicate documents.
• How credit notes link. Each credit note referencing the original accepted invoice.

A daily control compares invoices posted in the ERP with submissions accepted, so a gap is found the next morning rather than when the sales tax return is prepared. Which invoices are in scope and which fields they need is for your tax advisor; my job is seeing their guidance reflected in the mapping and the test cases. The testing of vendor claims during a purchase is covered separately on my ERP selection page for Jordan.

Banks, payment services and receipts in dollars

Jordanian companies often keep accounts in dinars and US dollars, and exporters of services receive much of their income from abroad. Bank integrations need to reflect that. A dollar receipt arrives with intermediary charges deducted, possibly converted at a rate the bank applied, and the ERP must record the original invoice currency, the amount received, the charges and any exchange difference as separate facts.

Typical interfaces I specify:

• Statement imports by file or feed, depending on what each bank provides, with reference fields mapped for automatic matching.
• Supplier and salary payment files in the formats your banks' corporate portals accept, generated from approved payment runs in the ERP.
• Receipts from the bill payment and instant transfer services available through Jordanian banks, where customers use them, mapped to customer accounts by reference.
• Post-dated checks received and issued, tracked in the ERP through to clearing, with the bank statement confirming each one.

Dinar amounts use three decimals, so each mapping carries a precision check that follows an amount from ledger to bank file and back. Bank capabilities differ, and I confirm with each bank and your treasury team what is actually available rather than assuming an API exists. Where only manual downloads are offered, a controlled import routine with validation is often the sensible answer.

Distributors, pharmacies and third-party warehouses

For Jordanian distributors, especially in pharmaceuticals, medical supplies and FMCG, the integrations that matter most are often on the operations side. Orders arrive from sub-distributors, pharmacy chains and hospital buyers through portals, apps, spreadsheets or messages. Goods may sit in a third-party warehouse in Amman or move through Aqaba with a freight forwarder.

I design these flows around stock accuracy and traceability:

• Order intake mapped to customer codes and price lists in the ERP, with batch allocation done by the ERP rather than by the ordering channel.
• Warehouse interfaces that send dispatch instructions and receive confirmations with batch numbers and expiry dates, so a recall trace works across both systems.
• Inbound shipments from forwarders and clearing agents, with landed cost elements arriving as documents the ERP can allocate.
• Stock snapshots from the warehouse compared daily with ERP balances, with differences reported to a named person.

File exchange is still common with logistics providers, and that is fine if it is automated, validated and monitored. Test cases cover partial shipments, returned goods with a different batch, short-dated stock and a warehouse file that arrives twice.

For the industry background, see pharmaceutical ERP and distribution ERP.

Gulf sister companies, group reporting and payroll

Many Jordanian companies belong to groups with entities in the Gulf, or serve as regional offices of international firms. That adds integrations between companies: intercompany charges for shared services, recharges of staff costs and data feeds into a group consolidation or reporting tool.

I specify intercompany flows so both sides record the same transaction with matching references, currencies and dates. Where entities run different ERPs, which is common, I define the document that triggers each flow, the mapping between charts of accounts and a monthly reconciliation of intercompany balances. Group reporting is usually built in Power BI or the parent's own tool, fed from each ERP with agreed definitions of revenue, margin and headcount.

Payroll is normally prepared by a local provider or a payroll module, with social security contributions calculated there. The ERP receives summarized journals by cost center or project, and employee master data has one home. For services exporters, approved timesheets often feed both payroll cost allocation and client billing, so I make sure there is a single approved source of hours.

Statutory payroll and social security rules are for your HR advisor and provider to confirm. My job is that data arrives complete, balanced and on time, and that someone is alerted when it does not. For multi-entity design more broadly, see ERP for multi-company groups.

Resilience, monitoring and who supports each interface

Connectivity in Jordan's cities is generally good, but interfaces should still assume that a connection, a provider or a server will fail at some point. Each one I specify has retry rules for temporary errors, a holding queue for records that need correction, protection so a repeated message cannot create a duplicate, and an alert that reaches a specific person instead of a mailbox nobody owns.

The method follows the requirement. A product's own connector is preferred where it genuinely covers the need. A middle layer such as Make, n8n or Zoho Flow becomes worthwhile when many applications trade the same records. Custom API work is justified for high volumes or complex logic. I compare options on reliability, cost drivers and who in Amman will maintain them after the project team leaves.

The build is done by your developers, an integration firm or the implementer; I review it against the specification and run end-to-end testing with your staff. For a small flow that a standard connector or low-code tool handles, I sometimes set it up myself.

Before go-live, the support agreement should say who fixes each interface and how quickly. Afterward, I can review logs and error trends remotely. For the sales side of the same picture, see my CRM consultant page for Jordan; to keep the implementer on track, my implementation oversight work in Jordan; and for other services, the Jordan hub.