What is a SIF file?

SIF stands for Salary Information File. It is the flat text file Omani banks use to ingest monthly payroll under the Wage Protection System (WPS). One file carries one employer, one pay period, one salary frequency and inside it, one row per employee. That is the whole shape of it. No headers. No spreadsheet formulas. Just rows and fields, delimited by commas or tabs.

WPS became mandatory in Oman in July 2023. Since then, every private-sector employer registered with the Ministry of Labour has had to route salaries through a licensed Omani bank in this exact format. The spec is maintained by the Central Bank of Oman and is currently on version SIF v4.1. Every bank in the country Bank Muscat, NBO, Bank Dhofar, Sohar International, Oman Arab Bank, Ahli, Nizwa, Meethaq, Maisarah, Al Hilal, and the rest parses the same 16 fields.

The 16 fields, in order

A SIF file has no header row. The fields are positional the bank identifies each value by its column position, not by a label. Get the order wrong and the file is rejected wholesale. Here is the full layout:

1. Salary Year 4-digit year, e.g. 2025.
2. Salary Month 1 or 2 digits, 1 through 12.
3. Employee ID Type single character, C for Civil ID or P for Passport. Uppercase only.
4. Employee ID up to 17 characters. Digits only when the type is C; no leading zeros; alphanumeric when the type is P.
5. Employee Name up to 70 characters. Must match the ID document. Arabic is supported if the file is UTF-8.
6. Bank Code 8 to 11 characters, the SWIFT-style code the employee banks at. Example: BMUSOMRX for Bank Muscat.
7. Account Number up to 30 characters. Typically an Omani IBAN (23 characters starting with OM), alphanumeric only.
8. Salary Frequency single character, M for monthly or B for bi-weekly. Uppercase only.
9. Number of Working Days whole number, 0 to 31.
10. Net Salary decimal in OMR, up to 3 decimal places.
11. Basic Salary decimal in OMR, up to 3 decimal places. Must be greater than zero for a salary file.
12. Extra Hours decimal, up to 2 decimal places. Optional.
13. Extra Income decimal in OMR, up to 3 decimal places. Overtime pay, allowances, bonuses added on top of basic.
14. Deductions decimal in OMR, up to 3 decimal places. Loan repayments, advances, disciplinary deductions.
15. Social Security Deductions decimal in OMR. The SPF contribution withheld from the employee.
16. Notes up to 300 characters. Optional but critical when anything out of the ordinary is happening on a row.

Every row must have exactly 16 fields. Sixteen values separated by fifteen delimiters. A missing or extra delimiter is one of the most common reasons a whole file gets bounced the parser at the bank expects positions, and position 17 does not exist.

Delimiters: commas or tabs

Banks accept two delimiters: comma (.csv) or tab (typically .txt). You pick one per file and stay consistent. Most banks will take either, but each bank has a preference check your bank's portal before you upload. Ujoor auto-detects whichever you used.

A small trap: if your file is comma-delimited, decimals must use a period (.), not a comma. Using a locale that writes 350,000 instead of 350.000 will turn one number into two fields and the row will fail length validation immediately.

UTF-8 is not optional

SIF files must be saved as UTF-8. This is how Arabic employee names survive the trip from your payroll system to the bank. Save a file as Windows-1256 or ANSI and Arabic names arrive as garbled question marks or the bank's parser refuses the file entirely.

The most common way this goes wrong is opening a SIF in Excel, editing it, and hitting Save. Excel will happily re-encode the file in whatever your locale defaults to. If you need to inspect or tweak a SIF, a plain text editor (VS Code, Notepad++, Sublime) is safer or upload it to Ujoor and edit it there, which guarantees UTF-8 on export.

A sample valid row

Here is one comma-delimited row that passes every check:

2025,11,C,12345678,AHMED MOHAMMED AL SAID,BMUSOMRX,OM020201012345678901,M,26,406.250,350.000,8,137.500,50.000,31.250,8 overtime hours and loan repayment

Read left to right: November 2025, Civil ID 12345678 for Ahmed Mohammed Al Said, banking at Bank Muscat (BMUSOMRX) on IBAN OM020201012345678901. Monthly frequency, 26 working days. The salary math: 350.000 + 137.500 − 50.000 − 31.250 = 406.250. The Notes field explains the overtime and the loan deduction so the Ministry has context.

The one cross-field rule that catches everyone

Net Salary must equal Basic + Extra Income − Deductions − Social Security. Always. Tolerance is 0.001 OMR for rounding. If your payroll software computed Net Salary independently instead of deriving it from the other columns, you will see silent mismatches the kind Excel hides behind formula cells.

When the math does not balance, the Ministry of Labour may flag the row. If there is a legitimate reason (mid-month joiner, unpaid leave, end-of-service), put it in Notes. An empty Notes field beside an unbalanced row is a near-certain flag.

How the SIF reaches the bank

The employer generates the SIF from payroll, runs it through a validator (such as the one at Ujoor) to catch any issues before sending, and then uploads it through the bank's WPS portal. The bank checks the file against the CBO spec, queues the salary transfers, and reports the outcome back. A clean file pays on time. A rejected file buys you a round-trip, usually right when you can least afford one.

Common misconceptions

“It's just a CSV, I can open it in Excel”

You can, but you probably should not. Excel will reformat numbers, strip leading zeros from Civil IDs, change the encoding, add BOMs, and generally make the file unusable without telling you. Civil ID 01234567 becomes 1234567. A basic salary of 350.000 becomes 350. The file still looks normal, but it will fail at the bank.

“One SIF per payday is fine, I can mix frequencies”

No. A SIF file is tied to one salary frequency. Monthly and bi-weekly employees go into separate files. One employer, one pay period, one frequency, one file. Mixing them is a file-level rejection.

“The bank will tell me exactly what is wrong”

Bank portals vary. Some give you row-level feedback; others return a single line like “file rejected invalid format.” You generally do not want to find out from the bank. Validate locally first.

“The IBAN checksum does not matter because it is all Oman”

It does. Omani IBANs are 23 characters OM + 2 check digits + 3-digit bank code + 16-digit account. A wrong check digit is rejected instantly. A wrong account with a valid checksum sends salary to a stranger. The validator at Ujoor checks both length and checksum, and recognises every licensed Omani bank code.

“Social Security applies to everyone”

Currently, the Social Protection Fund (SPF) employee contribution is 8% for Omani nationals, capped at OMR 240/month (8% of a OMR 3,000 salary ceiling). Expatriate employees have a different structure. If a file puts 8% on every row regardless of nationality, the math will look consistent but may not match what the Ministry expects for non-Omani employees. See the WPS guide for the full breakdown.

Where this leaves you

A valid SIF file is a boring text file with strict rules. Every rule in the spec exists because some payroll team hit it once and broke payday. You can learn them the hard way, or you can drop your file into the validator, see every issue inline, fix them in place, and download a clean file ready for the bank. Either way, the goal is the same: pay your team on time, every time.