Record what happened. Hold no opinion about the currency.

No. ZIMRA operates a fiscalisation regime and businesses within its scope transmit invoice data through approved devices or interfaces — we are not one of those and we do not connect to one. Our only fiscal e-invoicing integration anywhere is Kenya's eTIMS. What we hold is the operational record a return is built from, with net, tax and gross separated line by line and source documents attached to the transaction, which your accredited provider or practitioner works from. If transmission is a decision-blocker, tell us early and we will scope it as a build rather than imply it already exists.

Yes, and many Zimbabwean businesses should. The organization's base currency is a deliberate setup decision, and USD is a first-class choice rather than a workaround — everything is then stored, invoiced, printed and reported in dollars, with ZWG transactions recorded at the rate actually applied and that rate held on the record. The reverse arrangement works identically. What we will not do is decide it for you from a country field, because that choice governs every report you will read for the next several years.

Our configuration carried the pre-redenomination Zimbabwean currency code for considerably longer than it should have after the change. It now reads ZWG. We describe it rather than delete it because the general lesson matters more than the row: a vendor preset is a default you own, not maintained regulatory content, and ours proved that point at our own expense. Check every preset — currency, tax rate, rounding — on day one, and set your base currency consciously instead of accepting whatever a country selection implies.

Everything is reported in the organization's base currency, translated on the way out using the rate held on each transaction rather than a rate applied to a total after the fact. That distinction is the whole point: because the original currency, original amount and applied rate all survive on the record, any translation can be re-derived, explained or corrected later. There is also an optional organization-wide display currency for dashboards, but it is indicative only and never appears on an invoice, statement, receipt or export.

Not statutorily. Employee records, contracts, compensation, leave with balances, attendance and the allocation of payroll cost to projects and cost centres all work. The national computation — income tax bands, NSSA contributions, statutory return formats — is maintained for Kenya only. In Zimbabwe the workable arrangement is a local payroll specialist doing the calculation and filing while the employee and cost side lives here, and we would rather describe that plainly than sell a configurable tax table as compliance.

Operationally yes, with one caution about structure. Base currency is locked per organization, so a group with entities in two countries runs an organization per entity, with group reporting handled as management reporting rather than statutory consolidation. Two countries also mean two compliance regimes, two filing calendars and two sets of local specialists — the software does not collapse those, and any vendor implying otherwise has not checked recently.

When your requirement is chiefly statutory — fiscalised invoicing out of the box, local payroll, statutory accounts — and your operations are simple enough that stock, procurement and assets are not where the pain is. A good local package plus a payroll specialist then gives you one accountable vendor in your own timezone with support down the road. We reach that conclusion on first calls regularly and prefer to reach it in week one rather than month three.