Acumatica Zimbabwe QR Code Receipt — A Complete Guide

Zimbabwe's fiscalisation regime, administered by ZIMRA, requires fiscalised electronic invoices to carry a QR code that a customer or auditor can scan to independently verify the receipt against ZIMRA's records. It is the same trust model as most modern e-invoicing systems — the QR code encodes a verification URL plus a digital signature, and it exists so a receipt can be checked without trusting the merchant's own printout.

What the QR code actually encodes

ZIMRA's fiscal device (FDMS) specification defines the QR code as a compact encoding of the device's serial number, the receipt/invoice number, the total and tax amount, the date, and a verification hash or signature generated by the fiscal device at the time the receipt is fiscalised. It is not just a link to a website with the invoice number in the query string — the hash is what lets ZIMRA (or a customer using the verification app) confirm the receipt was actually issued by a registered fiscal device and hasn't been altered after the fact.

Generating the code from Acumatica

Acumatica does not generate the QR code itself — the fiscal device or the fiscalisation middleware does, as part of fiscalising the transaction. Your Acumatica-side integration submits the AR invoice or cash sale data to the fiscal device (or a cloud-based FDMS-compliant gateway) via its API, and the response includes the fiscal receipt number, the signature, and the QR payload. That payload then needs to be rendered onto the printed or PDF invoice — typically as a standard QR image generated client-side or server-side from the string ZIMRA's device returned, not invented locally.

[PXTable(IsOptional = true)]
public class ARInvoiceExt : PXCacheExtension<ARInvoice>
{
    [PXDBString(500)]
    [PXUIField(DisplayName = "Fiscal QR Payload")]
    public virtual string UsrFiscalQrPayload { get; set; }

    [PXDBString(30)]
    [PXUIField(DisplayName = "Fiscal Receipt Number")]
    public virtual string UsrFiscalReceiptNbr { get; set; }
}

Printing and report changes

Once the QR payload lands on the custom field, the invoice report (typically an SSRS or Acumatica Report Designer report) needs a barcode/QR rendering control bound to that field. Most teams use a standard QR-rendering report control rather than an external image service, since the payload must render correctly even for printed paper copies with no internet connection at print time.

What happens when fiscalisation fails

If the fiscal device is unreachable at the moment of invoicing, you need a defined fallback: either block invoice printing until fiscalisation succeeds (safest, but disruptive at the counter), or print with a placeholder and re-fiscalise + reprint once connectivity returns. ZIMRA's rules are strict about not issuing unfiscalised receipts for VAT-registered operators, so most implementations choose to block rather than queue silently.

Wrapping up

The Acumatica-side work is mostly plumbing — capture the fiscal device's response, store it, and get it onto the printed document faithfully. The compliance risk lives in treating the fiscal device as the sole authority for what the QR code says, and never trying to shortcut that with locally generated data. If you are stuck on something specific, reach out or keep reading through the rest of the Acumatica blog.