Integration Consultant, Saudi Arabia

E-invoicing as an integration, not just a feature

ZATCA's e-invoicing rules turn the invoice into a data exchange. Depending on the invoice type, documents are either cleared by the platform before they go to the buyer or reported to it after issue, and businesses are brought into the integration phase in waves. The exact obligations and timing for your company are a question for your tax advisor.

From an integration point of view, three questions matter. First, who provides the connection: the ERP vendor's own module, a localization add-on or a separate e-invoicing solution provider sitting between the ERP and the platform. Second, how device onboarding, cryptographic stamps and credentials are managed, and who renews them. Third, what happens to a rejected or warning invoice: where it appears, who corrects it and how the corrected document is linked to the original.

I review the chosen approach against those questions, specify the fields the ERP must supply, such as buyer VAT number, commercial registration and national address elements, and check that master data is complete before the switch-on. Testing runs in the sandbox where one is available, with standard, simplified, credit note and debit note cases. I do not build the connector itself, and I do not certify compliance; I make sure the interface is designed, tested and owned properly. The ERP-wide picture is on the Saudi ERP consultant page.

Payroll, wage protection and banking flows

Payroll integrations in the Kingdom touch several outside systems. Salaries are paid through banks and checked against the wage protection platform, social insurance contributions depend on accurate employee records, and the ERP needs summarized salary journals by cost center, branch or project. When payroll runs in a separate HR system, every one of those flows has to be designed.

The design starts with employee master data: national ID or Iqama number, IBAN, contract pay elements, cost allocation and status changes such as leave or final settlement. I check where each field is created and which system is the source of truth, then map the payroll output to the bank's salary file layout and the journal the ERP expects. End-of-service provisions and their accounting are agreed with finance and your advisor, not assumed.

Banking flows are next. Supplier payment files, statement imports and, where your bank offers them, API connections each need a mapping, a validation step and a reconciliation rule. I test with real bank sample files and a parallel payroll run before go-live, because a rejected salary file is a bad way to find a mapping error. The broader design method is on my ERP integration page.

Cards, marketplaces and delivery partners

Saudi consumers pay by mada and other cards, digital wallets, payment links and, for some retailers, deferred payment services. Every provider pays out on a different cycle, and fees are taken before the money arrives. If the ERP records only the bank credit, finance spends days matching it back to orders.

I design settlement mapping that breaks each payout into gross sales, refunds, chargebacks and fees, links them to orders or POS receipts, and posts the net to the right bank account. The same approach applies to marketplace payouts, which often include commission, delivery charges and promotional deductions on one statement.

Online sales also need order, stock and return flows. I agree with operations how often stock is published to each channel, which warehouse fulfills which region, how returns are received and credited, and what happens when an item is out of stock after an order is accepted. Courier and third-party warehouse links follow: shipment creation, tracking status, proof of delivery and cash on delivery collections, which need their own reconciliation.

For each of these I record the method. Some channels have reliable native connectors, others are better served by a middleware layer like Make, n8n or Zoho Flow, and high-volume retailers may justify a custom service. My system integration page explains the general approach.

Specifications, error queues and testing

Every interface I design ends up as a written specification. It sets out what starts the flow, which way data travels and how often, the keys used to match records, each field's mapping and conversion, validation, retry behavior and the person in the business who owns the flow. The specification is what your developers build from, what testers test against and what a new support partner reads later.

Error handling gets as much attention as the happy path. In a Saudi landscape the most damaging failures are silent ones: an invoice stuck between the ERP and the e-invoicing platform, a gateway notification received twice, a stock update that stops overnight. I specify validation before data is sent, a limited number of retries for temporary errors, duplicate detection for repeated messages, and an error queue with alerts to a named person. A simple daily control report compares counts and totals between systems.

Testing combines sandbox runs with real-world samples: bank files, gateway reports, marketplace statements and a full payroll cycle. Scenarios include credit notes, partial deliveries, cancellations, refunds and network failures. Finance reconciles a sample of test transactions before anything is switched on. This fits inside my testing and UAT approach, and the CRM handoff side is covered on the Saudi CRM consultant page.

Roles, partner oversight and support after go-live

Saudi integration projects often involve several parties at once: the ERP implementation partner, an e-invoicing solution provider, a payroll vendor, a gateway and sometimes a separate development firm. Without one person holding the design together, each party tests its own piece and nobody tests the whole chain.

That is the role I take. I own the interface catalog, the specifications and the end-to-end test plan, coordinate the parties against them and accept or reject what is delivered. I do not write the production code for complex interfaces; that sits with your developers or partners. For simpler native connectors and low-code automation I can usually set things up directly.

Before go-live I make sure each interface has a support arrangement in writing: who receives alerts, who fixes what, expected response times, and who holds credentials, certificates and documentation. Certificates and tokens that expire deserve a calendar owner. Once live, the interfaces deserve a closer watch until finance has closed a full month and prepared a VAT return from the new data, since that is when gaps surface.

All of this is delivered remotely, with any visit only by arrangement. The engagement runs in English; Arabic documents and screens are checked by your team. To see the other ways I help, visit the Saudi Arabia overview.