Zimbabwe VAT is administered by ZIMRA and, since the FDMS (Fiscal Device Management System) rollout, standard-rated VAT invoices generally need to be fiscalised in real time through a registered fiscal device before or as they're issued. That changes the shape of the Acumatica VAT-return project: it is not just tax-engine configuration, it is a real-time integration that has to work reliably at the point of sale or invoicing.
Tax engine configuration
Standard configuration mirrors most VAT jurisdictions: separate Tax Categories (TX205500) for standard-rated, zero-rated exports, and exempt supplies, each mapped to their own GL output/input tax accounts through Tax Zones (TX206000). Zimbabwe also has periods of USD and ZWL dual-currency operation depending on the prevailing monetary policy, which means your tax GL accounts and reporting currency configuration need to be verified against current regulations rather than assumed from a prior project — this is one area where "how it worked last year" can be wrong.
FDMS fiscalisation integration
Each qualifying sales invoice needs to be submitted to a registered fiscal device (or an FDMS-compliant virtual fiscal device/gateway) before it is considered fiscally valid. In practice this means an outbound call from Acumatica at invoice-release time, waiting for the device's fiscalisation response (receipt number, signature, QR payload), and writing that response back onto the invoice record before it can be printed as a valid fiscal tax invoice.
If fiscalisation happens asynchronously after release, you risk printing or emailing an invoice to a customer that later fails fiscalisation — leaving you with a document in the customer's hands that ZIMRA doesn't recognise. Gate invoice printing on a successful fiscal response, and hold anything that fails in a retry queue rather than letting it through unfiscalised.
public class ARInvoiceEntry_Extension : PXGraphExtension<ARInvoiceEntry>
{
[PXOverride]
public void Persist(Action baseMethod)
{
baseMethod();
ARInvoice doc = Base.Document.Current;
if (doc != null && doc.Released == true && doc.UsrFiscalReceiptNbr == null)
{
FiscalGatewayClient.Fiscalize(doc);
}
}
}The monthly return
The VAT return itself (VAT 7) is filed monthly through ZIMRA's e-services portal, summarising output tax and input tax by category for the period. Build the return from the tax transaction tables rather than a manually maintained spreadsheet, and reconcile the total against GL tax account balances before filing — the same discipline that matters in every VAT jurisdiction, but doubly important here because the FDMS integration adds another system whose numbers need to agree with Acumatica's.
Wrapping up
The tax configuration is the easy half of this project. The real engineering is a fiscalisation integration that fails safely, retries sensibly, and never lets an invoice reach a customer before ZIMRA has fiscally acknowledged it. If you are stuck on something specific, reach out or keep reading through the rest of the Acumatica blog.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.