Extract UAE Payslips to Excel: Basic, Allowances & WPS

You have a folder of UAE payslips, perhaps a Wage Protection System export alongside them, and a job to finish: a monthly pay-run reconciliation, a gratuity-accrual schedule, a WPS audit, or a migration into your accounting or HR system. The slips might be clean PDFs, scanned copies, phone photos, or bilingual Arabic and English layouts. What you need is the data in a structured spreadsheet, not a week of retyping. This guide is about that job: extracting the payslips you already hold, not creating new ones from a template.

That distinction matters, because most search results for UAE salary slips lead to generators and blank templates. The work here is the opposite direction. To extract UAE payslips to Excel in a form that actually survives scrutiny, capture each employee's basic salary and every allowance — housing, transport, communication — as separate columns. End-of-service gratuity and GPSSA pension are calculated on basic pay alone, so a spreadsheet that folds basic and allowances into a single "gross" figure has already lost the number your downstream calculations depend on. Map the WPS fields when they are present, the Labour Card number, IBAN, and MOHRE establishment number, and flag whether each employee falls under the national or expat deduction profile. The target is one row per employee per pay period.

A UAE payslip is not a regional skin on a generic one. There is no income tax to withhold, so there is no PAYE-style deduction line to extract; the entire deduction structure differs from a UK, Irish, or German slip. And earnings split into basic plus distinct allowances in a way that is load-bearing for everything that comes after. Generic PDF-to-Excel converters were not built around that model, which is why they tend to collapse the structure that a UAE accountant most needs to preserve.

The rest of this guide works through the extraction end to end: what a UAE payslip contains, why the basic-versus-allowance split is the decision everything hinges on, the prompt and column schema that produce a clean dataset, how to handle WPS and SIF data, nationals versus expats, and the bilingual and scanned slips that defeat simpler tools, finishing with the output shape and how to run the same extraction across a full batch.

What a UAE Payslip Actually Contains

Before you decide on columns, it helps to read a UAE payslip as a list of extraction targets rather than a document. Most slips group into three blocks: who the employee is, what they earned, and what was deducted to reach net pay.

The earnings block is where UAE payroll diverges from most other countries. Pay is not a single salary figure. It is a basic salary plus a set of separately itemised allowances, most commonly housing, transport, and communication, and sometimes a meal allowance or other employer-specific lines. These appear as distinct rows on the slip, and they need to stay distinct in your spreadsheet. Each allowance is its own column, not a number swept into a combined total. The slip usually also shows gross earnings, which is simply basic plus all allowances.

The deduction block is short, and what is missing from it is the point. There is no income tax in the UAE and no PAYE-style withholding line, so the deduction structure looks nothing like a UK slip with its income tax and National Insurance, or an Irish slip with PAYE, USC, and PRSI. What you will see instead, where it applies, is a statutory pension deduction for UAE and GCC nationals, an unemployment-insurance premium, and any employer-specific items such as a salary advance or a loan repayment. For a large share of the expat workforce, the deduction block is close to empty.

The identification block carries the fields that make a row traceable and reconcilable. Capture the employee name, the staff or employee ID, the designation, and the pay period. Where the slip includes them, also capture the Labour Card number, the MOHRE establishment number, and the bank IBAN. These three may feel like header noise when you are looking at a single slip, but they are the keys that let you match a payslip against a WPS file later, so pull them into their own columns from the start.

Finally, the net pay line ties the slip together: gross earnings minus total deductions equals net pay. It is worth capturing net explicitly rather than recalculating it, because it is the figure that should reconcile against what actually left the bank.

The practical consequence of all this is straightforward. With no tax line to reconcile, the analytical value of a UAE payslip lives almost entirely in how its earnings are decomposed. An extraction that preserves that decomposition gives you something you can audit and build on. One that flattens it gives you a net-pay total and very little else.

Why the Basic-vs-Allowance Split Is Load-Bearing

