Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
For Zimbabwe
Software that hardcodes a rate, a denomination or a conversion becomes the problem the day the assumption stops holding — and here, assumptions have stopped holding more than once inside one working life. Ours stores the transaction in the currency it happened in, at the rate that was actually applied, and derives everything else from that.
The whole design argument on this page reduces to the fields below. Nothing here is derived at report time, and nothing was converted on the way in.
Everything a report shows is computed from these fields on the way out. That is the difference between a system you can audit two years from now and one that quietly agreed with itself.
Three rules, and the whole design
A system that decides for you what a transaction was worth has thrown away the only thing you cannot rebuild. These three rules are what keep a Zimbabwean record auditable years later.
The transaction is held in the denomination it occurred in. Translation is a reporting decision, taken later, reversibly.
The rate actually applied lives on the record. A rate that exists only in a settings screen is a rate that will be wrong for some historic transaction.
Comparison, consolidation and margin are computed on the way out. Nothing downstream is allowed to become the only surviving copy of a fact.
What goes wrong
In each case a fact was thrown away at the moment it was still cheap to keep, and somebody was later paid professional rates to guess it back.
A fixed rate in a configuration file, a single denomination baked into a report, a conversion applied at print time. Each one is fine until the week it is not, and then it is unpickable.
Goods bought in dollars, some customers settling in dollars and some in ZWG, and a margin that depends entirely on which of them paid — recorded nowhere in a form anyone can query.
The transaction was stored already translated, so the original amount and the rate applied are gone. Nothing downstream can be rebuilt from it, and the auditor asking is not being difficult.
Three people, a week, and a stack of receipts, establishing what happened rather than reporting it. That is not accounting — it is archaeology at professional rates.
The operations layer
Each links to a fuller tour. The statutory half of your stack stays with local specialists — that boundary is drawn below, not left to be discovered.
One denomination for storing, invoicing, printing and reporting, chosen deliberately at setup. Businesses that price and settle in dollars set USD; that is a configuration choice, not a workaround.
The amount, the currency and the rate actually used are all held on the record. Reporting, comparison and consolidation are derived from that — never the other way round.
A dollar supplier stays a dollar supplier without anybody having to remember, and a customer's statement reads in the currency they actually trade in.
One stock position with movements that carry a reason, an approver and a variance — counted at the door on arrival rather than assumed from the dispatch note.
Requisitions, thresholds that block, RFQs, purchase orders, receiving and three-way matching that will not let an unmatched invoice through to payment.
Quotes, approvals, delivery notes, receipts and photographs held on the record they belong to — so producing a file two years later is a search, not a cupboard.
Scope, stated plainly
The last line in the right-hand column is about us rather than about you. It stays on the page because it is the best argument we have for the principle this page is built on.
Running in the product today
Not built for Zimbabwe — stated plainly, buildable on request
The preset line above is left in deliberately rather than deleted now that it is fixed. It is the strongest available argument for the principle this whole page is built on: a vendor default is a starting value you own, and the correct response to any of them — ours included — is to set it consciously at setup rather than accept what a country field implies.
How this starts
USD or ZWG, decided by what you actually price and settle in, on day one. Do not accept any vendor default, ours included — this is the decision every future report depends on.
Watch what gets stored on each record: the currency, the amount as invoiced, the rate applied. Then read the margin back out and check it against what you know happened.
Your approved device, interface or provider, and what they receive from us. One page, agreed before go-live, with a named owner on each side of the line.
Read before you shortlist
Three countries vendors treat as one bloc, and the three things that actually separate them: how the currency behaves, how far the revenue authority has gone with electronic invoicing, and how many people near you can implement what you sign.
Three currencies in one region behaving three different ways. Why the right software design is the one with no opinion about monetary policy, and the four habits that make margin visible instead of estimated.
Grants awarded in dollars, spent in kwacha, reported in a template nobody else uses, and audited two years later by someone who was not there. The reconstruction test, the advance regime that survives it, and an honest line on mobile money.
Questions we are asked in Harare
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.
A purchase in one currency, a sale in another, and the margin somebody had to work out by hand. We will show you exactly what the record would have held.