Integration Consultant, Kuwait

Shared master data across a Kuwaiti group

In a family group, the same customer may buy from the trading company, hire the contracting arm and hold a service contract with a third company. The same item may be bought by one company and sold by another. When each company keeps its own records, names and codes drift apart, and group reporting turns into a manual matching exercise every quarter.

Integration design in that setting starts with ownership. I run a working session with finance and the operating companies to agree, for each type of record, where it is created and who may change it. Customers might be created centrally with company-specific credit terms; items might be owned by the trading company and shared with the others; employees might sit in one HR system serving the whole group.

Then I define how shared records are matched. Commercial license numbers, civil ID numbers for individuals, supplier codes and item codes are better keys than names, which appear in Arabic and in several English spellings. Where companies run on different systems, the specification sets out how records are synchronized, in which direction and how conflicts are handled.

Getting this right first makes every later integration simpler. The wider ERP picture for groups is on the Kuwait ERP consultant page.

Intercompany transactions without manual mirroring

Kuwaiti groups trade with themselves constantly. The trading company supplies materials to the contracting arm, a central kitchen supplies restaurants, a services company charges management fees to the others. In many groups each side is entered by hand in each company's books, and the balances rarely agree at month-end.

When the group runs one ERP with several companies, the platform may handle intercompany documents natively, and my work is to configure the rules and test them. When companies run different systems, an integration has to carry the transaction across. In both cases I specify the flow in detail:

• The trigger, such as a confirmed sales order or a delivery in the selling company.
• The matching document created in the buying company, with the same quantities, prices and references.
• Pricing rules for transfers between companies, agreed with finance and your advisor.
• How returns, partial deliveries and price corrections are mirrored.
• The reconciliation report that shows any unmatched balance by company pair.

Consolidation itself is a finance task, but integration can make it easier by tagging intercompany transactions consistently so they can be eliminated. I test the flow with real cases from each pair of companies, including the awkward ones, before the group relies on it. The general approach is on my ERP integration page.

KNET, delivery apps and outlet sales

Restaurant, café and retail brands in Kuwait take payments through KNET debit cards, credit cards, payment links and cash, and many sell through delivery apps as well as their own channels. Each payment route settles differently. KNET and card gateways pay out on their own cycle with fees deducted; delivery apps send periodic statements netting commission, promotions, refunds and sometimes cash collected by drivers.

I design settlement integration so finance can see, for each brand and outlet, what was sold, what each provider kept and what actually reached the bank. Each statement or payout is broken into its parts and matched against POS or order totals for the period it covers. Differences are listed for review rather than absorbed silently into a suspense account.

POS integration follows the same discipline. Sales normally reach the ERP grouped by outlet and day, split by payment method, category, discounts and voids, while each receipt remains in the POS. Item and price ownership is agreed first: if the ERP or a central system owns the menu and price list, POS terminals receive updates rather than being edited branch by branch.

Central kitchens and warehouses add stock transfers to outlets, which link back to the intercompany design where outlets sit in different companies. My system integration page covers the general method.

Payroll, salary transfers and method choice

Payroll in a Kuwaiti group often spans several companies and very different workforces, from office staff to site labor and restaurant teams. Salaries are paid by bank transfer, social security contributions for Kuwaiti employees go through PIFSS, and each company needs its own payroll journal. Pay rules and contributions are confirmed by your HR advisor; my concern is that the data flows correctly.

I map employee master data, pay elements and cost allocation from HR or payroll to the bank's salary transfer file and to a summarized journal per company and cost center. Validation runs before a file is produced: valid IBANs, matching totals, no missing civil ID numbers. I test with a parallel payroll and real bank samples before the first live run.

For each interface in the landscape I then choose the method. A native connector is preferred when it covers your cases. Middleware such as Zoho Flow, Make or n8n suits a group that wants one place to see several flows. Scheduled files remain right for many bank processes. Bespoke code earns its place only where volumes or business rules exceed what the other routes handle, and the group should own that code outright.

Every flow validates data, retries temporary failures within limits, blocks duplicates and sends rejected records to a queue someone actually watches.

Testing, ownership and who does what

Integration testing in a group has to cross company lines. A test case might follow an order from the trading company to the contracting arm, through delivery and both sets of books, then check that the intercompany balance is zero. Another follows a day of restaurant sales from POS and delivery apps to the bank and the ledger. Tests include returns, cancellations, duplicate messages and a connection failure. Finance confirms the results before sign-off, within the testing and UAT plan.

Roles are written down from the start. I own the design: the ownership matrix, interface specifications, method choices, test plan and acceptance. Your developers or implementation partner build the interfaces and fix defects under agreed terms. Inside the group, someone in finance or IT receives alerts and follows a short troubleshooting guide. The group holds credentials, code and documentation, so it is never dependent on one supplier.

Groups often roll out company by company, and integrations should follow the same sequence. I plan which links each wave needs, so later companies join a tested pattern rather than a new design. The Kuwait CRM consultant page covers the sales side, and the Kuwait overview lists other services. The work is remote, with visits by arrangement.