If you take one extraction decision seriously, take this one: keep basic salary and each allowance in separate columns. It is the difference between a spreadsheet you can defend in an audit and one that quietly throws away the figure your calculations need.

The reason is that the most consequential UAE payroll entitlements key off basic salary alone, not total earnings. End-of-service gratuity, leave encashment, and GPSSA pension contributions are all computed on the basic figure. Allowances, however large, do not enter those calculations. So the moment an extraction merges basic and allowances into a single "gross" column, the gratuity and pension base is gone, and no amount of downstream spreadsheet work can recover it from the combined total.

The gratuity rules make the stakes concrete. Under the UAE Labour Law, gratuity is calculated on basic salary at 21 days' pay for each of the first five years of service and 30 days' pay for each year thereafter. Both the day-counts and the basic-only base come from the framework set out in Federal Decree-Law No. 33 of 2021. An accrual you calculate on gross rather than basic will overstate the liability, and the error compounds with every allowance an employee receives.

This is why the basic figure has to be isolated at extraction time. To reconstruct a gratuity base from UAE payslips, or to run an accrual schedule across a workforce, you need each employee's basic salary for each period sitting in its own column. If the extraction kept that column from the start, the accrual is a straightforward calculation over the dataset. If it did not, you are back to opening individual slips by hand, which is the work you were trying to avoid.

The principle is not unique to the Emirates. Any payroll where entitlements or statutory deductions key off specific pay components rewards the same column-per-component discipline. The approach that lets you extract South African payslips with PAYE, UIF and SDL as separate columns is the same instinct applied to a different rulebook, and you can follow the same column-per-deduction approach for Irish payslips with PAYE, USC, and PRSI. UAE payroll simply makes the cost of getting it wrong unusually visible, because the entitlement that depends on the split is one of the largest the employer carries.

The Extraction Prompt and Target Column Schema

With the structure understood, the extraction itself comes down to two things: the columns you want and the instruction that produces them. Start from the schema, because it tells you what to ask for.

A workable target schema for a UAE payslip looks like this, one row per employee per pay period:

• Employee Name
• Employee ID
• Pay Period
• Basic Salary
• Housing Allowance
• Transport Allowance
• Communication Allowance
• Other Allowances
• Gross Earnings
• Statutory Deductions (itemised: GPSSA or ADPF, ILOE)
• Total Deductions
• Net Pay
• Labour Card Number (where present)
• IBAN (where present)
• MOHRE Establishment Number (where present)
• Source File and Page

Every allowance has its own column, the statutory deductions are itemised rather than summed into one figure, and the WPS identifiers are captured so the rows can be matched against a Wage Protection System file later. The final source-reference column means each row points back to the exact slip and page it came from, which is what makes the dataset auditable.

The instruction that produces this is most reliable when you describe the job rather than just listing fields. A goal-oriented prompt gives the extraction the context to handle the variation real payslips contain:

I'm preparing payroll data for our monthly pay run across a batch of UAE payslips. Extract one row per employee per pay period. Capture Employee Name, Employee ID, and Pay Period. Put Basic Salary in its own column, and create a separate column for each allowance: Housing, Transport, Communication, and Other Allowances. Itemise each statutory deduction (GPSSA, ADPF, or ILOE) in its own column, then Total Deductions and Net Pay. Where the slip shows them, also capture Labour Card Number, IBAN, and MOHRE Establishment Number. Format the pay period and any dates as YYYY-MM-DD and all amounts to two decimal places.

Describing the downstream purpose, preparing data for a pay run, is what lets the extraction deal with the cases a rigid field list would miss: a slip that labels its housing line differently, an employee with an extra deduction, a period where one allowance is absent. The instruction adapts to the document instead of breaking on it.

Output format follows the use. Excel is the natural choice when you are going to pivot, filter, and build accrual calculations over the data. You can convert UAE salary slips to CSV when the destination is an import into accounting or HR software that expects a flat file, and JSON when the data feeds a script or an integration. The schema stays the same across all three; only the container changes.

