Business Central Consultant, Oman

From VAT posting setup to the figures on the return

Business Central works out VAT from two codes, one attached to the trading party and one attached to what is being sold or bought. Each pairing in the VAT posting setup holds the rate, the calculation type and the accounts. The VAT statement then sums entries by those combinations into lines, and those lines become your return working.

For an Omani company, I build the matrix with your tax advisor's guidance, because the treatment of each supply is their call and not mine. Typical combinations include:

• Standard-rated local sales and purchases.
• Exports and any further zero-rated categories your advisor confirms.
• Exempt supplies, where they apply to your business.
• Services bought from foreign suppliers, using the reverse charge calculation type.
• Goods imported through customs, where VAT is settled on the import document rather than on the supplier's invoice.
• Purchases where input VAT cannot be recovered.

I then map each combination to a statement line and run a dry return on test data. Any figure your accountant still has to adjust by hand points to a missing combination or a wrong default on a master record. Electronic invoicing is being introduced by the Tax Authority, so I also ask each bidder how their localization will meet it, without assuming an answer. The broader platform view is on the Dynamics 365 consultant Oman page.

Rial rounding beyond the general ledger

Setting three decimals for the rial in the currency table is the obvious step. The less obvious steps are where small differences appear later and quietly clutter the books.

• Amount, unit-amount and invoice rounding: each is a separate field. Unit prices for bulk goods may need more decimals than invoice totals, and invoice rounding to a convenient amount needs an account to post the difference.
• Application rounding: when a customer pays in a different currency from the invoice, conversion leaves residues. Defining an application rounding precision lets small differences close the entry instead of leaving it open.
• Payment tolerance: customers sometimes pay a few baisa short or over. A tolerance with its own accounts stops staff writing manual journals for each one.
• Exchange rate adjustment: with the rial tied to the dollar, dollar balances barely move, but euro, rupee or dirham balances still need periodic revaluation with agreed accounts for gains and losses.

I write a short set of rounding test cases: a multi-line invoice with unit prices at full precision, a foreign currency receipt applied to a rial invoice, a short payment within tolerance and a revaluation run. The partner runs them during UAT and finance signs the results. Apps the partner adds must pass the same tests, since a report or payment file that drops the third decimal undoes the work.

Posting groups and dimensions Omani finance teams actually use

Posting groups decide which accounts every transaction reaches without the user choosing them. Dimensions add the analysis. Both are easy to get wrong in the rush to load masters.

For Omani companies I usually separate customers into groups that matter to credit control and reporting: ministries and government-linked bodies with long payment cycles, private local customers, buyers in other GCC countries and related companies in the same group. Each gets its own customer posting group where finance wants a separate receivables account, and its own general business posting group where revenue should be split.

On the product side, general product posting groups separate goods, services, rental and contract revenue, while inventory posting groups split raw materials, finished goods and spares so the balance sheet tells a story without filters.

Dimensions then carry what posting groups should not: department, activity or branch, project or contract, and sometimes a salesperson or region for management reports. I set default dimensions on customers, vendors, items and fixed assets so users rarely type them, and value posting rules so cost accounts cannot be saved without the codes finance relies on.

This design is cheap on paper and expensive to change after go-live. My ERP solution design service covers how I document it.

Migrating Omani companies from Tally, local packages or NAV

Omani businesses come to Business Central from Tally, regional Arabic accounting products, QuickBooks and older Dynamics NAV installations. The approach differs with each.

Tally and many local packages hold customers, suppliers and expenses in one ledger tree, often with groups created over many years by different accountants. I rebuild masters to the new posting group design rather than copying the old tree, and I map old ledgers to new accounts in a table finance signs. NAV estates are a different conversation: the data model is familiar, but every customization needs a decision on whether to keep, replace with a standard feature or drop.

A typical Omani scope looks like this:

1. Customers and vendors with VAT registration details and the new posting groups.
2. Open invoices and credit notes with original numbers, currencies and VAT amounts.
3. Open purchase and sales orders.
4. Stock by location at an agreed cut-off, valued and reconciled to the ledger.
5. Fixed assets with cost and accumulated depreciation.
6. General ledger balances per period for comparison reporting.

Each load is reconciled to the source trial balance, aging and stock valuation before sign-off, and VAT control accounts are checked separately. The steps are described in ERP data migration and the migration checklist.

Reading an Omani Business Central proposal

In Oman, the VAT reports, Arabic invoice layouts and other local requirements in a Business Central project have typically come from partner or third-party add-ons instead of Microsoft's base application. Since that can change, I confirm the position for each project. What matters is that the proposal names the localization, its publisher and its subscription.

My review, following the vendor proposal review method, checks:

• Which VAT cases the partner will configure and test, and whether a return dry run is included.
• How the bidder plans to meet electronic invoicing requirements as they are introduced.
• Which document layouts are bilingual and how many are in scope.
• Whether the data load stops at masters or also brings open documents and balances.
• Who writes UAT scripts and how many rounds are supported.
• Support hours during your working week and how urgent issues are handled.

Since I hold no Microsoft partnership and take no license or build revenue, I can also say plainly when the product is heavier than your business requires, for example a single trading company that a cloud accounting product with Omani VAT support would serve well. For how I work across the country, see the Oman hub and my ERP consultant Oman page.