“Can the automation send the invoice?” is the question that decides whether a Zimbabwean back-office project is honest. The answer is: it can prepare the invoice, it can send the invoice, it can file the invoice, and it must not issue the fiscal tax invoice, because ZIMRA requires that step to happen on a fiscal device or software integrated with its Fiscalisation Data Management System. This guide draws the line precisely and shows the workflow on either side of it.
What FDMS is
ZIMRA describes the Fiscalisation Data Management System as an integrated back-end that interfaces with the fiscal devices installed at taxpayers’ points of sale, so that every fiscal tax invoice is recorded and transmitted. Registered operators under the VAT Act must record all sales through fiscal devices interfaced with FDMS; the invoices display a QR code and an authentication code that anyone can verify on the FDMS validation portal.
Since 1 January 2024, a trader must register for VAT once taxable supplies exceed or are expected to exceed USD 25,000 (or ZiG equivalent) in twelve months (ZIMRA). Below that you may still fiscalise voluntarily; above it, the rules below are not optional.
What changed in 2025
Three dates matter for anyone designing a workflow.
| Date | Change | Source |
|---|---|---|
| 31 May 2025 | Deadline for VAT-registered operators to upgrade fiscal devices so that buyer details are transmitted to FDMS on every fiscal tax invoice: buyer name, address, TIN, contact details and VAT number where applicable. | ZIMRA Public Notice 30/2025; RTC Suite |
| 1 June 2025 | TaRMS begins importing FDMS records to pre-fill VAT return drafts, input-tax schedules and credit/debit-note logs. | RTC Suite |
| 1 December 2025 | Cut-off for the TaRMS/FDMS integration on all valid fiscal tax invoices, debit notes received and credit notes issued. | ZIMRA Public Notice 63/2025 |
The practical consequences reported in the same sources: an invoice from an un-upgraded device is flagged INVALID, which denies the buyer its VAT deduction; mismatches between printed documents and FDMS records must be corrected before the fiscal day can close; and tax clearance certificates are issued only to taxpayers who comply with FDMS requirements.
For B2B customers this changes the sales conversation. A buyer that claims input VAT needs its TIN and VAT number on your fiscal invoice. If your sales team captures orders on WhatsApp without those fields, someone re-keys them at the fiscal device or the invoice comes out wrong.
The workflow, with the boundary drawn
Below is a typical quote-to-cash flow for a wholesaler or service business. The middle column says whether we automate it; the right column says what the automation does or why it stops.
| Step | Automated? | Notes |
|---|---|---|
| 1. Enquiry captured (WhatsApp, form, counter) | Yes | Name, +263 number, what, quantity, delivery area. For B2B: TIN and VAT number asked here, once, and stored on the customer record. |
| 2. Quote prepared | Yes | From the current price list; both USD and ZiG amounts with the rate source and date printed on the quote. |
| 3. Quote sent and chased | Yes | In the chat; follow-ups at 24h/72h/7d until the customer replies. |
| 4. Order confirmed | Yes, with approval | Credit terms or discounts beyond the rule go to a named approver. |
| 5. Payment received | Yes | EcoCash/Paynow/bank notification parsed and matched to the open quote; ambiguous references proposed to a person. |
| 6. Non-fiscal acknowledgement | Yes | A “payment received, invoice to follow” message. Clearly not a tax invoice. |
| 7. Fiscal tax invoice issued | No | Draft with buyer details is prepared and presented; the invoice is issued on the FDMS-integrated device or software, which generates the QR and authentication code. |
| 8. Fiscal invoice sent and filed | Yes | The issued document (PDF or photo, with its QR) is sent in the chat and filed against the customer and the order. |
| 9. Records updated | Yes | Sheet, accounting package and CRM marked paid/invoiced with the fiscal invoice number. |
| 10. Credit/debit notes | Prepared, not issued | Same boundary: the note is issued fiscally; the automation prepares, sends, files. |
The point of step 7 is not technical; some fiscal software exposes integrations, and where yours does, the boundary is drawn at its API, not at a person. The point is that the legal act of issuing a fiscal tax invoice happens inside the FDMS-integrated system, and we never simulate it with a PDF template.
The buyer-details problem, solved upstream
Since 31 May 2025 the fiscal invoice must carry the buyer’s details. The cheapest place to capture them is the first time a business customer buys, in the same chat that took the order:
For your tax invoice we need your registered name, address, TIN and VAT number (if registered). Reply with them once and we’ll keep them on file for future orders.
Stored on the customer record, they travel with every order to the fiscal step. The alternative, asking at the device every time, is where the re-keying and the INVALID invoices come from.
A worked example (illustrative)
A building-supplies wholesaler issues 20 invoices a day. Today the sequence is: read the EcoCash screenshot, find the quote, mark paid in the sheet, type the invoice in the accounting package, re-type buyer details at the fiscal device, print, photograph, WhatsApp the photo. Call it six manual touches at roughly two minutes each: about four hours a day.
After the workflow above, the manual touches are: confirm any ambiguous payment match, and issue the fiscal invoice from the prepared draft. Call it one to two touches at one minute: about 30 minutes a day. The assumption of two minutes per touch is ours; count yours for a week and replace it. The saving is time and, more importantly, the disappearance of the re-keying step that produces wrong buyer details.
Deadline workflows sit on the same rails
Once payment matching and invoice filing are automated, the numbers ZIMRA wants each quarter already exist in one place. ZIMRA’s quarterly payment dates for 2026 are 25 March, 25 June, 25 September and 20 December. A deadline workflow reminds the right people, gathers the figures and produces the checklist; your accountant still files. The professional services section describes it for firms that do this for clients.
What to check in your own setup
- Is the fiscal device upgraded and transmitting buyer details? (If invoices verify as VALID on the FDMS portal with buyer details showing, yes.)
- Does your accounting or fiscal software expose any integration, or is the device stand-alone?
- Where are B2B customers’ TINs and VAT numbers stored today?
- Which rate source do you use for ZiG amounts, and is it printed on quotes?
Bring the answers to scoping and the fiscal boundary is drawn in the first diagram, not discovered in the pilot.