Multi-currency · Africa
A figure that mixes two currencies is not a total, it is a category error. Keep the currency attached to each document, never add amounts across currencies, convert only at a dated rate from a source you can name, and remit each tax in the currency the underlying transaction actually used.
Last updated 2026-09-04. Published by Umbra ERP.
A ledger entry is a pair: an amount and a currency. The pair is atomic, and the moment it is split the arithmetic stops meaning anything. Most small businesses split it at the first opportunity, because a spreadsheet cell holds a number while the currency lives in a column heading, a cell format, a colour, or somebody's memory. Nothing in the tool objects, so the split is invisible until a decision is made on the output.
The failure is arithmetic, not judgement. A SUM over a column holding 400 (US dollars) and 3,000 (local currency) returns 3,400. That figure is not wrong by a percentage you could estimate and correct later. It has no correct value at all, because the operation that produced it was undefined. It then propagates: into a debtors report, into a cash position, into a decision about whether you can afford stock this month.
The second mechanism is converting too early. A business decides to hold everything in US dollars, converts each local-currency sale as it is captured, and stores only the converted figure. The ledger now holds a derived number and the original has been overwritten. When a customer disputes an amount, or an auditor asks which rate was applied, the source figure cannot be reproduced, because it was never kept. The conversion has become unfalsifiable.
The third mechanism is a single global rate setting. One field somewhere labelled "exchange rate", updated when somebody remembers, applied retrospectively to every document that has not been locked. Change it and last month's invoices silently restate. Reports that reconciled yesterday do not reconcile today, and nobody can say which figure was on the document when the customer received it.
The structural fix is to make currency a property of the individual document and refuse to average it away. In Umbra every quote, invoice, receipt, sales order and credit note carries its own currency, and Umbra never sums amounts across currencies. That is a deliberate refusal rather than a missing feature.
The consequence is that reports come back partitioned. Aged receivables give you a US dollar ageing and a local-currency ageing, side by side, each internally consistent. At first this reads as extra work, because you wanted one number. What you actually wanted was one number you could defend, and the partitioned view is the only version of it that exists. If you need a single headline figure for a board pack, you produce it deliberately, on a stated date, at a stated rate, and you show the basis alongside it.
Once currency lives on the document, conversion becomes an explicit event with three attributes rather than an ambient setting. It has a rate, a source, and the timestamp at which that source published the rate. Store all three next to the converted figure. A converted amount without those three attributes is an opinion, and it will be treated as one the first time it is challenged.
This also keeps documents stable over their lives. An invoice raised in local currency stays a local-currency invoice through part payment, credit note, statement and write-off. If a customer settles in a different currency, that is a reconciliation event you can see, price and record, rather than a discrepancy that was quietly absorbed into a rounding difference three reports downstream.
Accounting standards start from the entity, not the invoice. IAS 21 defines an entity's functional currency as "the currency of the primary economic environment in which the entity operates (ie the environment in which it primarily generates and expends cash)". That single choice determines what counts as foreign for you. A Harare trading company that prices, buys, banks and pays wages predominantly in US dollars is in a different position from one that genuinely operates in local currency and sells occasionally in dollars, even if their invoice books look identical.
Two moments then matter. The first is the date of the transaction, when the sale is recognised and translated into the functional currency. The second is the reporting date, when outstanding monetary balances such as receivables and payables are looked at again. The movement between those two moments is an exchange gain or loss. It is a real economic result of having held a foreign-currency claim for a period, not a bookkeeping error to be suppressed, and treating it as an error is how businesses end up with two sets of numbers that never agree.
The practical rule that follows is that a rate is a fact about a moment, not a configuration value. Pin it to the document at the moment the document is issued and store it there permanently. Do not re-derive it later from a live feed, because the feed has moved and the answer you get will not be the answer the customer was given.
Applying one rate for a whole month is a defensible policy in a stable currency and an expensive one in a volatile currency, and it is a policy either way. If you adopt it, write it down, state the day the rate is taken, and apply it consistently. An undocumented monthly rate is indistinguishable from a rate somebody chose after seeing the result they wanted.
In a market with a wide spread, the parallel rate is often the rate at which business is genuinely being done, and the temptation to use it in the books is obvious. The reason not to is mechanical rather than moral: a parallel rate has no publisher, no timestamp and no record you can produce. You cannot cite it, you cannot hand it to an auditor, and you cannot show that the figure you used on the 14th was the figure available on the 14th rather than the one that suited the result.
Umbra fetches rates automatically, from an official rate API first and Stanbic Bank second. Parallel-market quotes are refused outright. That is a hard behaviour of the system rather than a default that an administrator can quietly change, and it exists so that every converted figure in the ledger traces to a named institution that published it.
Umbra also never computes a midpoint between two sources. This looks like a needless restriction until you try to defend the resulting number. A midpoint is a rate that nobody published, and therefore a rate with no external record. One named source at a stated time can be produced as evidence. An average of two sources can only be reconstructed by rerunning your own code, which is not evidence, it is a claim about your own software.
The last guard is temporal. A rate that is already stale when it is fetched is rejected rather than stored, and publisher timestamps quoted in Central Africa Time are corrected to UTC before comparison. This matters more than it sounds. A rate published at 09:00 CAT, read by a system that assumes UTC, appears to have been published two hours in the future. Freshness checks then pass on rates that should have failed, and a stale rate that should have been refused gets written into a document that a customer is about to receive.
A useful reality check is that the revenue authority has usually resolved the currency question before your accounting system has. Its rules are written per currency, and they are specific.
On Zimbabwean employment taxes, ZIMRA requires PAYE to be remitted on or before the 10th of the following month, paid into the ZIMRA Single Bank Account in the currency in which the earnings were received. Employees paid in foreign currency are taxed using the USD tax tables and those paid in local currency using the ZiG tables, with the AIDS levy at 3 per cent. Where a salary is paid in a mixture of currencies, the USD tables apply. There is no version of that instruction that a single blended-currency payroll figure can satisfy.
On VAT, the standard rate is 15.5 per cent and registration becomes compulsory once taxable supplies exceed or are likely to reach US$25,000 or the ZiG equivalent within 12 months, a threshold effective from 1 January 2024. A fiscal tax invoice must be issued within 30 days of supply, and is not required where the amount is less than US$10.00. Input tax must be claimed within 12 months of the date of the invoice, and returns are due on or before the 25th day of the month following the tax period. The governing law is the Value Added Tax Act (Chapter 23:12).
Read together, those rules do the same thing your ledger should do: they keep the currency attached to the transaction all the way through to the payment of the tax. A system that blends currencies internally cannot produce a compliant remittance without somebody unpicking the blend by hand at month end, which is exactly the work the system was bought to remove.
Sales documents tolerate a mixed-currency portfolio well, because each one is independent. Payroll does not, because a pay run is a single object that produces a single set of statutory outputs: one remittance, one schedule, one set of employee certificates.
Umbra therefore uses one payroll currency per business per pay run. Paying some staff in US dollars and others in local currency inside a single run is not supported, and that constraint is worth stating plainly rather than hiding. It is not a gap waiting to be filled. A run that mixed currencies would have to produce a remittance figure that is a sum across currencies, which is the exact operation that has no meaning and which the authority does not accept.
Two separate things are often confused here. The first is an individual whose own salary is part foreign currency and part local currency. That is a tax table question, and ZIMRA answers it: the USD tables apply. The second is a workforce where different people are paid in different currencies. That is a structuring question, and the answer is more than one pay run, with each run producing its own remittance in its own currency.
Where the split is permanent rather than incidental, the cleaner structure is separate business records. One Umbra login can run up to 25 businesses, including parent and subsidiary structures, and each business holds its own currency and its own payroll configuration. You switch between them with a business header rather than logging out, so the operational cost of keeping them separate is low, while the reporting benefit is that neither set of books ever has to be unpicked from the other.
The report that suffers most from a mixed-currency ledger is aged receivables, because ageing is already a bucketed summary and a currency error inside a bucket is almost impossible to spot. Run it per currency. A customer who owes you 4,000 US dollars at 90 days and a modest local-currency balance at 30 days is a very different problem from the blended number, and only the partitioned view tells you which conversation to have.
Customer statements deserve the same treatment. A statement that lists documents in the currency each was raised in, and closes with a balance per currency, is one a customer can check line by line against their own records. A statement that presents a single converted balance invites a dispute about your rate rather than a payment, and that dispute costs more than the clarity was worth.
Recurring billing needs the currency to be part of the schedule, not applied at generation time. Umbra's recurring invoices and recurring quotes run weekly, fortnightly, monthly, quarterly, half-yearly or annually, pinned to a day of the month with month-end handling, and each generated document carries the schedule's currency. A twelve-month schedule therefore produces twelve documents in one currency rather than twelve documents that each inherited whatever the system rate happened to be that morning.
Collection rails carry their own currency constraints and it is better to design around them than discover them. Card and EcoCash pay links on Umbra invoices and quotes are enabled per account by an administrator and settle in US dollars, and the card rail does not carry ZWG. If part of your book is billed in local currency, that part needs a different settlement route, and knowing this before you promise a customer a pay link is worth more than any report. When a payment is recorded, by whatever route, a receipt is raised automatically; sending that receipt to the customer remains a separate and deliberate action.
None of this requires a large system. It requires a small number of rules that are never broken, and a tool that enforces them rather than relying on the person keying the document to remember.
The test of whether the discipline is working is simple. Pick any invoice from six months ago and ask what rate was used, where it came from, and when it was published. If the system answers in one click, your books will survive an audit, a customer dispute and a currency reform. If the answer requires somebody to reconstruct it, the number on that invoice is already an opinion, and the only question left is when it gets challenged.
You should not. An invoice is a demand for a specific amount in a specific currency, and a document carrying two currencies has no single payable total. Raise two invoices instead, one per currency, each with its own total. In Umbra every quote, invoice, receipt and credit note carries exactly one currency, and amounts are never summed across currencies.
The rate published by a named institution on the date the document is issued, stored on the document along with its source and publication time. Do not use a rate you re-derive later from a live feed, because the feed will have moved and you will no longer be able to reproduce the figure the customer received.
Not in the ledger. A parallel rate has no publisher, no timestamp and no record you can produce to an auditor or a revenue authority, so any figure derived from it is undefendable. Umbra refuses parallel-market quotes outright and takes rates from an official rate API first and Stanbic Bank second.
Show the balance per currency and, if a single figure is genuinely needed, add a converted total that states the rate, the source and the date it was published. A statement that presents only a blended figure invites an argument about your exchange rate rather than a payment.
Not in one run. Umbra uses one payroll currency per business per pay run, because a run produces a single statutory remittance and that remittance cannot be a sum across currencies. Split it into separate runs, or hold the two groups as separate businesses, each with its own payroll configuration.
ZIMRA applies the USD tax tables where an employee is paid in a mixture of currencies. Employees paid wholly in foreign currency also use the USD tables, and those paid in local currency use the ZiG tables. The AIDS levy is charged at 3 per cent.
In the currency in which the earnings were received, paid into the ZIMRA Single Bank Account on or before the 10th of the following month. That rule is one of the clearest reasons to keep the currency attached to each payroll transaction rather than blending it into a single reporting currency.
It should not, and in Umbra it does not, because the rate is recorded on the document rather than read from a global setting at report time. A system where updating one rate field silently restates last month means no historical report can be reproduced, which is a serious problem well before an auditor arrives.
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.