ERP Requirements Consultant, Oman

Structure of an Omani ERP specification

Omani finance and operations teams are often small, so the specification has to be easy for a busy manager to review. I keep it in a handful of chapters with one owner each:

• Organization: legal entities, any free zone or special economic zone units, branches and warehouses, users by role and the systems in use today.
• Process requirements: quotation to collection, purchase request to supplier payment including imports, stock and costing, service or project delivery, payroll and the close.
• Statutory chapter: VAT, e-invoicing data, salary transfer output, Arabic documents and how long records are kept.
• Precision and behavior: currency handling, hosting, access, audit and load.
• Interfaces and migration.
• Reports for owners, finance and, where it applies, contract or In-Country Value reporting.

Every requirement is a single sentence carrying its code, owner, ranking and pass condition. A good test for any line is whether two different vendors could read it and reach the same understanding. "Good inventory control" fails that test. "Stock must be valued per warehouse, with landed cost including freight and customs duty allocated to the receipt before the item is sold" passes it.

The workshops and process mapping behind these lines are described on my Oman ERP business analyst page. What follows here is about the finished specification and how it is put to work.

Precision rules for the Omani rial

The rial is divided into baisa, so amounts carry three decimal places. Many ERP products handle that well, but some default to two decimals in places nobody checks until a bank file or tax report is wrong. A requirements specification is the right place to stop that, because it turns an assumption into a contractual rule.

I write the precision chapter as a set of explicit statements, for example:

• All monetary fields, including document totals, tax amounts and ledger balances, must store and display three decimals in rial.
• Unit prices must allow at least the precision your price lists use, which may be more than the currency itself.
• Rounding of tax must follow the method your advisor confirms, whether per line or per document, and the method must be the same on screen, on the printed invoice and in the return report.
• Payment files, statement imports and any e-invoicing output must carry amounts at full precision.
• Foreign currency purchases must revalue into rial without leaving residual baisa differences in clearing accounts.
• Exports to spreadsheets and BI tools must keep three decimals.

Each statement gets a test case built on awkward amounts, such as a quantity with a fractional price and a discount, so the result can be checked by hand. Read alongside the multi-currency ERP page, this chapter protects finance from small errors that grow into reconciliation work every month.

VAT, e-invoicing and WPS as testable statements

Oman's VAT is administered by the Tax Authority, which has also announced an e-invoicing program. The scope, phasing and technical model come from official guidance and may be refined, so I draft this chapter with your finance team and have your tax advisor confirm each line before sign-off. I do not give tax advice; I make sure what the advisor tells you becomes a requirement someone must deliver.

Typical statements include:

• Each sales and purchase line must carry a VAT code from an agreed list, defaulted from item and party, which only an authorized finance user may override.
• Printed invoices and credit notes must show the content your advisor lists, in Arabic and English where required, with the Arabic layout approved by an Arabic-speaking reviewer you appoint.
• Imports must record the information needed for import VAT and its recovery, as confirmed by your advisor.
• Customer and supplier records must hold validated tax registration numbers and structured addresses, ready for structured e-invoices.
• Once e-invoicing applies to you, invoices must leave the system by the submission method the vendor has described in writing, with each response stored against the invoice, and route rejections to a named role.
• Where the Wage Protection System applies, the payroll module or the outside payroll service must create a salary transfer file in the layout your bank specifies.

The wider tax context in Oman is covered on my Oman ERP consultant page.

Behavior, interfaces and migration requirements

Behavior requirements set how the system must operate. For Omani companies I specify where production and backup data may be hosted and what your legal team should verify against Oman's personal data protection law, phrased as questions vendors answer in writing. Access is defined by role and entity, with approval limits matched to delegated authority, and the audit trail must keep old and new values for bank details, prices, tax codes and credit limits. Load is described in plain terms, such as the number of invoices raised on the last working day of the month, and branches outside Muscat or units in a free zone need a stated way of working when connections are slow.

Each interface is its own requirement block: the systems at both ends, the data, the direction, the frequency, the master record and how errors surface. Bank payment and statement files, the salary transfer route, freight or customs data for importers, HR systems and the future e-invoicing provider are common entries.

Migration requirements say which master data moves, which open invoices, orders and stock balances transfer, how much history is kept, what is archived instead, and how opening balances are reconciled per entity to the baisa. Execution of the move itself, after selection, belongs to ERP data migration.

Priorities, traceability and contract use

Owners rank every line on a plain scale: must have at go-live, should have, could have, or not in this phase. Must-have lines then move through a traceability matrix into scripted demo scenarios used on my Oman ERP selection work and later into UAT cases. The same matrix holds each platform's fit result, so a missing capability is visible before contract rather than during testing.

The signed specification goes into the RFP as a requirement annex with a response column per line, and a frozen baseline is attached to the implementation contract. After that, each change needs a short request with its reason, approver and effect on cost. Finance signs the statutory chapter only once the advisor's confirmation is attached.

Gaps that put Omani specifications at risk:

• No precision chapter, leaving baisa handling to defaults.
• E-invoicing written as "compliant when required", with no data or exception lines.
• Free zone units treated as departments rather than entities.
• Arabic printouts with no approval step.
• Salary transfer output assumed, never specified.

For the tender process built around the specification, see ERP RFP consulting, or visit the Oman overview.