System Integration Consultant, Oman

Precision, rounding and currency across interfaces

Because rial amounts run to three decimal places, every baisa shows up in the ledger. Many outside systems do not work that way. A marketplace may report in rials rounded to two decimals, a gateway may settle in another currency, a foreign supplier's invoice may arrive in dollars or dirhams, and a POS may round each line differently from the ERP. Each mismatch is tiny, but across thousands of transactions they leave unexplained differences that finance has to clear by hand.

I treat precision as a requirement, not an afterthought. For each interface the specification states the currency and decimal places on both sides, whether tax is calculated per line or per document, which system's rounding wins, and where any difference is posted. Exchange rates get the same attention: which source is used, on which date, and how realized differences on settlement are booked.

Testing then checks totals at baisa level, not just whether records arrived. A day of sales, a gateway payout and a bank credit should agree exactly, or the difference should land in a known rounding account with an amount small enough to explain. That discipline also prepares the data for e-invoicing, where the invoice figures sent out must match the figures in the ledger. The wider ERP context is on the Oman ERP consultant page.

Getting interfaces ready for e-invoicing in Oman

Oman's Tax Authority is introducing e-invoicing, and businesses will need to produce and exchange invoices in a structured electronic form rather than as printed or PDF documents. The scope, model and timing for your business should be confirmed with your tax advisor, and details may change as the program develops.

From an integration point of view, the useful work can start before the rules apply to you. I review the data the ERP holds for customers, suppliers and items: legal names, VAT registration numbers, addresses, tax categories and units of measure. Gaps here will become rejected invoices later, and they are much cheaper to fix now.

Your ERP vendor or partner also receives a short written questionnaire from me. Will e-invoicing be handled by the vendor's own module, an add-on for Oman or an outside provider? How are invoices that fail validation shown and corrected? How are credit notes linked to their original invoices? Who manages credentials and certificates? Their answers, kept on file, become part of the integration plan and the test scripts.

Finally, I look at systems that create invoices outside the ERP, such as a POS, a billing tool or an online store. Each of them will need a clear route into the e-invoicing flow, or a change so the ERP becomes the single issuer. Compliance sign-off is not mine to give; my aim is that the interface design never becomes the weak link.

Banks, payroll and social insurance data

Most Omani companies exchange files with their banks rather than live connections. Supplier payments are uploaded to a corporate portal, statements are downloaded for reconciliation, and salaries are paid through the wage protection system. Each bank publishes its own layout, and layouts change from time to time.

For each file I write a mapping from ERP or payroll fields to the bank's format, with validation before the file is created: valid IBANs, beneficiary names within the allowed length, no blank amounts, totals that match the approved payment run. For WPS, employee identifiers, bank details and pay components must be consistent across HR, payroll and the file. Where a bank offers an API, I assess whether it is worth the extra setup compared with a well-controlled file process.

Payroll also feeds the ERP. Most businesses post a summarized salary journal by department, branch or project, together with social insurance contributions for eligible employees and accruals for end-of-service benefits. The mapping of pay elements to accounts is agreed with finance, and the treatment itself is confirmed by your HR or tax advisor.

I test every file with real bank samples and a parallel payroll before go-live. A rejected salary file is a stressful way to discover a mapping problem. The underlying approach is described under ERP integration.

Online sales, forwarders and warehouses

Omani retailers and distributors increasingly sell online, through their own store and through regional marketplaces, and take payments through bank-provided gateways and payment links. The integrations look familiar: orders and customers into the ERP, stock and prices out to the channels, refunds and returns back, and settlements into the bank. The details decide whether they work.

Operations and I settle the stock publishing rhythm for each channel and the warehouse behind it, so the website does not sell what the warehouse cannot ship. Orders are mapped with their tax, delivery charges and discounts, and each settlement is broken down so sales, charges, refunds and the money actually banked are visible separately. Cash on delivery collections from couriers get their own reconciliation route.

Trading companies also depend on outside parties for import data: forwarders, clearing agents and third-party warehouses. Many of them cannot offer an API. Rather than accept manual re-keying, I design structured import templates with validation, so shipment, container, duty and receipt details enter the ERP consistently and feed landed cost and stock in transit. If a partner later offers an API, the same mapping can be reused.

Every link gets a recorded method, chosen from a built-in connector, a middleware layer (Zoho Flow, Make or n8n, for example), scheduled files or bespoke code. My system integration page describes the options in general.

Monitoring, roles and support for small teams

Many Omani businesses have a small finance team and limited in-house IT. Integrations must therefore be simple to watch and clear about who acts when something breaks. A sophisticated design that needs a full-time specialist to keep it running is the wrong design for that company.

I specify error handling that a small team can live with. Records are validated before sending, temporary failures are retried a limited number of times, duplicates are blocked, and anything rejected goes to a visible queue with an email or chat alert to a named person. A short daily summary compares counts and totals between systems, so a stopped flow is noticed the next morning rather than at month-end.

Roles are written down. I own the interface catalog, specifications, test plan and acceptance. Your developers, an external specialist or the ERP partner build and fix the interfaces under agreed support terms. A person in the business owns monitoring and follows the runbook. Your company holds the credentials, configuration and documentation.

Tests run end to end with real files before go-live, and finance reconciles a sample at baisa level. See testing and UAT for the approach, the Oman CRM consultant page for the sales side, or the Oman overview. I deliver the work remotely; a visit can be arranged if it genuinely helps.