This is the prompt-driven approach in practice. Invoice Data Extraction works as a single prompt field over a file upload area, the same interaction pattern as a modern AI chat tool. You describe the UAE schema in plain language, as above, and receive back one row per employee per period with the allowance columns broken out and dates and amounts formatted as instructed. There are no templates to configure or rules engines to wire up; the prompt is the configuration, and a saved prompt reproduces the same column layout on next month's batch. If you want the broader pattern this fits into, the UAE schema here is a regional specialisation of the general payroll data extraction workflow that applies across countries.

Mapping WPS and SIF Fields for Reconciliation and Audit

Payslips rarely travel alone. Private-sector salaries in the UAE are paid through the Wage Protection System, monitored by the Ministry of Human Resources and Emiratisation (MOHRE), and the structured file behind every WPS transfer is the Salary Information File. For anyone doing reconciliation or audit work, the SIF is as much an extraction target as the payslips themselves.

The SIF is a pipe-delimited or fixed-width text file with a defined shape: a Salary Control Record that summarises the batch, followed by one Employee Detail Record per worker. Each detail record carries the fields you would expect to reconcile against a slip, including the MOHRE establishment number, the employee's Labour Card number, the worker UID, basic salary, allowances, deductions, net pay, the currency (AED), and the IBAN the salary was paid into. Extracting that file into Excel turns a machine-format payroll record into something a person can read row by row.

The reconciliation use case is where this pays off. Pull both sides into the same workbook, the payslips and the SIF export, and you can match employee by employee that what the slip shows equals what was actually paid through WPS. Discrepancies surface immediately: a net figure that does not tie out, an allowance present on the slip but missing from the file, an IBAN that does not match. The result is an audit trail you can hand to a reviewer rather than a stack of documents to cross-check by hand.

It is worth being clear about scope. The job here is extracting WPS and SIF salary data to Excel for reconciliation and audit, reading files that already exist. Generating or submitting a SIF is a separate function that belongs to payroll software, and it is not what this workflow is for. The value is on the analysis side: taking the records you already have and making them comparable.

This is also where the identifier columns from the schema earn their place. Because the SIF and the payslip share keys, the Labour Card number, the IBAN, and the establishment number, capturing those columns during payslip extraction is exactly what lets you join the two datasets. Without them, you are matching on names, which is slow and error-prone across a workforce. With them, the cross-match is a lookup.

Handling Nationals and Expats as Two Deduction Profiles

A UAE workforce usually holds two kinds of payslip at once, and a reliable extraction has to keep them straight. UAE and GCC nationals carry statutory pension deductions and do not accrue end-of-service gratuity. Expats are the mirror image: they generally have no statutory payroll deductions, but they do accrue gratuity. These are two distinct deduction profiles, and a row that treats them as interchangeable will misstate either the deduction or the entitlement.

For nationals, the deduction to look for is the GPSSA pension contribution, which shows on the slip as an employee deduction. The employee share is commonly in the region of 5% across most emirates, but treat that as a pointer, not a fixed input: Abu Dhabi nationals fall under a separate scheme administered through the Abu Dhabi Pension Fund (ADPF) with its own contribution rates. Rates and thresholds change, and they differ by emirate, so confirm the current figures against the relevant pension authority before you rely on them in an accrual or a reconciliation. The extraction's job is to capture what the slip states; the rate validation is yours.

There is also ILOE to account for. The Involuntary Loss of Employment insurance scheme has been mandatory since 2023, and its premium can appear as a deduction line on either profile. Where it is present, capture it in its own column rather than bundling it into a general deductions figure.

This is why the schema needs a deduction-profile flag. A single column marking each row as national or expat, paired with dedicated columns for GPSSA or ADPF and for ILOE, keeps the dataset analysable. The alternative, forcing two different deduction logics through one ambiguous "deductions" column, makes it impossible to filter or total the two populations separately, which is precisely what a payroll reconciliation or a headcount cost analysis needs to do.

