Payroll · Zimbabwe
Zimbabwe payroll runs off two separate ZIMRA tax tables, one for USD earnings and one for ZiG. Where a salary mixes both, ZIMRA requires the USD tables. PAYE is worked out before tax credits, the 3 per cent AIDS levy is applied after them, and the total is remitted by the 10th of the following month in the currency earned.
Last updated 2026-09-04. Published by Umbra ERP.
Zimbabwe does not have one payroll with a conversion step bolted on. It has two parallel PAYE calculations that happen to sit inside the same monthly run. ZIMRA publishes a USD tax table and a local-currency tax table for each tax year, and the table you apply is decided by the currency the employee was actually paid in. Not the currency the business reports in, not the currency of the contract, and not whatever rate the sales side of the business used that week.
That distinction catches people out because it inverts the habit most accountants bring with them. Elsewhere you convert everything into one presentation currency and then apply one rule. Here you apply the rule that matches the money that left the account. An employee paid in United States dollars is taxed off the USD table. An employee paid in local currency is taxed off the ZiG table. Two people doing identical jobs on economically comparable packages can sit in different tax tables in the same month, and both treatments are correct.
The tables themselves move more often than the rules do, which is the argument against ever typing a bracket into a formula. ZIMRA maintains a set per year and per currency, and 2024 is the clearest illustration of why dated data matters: the local-currency set for that year includes both a ZWL table and a ZiG table running from 5 April 2024, because the currency changed in the middle of the year. The 2025 set is listed as USD and ZWG. The spelling drifts between ZiG in ZIMRA guidance and ZWG in the table listings and in bank systems, but it is the same currency and the same table.
So the first design question for a Zimbabwean payroll is not which software has the nicest payslip. It is whether the brackets are stored as data, per currency, per year, with an effective date attached, so that a mid-year currency change or a mid-year revision applies from the day it takes effect rather than being smeared across twelve months. Anything that stores a rate as a constant will be quietly wrong from the moment that rate changes, and quietly wrong is the expensive kind.
The most useful single sentence in ZIMRA guidance on PAYE is the one about split packages: for salaries with both local and USD currency components, use the USD tax tables.
This matters because split packages are ordinary here, not exotic. A company that bills some customers in USD and some in local currency very often pays a base in one currency and an allowance, a commission or a monthly top-up in the other. The moment an employee has any foreign-currency component in their pay, the whole calculation moves onto the USD tables. You do not run two miniature payrolls for one person and add the answers together, and you do not tax the ZiG portion off the ZiG table while taxing the USD portion off the USD table.
In practice the local-currency element has to be brought to USD for the purposes of the calculation, using the rate applying on the day of payment, with tax then falling out of the USD table on the combined figure. Getting this backwards is one of the more expensive payroll errors available in this market, because it does not fail loudly. It usually understates PAYE for every affected employee for every month it goes unnoticed, and then arrives as one arrears number with interest attached to it.
There is a software design consequence here that is easy to miss when you are comparing feature lists. If a payroll tool treats currency as an attribute of the employee, and quietly runs each employee against whichever table matches their own currency, it will handle single-currency staff perfectly and get every split package wrong. The rule attaches to the salary, and the trigger is the presence of a foreign-currency component, not the employee record. When you evaluate a system, test that case specifically with real numbers before you migrate a workforce onto it.
ZIMRA describes PAYE as an ordered sequence rather than a formula, and the order is not decorative. Two of the steps, tax credits and the AIDS levy, interact in a way that changes the answer if you swap them.
For the day, week, month or year, depending on the pay period the employee is on.
Exempt amounts come out first, for example bonus up to the limit set in the Act. What remains is Income.
Pension contributions and subscriptions to professional associations are the common ones. What remains is Taxable Income.
Run taxable income through the ZiG or USD table for that period and year. This produces PAYE due before the AIDS levy.
Medical expenses, the blind person's credit, the mentally or physically disabled person's credit and the elderly person's credit are applied here.
The levy is applied to PAYE once the credits have already reduced it. The result is the total tax to be remitted to ZIMRA.
The sequencing point is step five before step six. The AIDS levy is 3 per cent of PAYE after credits, so a system that applies the levy to gross PAYE and then subtracts credits will overstate the liability for every employee who carries a credit. On one payslip the difference is trivial. Across a workforce and a full year it is not, and it is precisely the class of error that survives review, because the total still looks plausible and nobody re-derives it by hand.
It is also worth noting what the sequence does not contain. ZIMDEF and the Workers Compensation Insurance Fund do not appear anywhere in it. They are separate statutory obligations, with their own bases, their own returns and their own recipients, and they are not deductions inside the PAYE computation. Allowable deductions are only what the Act allows, principally pension contributions and professional subscriptions. Everything else stays outside.
Tax credits are the part of the calculation most likely to be quietly wrong, because they depend on facts about a person that the payroll only knows if somebody tells it. ZIMRA lists the mentally or physically disabled person's credit, the elderly person's credit, the blind person's credit, and a credit for medical expenses.
The published amount is US$900.00 for income earned in foreign currency, effective 1 January 2024, with ZiG income taking the equivalent at the exchange rate prevailing on the day of payment. That second half is the operationally awkward one. The credit for a locally paid employee is not a fixed local number you configure once and forget. It is a USD amount converted at a date-specific rate, so it moves as the rate moves and it has to be recomputed each period rather than carried forward from last month because last month balanced.
On the deductions side, ZIMRA names pension contributions and subscriptions to professional associations. Both are routinely under-applied, because both usually live somewhere other than payroll. An engineer, an accountant or a lawyer paying an annual practising fee has an allowable deduction that will never reach the payroll officer unless there is a process that makes the employee submit the receipt. That is an administrative failure with a cash cost attached, borne by the employee, and it reflects on the employer.
Build the evidence trail at the point the claim is made rather than at year end. A credit claimed without a supporting document behind it is a liability sitting with the employer, because PAYE is the employer obligation to compute and remit correctly. The employee having been honest is not a defence, and reconstructing eleven months of medical receipts in December is not a plan.
PAYE and the AIDS levy are only part of what a Zimbabwean pay run has to produce. Alongside them sit NSSA contributions under the Pension and Other Benefits Scheme, the Workers Compensation Insurance Fund, and ZIMDEF, the manpower development levy. Each has its own base, its own return and its own destination, and none of them is ZIMRA.
Two features of NSSA make it easy to automate badly. The first is the insurable earnings ceiling: contributions are computed on earnings up to a cap, so an employee above that cap contributes on the cap rather than on the full salary, and every dollar of increase above it changes nothing in the contribution. Payroll that applies a flat percentage to gross will overstate the deduction for exactly the senior people most likely to notice.
The second is that the ceiling is revised. It is set by statutory instrument and it has moved more than once as the currency has moved. Any system holding it as a constant in code rather than as a dated configuration value will be wrong from the day it changes, and will stay wrong until somebody happens to check.
For that reason this article deliberately does not quote a NSSA contribution rate, a ceiling figure or a ZIMDEF percentage. Take them from NSSA and ZIMDEF directly, note the date you took them, and revisit them after every budget statement and every statutory instrument that touches them. The common failure with these numbers is not that people cannot find them. It is that they find them once, hard-code them, and never look again.
What a payroll system should give you is the shape rather than a frozen answer: a ceiling that can be dated, a rate that can be dated, the employer portion recorded separately from the employee portion so the true cost of employment is visible, and a per-run schedule you can reconcile against what you actually paid over. Umbra calculates PAYE, NSSA, WCIF, ZIMDEF and the 3 per cent AIDS levy in the same Zimbabwe pay run, and emails payslip PDFs when the run is approved.
PAYE is due on or before the 10th of the following month. Payment is made through a bank, into the ZIMRA Single Bank Account, in the currency in which the income was earned.
The currency clause is the one to internalise, because it quietly dictates the shape of your month-end. It is not sufficient to compute USD PAYE correctly and then settle it in local currency at a rate of your choosing. If the employee earned in USD, the remittance is in USD. If the employee earned in ZiG, the remittance is in ZiG. A business with a split workforce is therefore making more than one payment every month, in more than one currency, into the same ZIMRA account.
The 10th is a date, not a working-day convention. A month in which the 10th falls on a weekend or a public holiday compresses the schedule rather than extending it, and bank cut-off times do the rest. Work backwards: the run has to be calculated, approved, funded and paid over with banking days in hand, which for most businesses means the pay run itself needs to close in the first week of the month rather than the second.
Keep the proof against the period. A bank confirmation that names the ZIMRA account, the amount, the currency and the month is the document that closes payroll for that month. A payroll report on its own is a calculation, not evidence of payment, and the two get separated with remarkable speed once a year has passed.
Two documents close the Zimbabwean payroll year. The P9 is the employee tax deduction certificate, the per-person statement of what was earned and what was deducted. The ITF16 is the employer annual return, the consolidated schedule across the whole workforce.
Both are assembled from twelve months of pay runs, which makes them a fair test of whether payroll was kept honestly during the year. If monthly runs were adjusted by hand, if a bonus was processed outside the system, if a top-up was paid through the general ledger because it was quicker that way, the year-end forms will not tie back to the remittances. December then becomes an exercise in reconstructing March, usually without the person who did March.
The specific trap for a split-currency workforce is that the year-end position has to be presented consistently with the tables actually applied during the year. An employee who moved from local-currency pay to USD pay mid-year, or who acquired a USD allowance and therefore moved onto the USD tables under the mixed-currency rule, has a year with two shapes in it. That is a records problem before it is a tax problem. You need to be able to show which table applied in which month, and why it changed.
Umbra produces both the P9 and the ITF16 from approved pay runs rather than from a re-keyed summary, and a Zimbabwe RTGS bank file can be exported as CSV for an approved run, so the payment instruction and the payslips come from the same underlying record instead of from two spreadsheets that agreed on the day they were made.
Here is a constraint worth knowing before you choose any Zimbabwean payroll system, this one included. Umbra uses one payroll currency per business per pay run. It does not pay some staff in USD and others in ZWG inside a single run.
That is a genuine limitation and it is better stated here than discovered in week one. The workaround businesses use is structural rather than clever: run the USD-paid population and the local-currency-paid population as separate pay runs, keep each run wholly in its own currency, and remit each in the currency it was earned in, which is what ZIMRA requires anyway. Because one Umbra login can carry up to 25 businesses, including parent and subsidiary structures, groups that genuinely operate more than one entity can keep those separated cleanly at the same time.
What the workaround does not solve is the individual with a genuinely split package, the person on a local-currency base with a USD allowance. That case belongs in a single calculation on the USD tables with the local element converted at the rate applying on the day of payment. Whatever system you use, put that exact scenario through it during evaluation and check the answer by hand once.
The same scepticism should be applied to any multi-currency claim in this market: ask what happens at the boundary. Umbra never sums amounts across currencies anywhere in the product, and its exchange rates are fetched from an official rate API first and Stanbic Bank second, with parallel-market quotes refused outright and no midpoint ever computed. That is also a deliberate constraint rather than a gap. A payroll figure derived from an unofficial rate is not defensible in front of ZIMRA, whatever it does for morale on payday.
The Zimbabwean payrolls that do not generate arrears assessments tend to share the same handful of properties, none of which are sophisticated and none of which require a large finance team.
Software does not make a business compliant. It makes the calculation repeatable and the evidence retrievable, which turns out to be most of what compliance is in daily practice. The filing obligation, the accuracy of what is claimed and the timeliness of the remittance stay with the business, and no vendor can take those on for you.
PAYE is remitted on or before the 10th of the month following the month in which the income was paid. Payment is made through banks into the ZIMRA Single Bank Account, in the currency in which the income was earned. The 10th is a calendar date, so weekends and public holidays shorten the window rather than extending it.
The USD tables. ZIMRA states that for salaries with both local and USD currency components you use the USD tax tables. You do not tax each component separately against its own table. The local-currency element is brought to USD using the rate applying on the day of payment, and the tax is calculated on the combined figure.
The AIDS levy is 3 per cent and it is applied to PAYE after tax credits have been deducted, not before. Applying it to gross PAYE and then subtracting credits overstates the liability for every employee who carries a credit, which is a common and hard-to-spot payroll error.
No. ZIMRA requires payment in the currency in which the income was earned. A business paying part of its workforce in USD and part in ZiG therefore makes more than one remittance each month, one per earning currency, into the same ZIMRA Single Bank Account, all by the 10th.
ZIMRA publishes the credits at US$900.00 for income earned in foreign currency, effective 1 January 2024. For income earned in ZiG, the credit is the equivalent amount at the exchange rate prevailing on the day of payment, so it is recomputed each period rather than fixed as a local-currency constant.
The P9 is the employee tax deduction certificate, issued per employee, showing what that person earned and what was deducted over the year. The ITF16 is the employer annual return, consolidating the same information across the whole workforce. Both are built from the twelve monthly pay runs, so they only reconcile if those runs were kept clean.
Umbra uses one payroll currency per business per pay run, so it cannot pay some staff in USD and others in ZWG within a single run. The practical approach is separate runs per currency, which also matches the ZIMRA requirement to remit in the currency earned. Umbra calculates PAYE, NSSA, WCIF, ZIMDEF and the 3 per cent AIDS levy, and produces the P9 and ITF16.
ZIMRA publishes them on its tax tables page, with a separate set per currency and per tax year. The 2024 local-currency set includes both a ZWL table and a ZiG table running from 5 April 2024, because the currency changed mid-year, which is why tax bands should be stored as dated data rather than hard-coded.
Regulatory figures on this page are taken from the following primary sources. Tax rates and thresholds change; check the source before relying on a figure.