ERP Implementation Consultant, Oman

Where Omani ERP rollouts usually go wrong

The issues that hurt Omani ERP projects are rarely exotic. They are ordinary risks made sharper by small internal teams and partners who are often not in the same city:

• Too few people on the client side. The partner has a full team, while the business has one or two people answering every question. Decisions are delayed or made without the right person present.
• Rounding left until the end. Precision settings for currency, unit price and quantity are not agreed early, and differences of a few baisa appear across thousands of lines at the first close.
• VAT codes mapped in a hurry. Tax codes from the old system are copied rather than redesigned, so returns built from the new ledger need manual adjustment.
• Bank and payroll files untested. Supplier payment batches and WPS salary files are generated for the first time on the day they are needed.
• Distance hiding problems. With a remote partner, configuration can drift from what was agreed without anyone noticing until UAT.

Each of these is avoidable with structure and early testing. My role is to bring both from the business side and keep them in place when deadlines tighten. If a project is already badly off course, an ERP health check or recovery is a better first step than routine oversight.

Running the project when your team is small

A small team does not have to mean a weak client side. It means the time your people give to the project has to be used well. At the start, I map who in your business can contribute, how many hours they realistically have and which decisions only they can make. That becomes a simple responsibility chart the partner can see.

From there, I take on the coordination load: preparing agendas so workshops end with decisions, chasing open questions between sessions, maintaining the decision log, and turning the partner's design documents into short summaries your managers can approve without reading every page. When a design choice needs the owner or general manager, I bring it to them with the options and the trade-offs already laid out.

I also watch the partner's progress closely, because a partner working from a neighboring country or from abroad can drift from the agreed design without anyone in Oman seeing it. Regular configuration demos on your own data, a shared change register and written approval for every scope change keep the build visible.

None of this replaces the partner's platform skills. It makes sure those skills are applied to your requirements and that your staff can sign off with confidence. My general approach is set out under ERP implementation, and if no partner has been chosen yet, see the Oman ERP selection page.

Migrating balances without baisa gaps

Omani businesses come to a new ERP from Tally, QuickBooks, Sage, local accounting packages and a lot of spreadsheets. Some of those sources store amounts or unit costs with different precision from the new system, or were set up years ago with settings nobody remembers. When balances move, small rounding differences can appear in places that are hard to trace later.

The partner or your IT team handles extraction and loading. From the business side, I own the plan and the checks:

• Agree precision for currency, unit price and quantity in the new system before the first trial load, and document it.
• Define what moves: masters, open invoices and bills, balances, stock and how much transaction history.
• Assign clean-up owners for customers, suppliers and items, including VAT numbers on registered parties.
• After every trial load, reconcile the trial balance account by account, open receivables and payables by party, stock quantity and value by warehouse, and VAT control accounts.
• Investigate any difference, however small, until its cause is known and fixed at the source.

Stock deserves extra attention. Unit costs carried at many decimal places can produce a valuation that does not match the ledger by a few baisa after loading. Agreeing in advance how that difference will be handled saves a long argument at the first close. The ERP data migration page explains the full method, and migration from Excel covers spreadsheet sources.

Cutover around VAT periods, payroll and e-invoicing

Choosing when to go live is a business decision, not just a project milestone. I help you pick a cutover point with your accountant that avoids landing in the middle of a VAT return period, so one return is not prepared from two systems. Where that is unavoidable, we agree how the return will be assembled and who checks it.

Payroll needs the same care. Omani salaries go through the Wage Protection System, which means the bank must accept the very first salary file the new system creates. I plan a cutover between pay periods, a parallel run whose results are matched employee by employee against the old payroll, and a test of the salary file in your bank's required format before go-live. Employment and social insurance rules are confirmed by your HR advisor.

E-invoicing adds a further layer once Oman's program applies to your business. Its scope and timing are set by the Oman Tax Authority. When it applies, issuing and transmitting test invoices through the chosen solution, handling a rejection and issuing a credit note against an e-invoice all belong in UAT before cutover, not after.

The cutover plan itself lists every step with an owner and a check: freeze points in the old system, final loads, reconciliation sign-offs, user access, bank file activation and rollback criteria. More detail is on the ERP go-live support page.

Testing, training and hypercare with Omani teams

UAT scripts are written from your processes, not the partner's standard tests. For a trader, that might mean an import with freight, customs and clearing charges added to landed cost, a sale with a three-decimal price and a credit note. For a logistics business, a job opened for a shipment, costs captured from several suppliers and re-billed to the customer. For an energy-sector supplier, a job ticket billed against a call-off with spend tagged for In-Country Value reporting. Bilingual documents are checked on screen and on paper by your staff.

Training is planned by role. Key users are trained first, help test, and then support their colleagues. Any Arabic material is produced and reviewed by your own staff or the partner. I track attendance and readiness as part of the go-live criteria.

Once the new system is live, key users, the partner and I meet briefly each day. Each issue is classified as a training need, a data problem, a configuration defect or a new request, and routed accordingly. Hypercare lasts until finance has closed a full period and filed a VAT return from the new ledger, because those two events expose most hidden faults.

Sessions are held online in English; time on site is possible only by arrangement. The Oman ERP consultant page and the ERP testing and UAT page add more background.