The profile flag also governs the gratuity side. Because nationals do not accrue gratuity while expats do, the basic-salary column feeds a gratuity-accrual calculation only for the expat rows. Without a flag distinguishing the two, an accrual run across the whole dataset would wrongly attribute a liability to national employees who never earn it. The split you preserved at extraction time is what lets the calculation apply to the right people.

Bilingual and Scanned Slips Where Simple Converters Fail

The clean, native PDF is the easy case. Real batches are messier, and the mess is usually where a straightforward PDF-to-Excel converter stops being useful.

The first complication is language. A large share of UAE payslips label their fields in both Arabic and English, often with the Arabic running right-to-left beside the Latin script. A converter built for a single language and a single reading direction tends to mishandle this, jumbling the column order, pairing the wrong label with a value, or dropping the Arabic entirely. The information is all on the page; the tool just cannot reconcile two scripts and two directions in one layout.

The second complication is image quality. Plenty of slips arrive as scanned images, photographs taken on a phone, or low-resolution PDFs with no underlying text layer at all. A structure-blind converter that expects selectable text has nothing to work with and returns garbled output or empty cells. This is the UAE payslip OCR scenario where the simple tools fall short, and it is common precisely because payslips are so often forwarded as photos or filed as scans.

What handles both cases is an extraction that interprets the document by its content and context rather than depending on a clean text layer. Reading a slip the way a person does, recognising that a figure beside a housing label is a housing allowance regardless of the script it is written in or whether it arrived as a crisp PDF or a phone photo, is what lets bilingual and low-quality inputs map into the right columns. Handling Arabic and right-to-left text alongside other scripts, and reading from scans and mobile-phone images rather than requiring a text layer, is exactly the kind of capability this depends on.

The reassurance for the practitioner is that none of this changes the target. The same column schema applies whether a slip is a bilingual scan or a native English PDF; a messy input still resolves to one clean row per employee per period. When you are choosing how to process a batch, it is worth weighing tools specifically on this, since it is where capabilities diverge most. If you are evaluating options, it helps to compare payroll OCR software for finance teams on how they handle bilingual layouts and low-quality scans rather than on the clean-PDF demo.

From Spreadsheet to Pay Run: Output Shape and Running at Scale

The finished output is a single table you can work in directly. One row per employee per pay period; basic and each allowance in their own columns; statutory deductions itemised; a flag marking each row national or expat; WPS identifiers mapped where the slip carried them; and a source reference on every row pointing back to the original document. That is a dataset you can pivot for cost reporting, filter for a gratuity-accrual run on the expat rows, or reconcile line by line against a SIF export, and it is structured well enough to import into accounting or HR software without rework.

The shape matters most when you move from one slip to a batch. A bulk UAE payslip to spreadsheet run is only useful if every slip produces the same columns in the same order; otherwise you have a pile of one-off conversions that will not stack into a single table. Applying the same prompt and the same schema across the whole batch is what gives you consistent columns on every row, which is the property that makes analysis possible at all.

This is where running the extraction as a single, repeatable operation earns its keep. The same prompt that structured one payslip runs unchanged across a full batch, so you can extract structured data from any payslip into Excel at the scale your workload actually demands. The platform handles large, mixed-format batches of up to 6,000 files in a single job, including multi-page PDFs, and produces consistent structured output across every document, so a hundred slips or a thousand resolve into the same clean table without you rewriting the instruction each time. Saving the prompt means next month's pay run starts from the same schema rather than from scratch.

The payroll dataset also rarely sits on its own. The same finance team reconciling salaries is often handling VAT and supplier records in parallel, and the same prompt-driven approach lets you build a UAE VAT purchase register from invoices, so the payroll extraction fits into a broader UAE compliance and accounting workflow rather than standing apart from it.

The payoff is a clean, analysis-ready dataset that holds up to gratuity and WPS scrutiny, built from the documents you already had, with no retyping and the basic-versus-allowance structure intact from the first column to the last.