Where QuickBooks sits in a fiscalisation setup
QuickBooks raises the invoice. ZIMRA's Fiscalisation Data Management System has to receive it. ZIMRA describes fiscalisation as configuring fiscal devices to record and transmit sales and other tax information at the time of sale to its servers, for use in VAT administration, and lists direct interface of a taxpayer's accounting or point of sale system to the ZIMRA server among the virtual fiscalisation options. Nothing inside QuickBooks does that on its own, so something has to sit between the two: read the invoice, put it into the shape FDMS expects, submit it, and bring the fiscal reference back for the customer's document.
Africube's integration is built to the ZIMRA FDMS specification. It is not approved, certified or endorsed by ZIMRA, and no supplier can hand you compliance; the obligation stays with the taxpayer.
Who has to fiscalise
On its fiscalisation explanation, ZIMRA states that all VAT registered operators should fiscalise as outlined in SI 104 of 2010 and must comply with the requirements of the Fiscalisation Data Management System. It also states that all taxpayers are required to fiscalise in terms of Section 90 of the Income Tax Act [CAP 23:06] as read with Section 80D and Section 80DD, and that the obligation applies to taxpayers with an annual turnover below the VAT registration threshold of USD 25,000.00.
ZIMRA's page on offences and penalties in fiscalisation states that a person who fails to fiscalise in terms of section 3 is liable for a civil penalty of US$25.00 per point of sale for each day the taxpayer remains in default, up to one hundred and eighty-one days, and that continued default after 181 days is an offence carrying a fine not exceeding level seven, or imprisonment for up to 12 months, or both. That page also covers offences involving unapproved fiscal devices, and cites SI 104 of 2010 as read with SI 148 of 2016 and SI 153 of 2016.
Virtual fiscalisation or a physical device
ZIMRA lists four broad categories of fiscal device on the market: fiscalised electronic registers, also called cash registers or electronic tax registers; fiscalised printers; electronic signature devices; and virtual fiscal devices. A fiscalised device holds a fiscal memory, which ZIMRA defines as a special read only memory permanently built into it to store tax information at the time of the sale. VAT registered operators and taxpayers not registered for VAT may choose whichever devices they prefer, based on the nature of the business and their capacity to implement the option chosen.
The virtual route touches your accounting system. ZIMRA describes use of APIs as virtual fiscalisation as suitable for medium to large taxpayers, especially those processing transactions on connected servers, accounting systems or point of sale systems, and says small traders can also use it through mobile point of sale. Eligibility depends on taxpayer needs and the ability to develop APIs for interfacing with FDMS. ZIMRA makes that API available from its website free of charge, with the fiscalisation API documentation published as a download.
ZIMRA says hardware fiscal devices should be acquired from approved suppliers, who assist in identifying appropriate devices, install them and provide training. Incentives attach: registered operators can claim 50% of the cost of acquiring fiscal electronic registers as input tax on the VAT 7 return, with the remaining 50% spread over two years and claimed as SIA on the income tax return (ITF 12C).
Desktop and Online are two different jobs
QuickBooks Desktop keeps your accounting in a company file on an office server, a workstation, or a Windows desktop rented from a hosting provider. Reading it means running software on Windows beside QuickBooks itself, with the Desktop SDK exchanging qbXML locally, and where that machine has no route out the Web Connector bridges the gap by polling outward. So the machine stays on while invoices are raised, an administrator has to be available during setup, and a hosting provider has to permit an application alongside QuickBooks. Ask in writing early.
QuickBooks Online has no file to reach. An administrator on your side grants access through QuickBooks' own consent screen, the authorisation is tied to one company, and invoices are read through the QuickBooks Online API under the accounting scope. No server has to be kept awake, removing the most fragile part of a Desktop setup. What you have instead is a live permission: revocable, refreshed on a schedule, and belonging to whoever granted it. If that person leaves, it is a handover item.
The two products also do not structure documents identically, and Zimbabwean businesses often keep customer tax details in a custom field or a memo line. Where those sit we establish from your invoices.
Read-only, and what that means
For fiscalisation, Africube's access to your accounting data is read-only. We read, never write. Your books stay untouched: nothing here edits a transaction, closes a period or moves a balance.
That is a decision about configuration and scope. On QuickBooks Online the accounting scope covers more than reading, so the restriction lives in what we configure and what is agreed in writing, and the same applies to a Desktop company file. Ask any supplier to put it in the scope document; said on a call, it is not a commitment.
One limit is worth naming early. Putting the fiscal reference inside QuickBooks against the original transaction means writing back, a different scope. Under read-only it lives in the fiscalisation layer and on the document you issue.
What your accounts team will see change
Invoices are still raised in QuickBooks, the same way, by the same people. Once one is recorded it is submitted, a fiscal reference comes back, and that reference appears on the document the customer receives. Submission follows the recording, so nobody waits on it.
Submissions can fail, through a dropped connection, a missing field or a rejected value, so there is a queue of failures and somebody has to own it. Name that person during implementation; an unwatched queue is how a business discovers in month three that it had a gap in month one. Where failures persist and the cause sits with the device or the transmission, your approved supplier or ZIMRA resolves it.
Customer details need more discipline: a tax number that used to get filled in later has to be right when the invoice is raised. Correcting by credit note matters more too, because editing a document after it has gone leaves your records and the transmission disagreeing.
What to have ready
An assessment moves faster with these to hand:
- Edition, version and hosting. For Desktop, the host and their confirmation that a connected application is permitted.
- Sample documents. Three or four invoices with confidential details removed, including a credit note, showing your field layout and where customer tax details sit.
- Where invoices are raised. Sites, users, and anything invoiced outside QuickBooks.
- Currencies and volume. What you invoice in, how the rate is recorded, and whether volume is steady or lumpy.
- Your existing fiscalisation position. Devices registered and what is connected.
- Two names. Who owns the accounting process, and who can approve system access.
Where the rules come from
The requirement is ZIMRA's. ZIMRA sets out what fiscalisation involves, who must fiscalise, the devices and the incentives in its fiscalisation explanation, publishes guidance on complying with FDMS, and sets out the offences and penalties for a failure to fiscalise. Changes appear in its public notices. Requirements change, so confirm your own position with ZIMRA or your tax adviser before acting on anything here. This is general information about connecting software. It is not tax or legal advice.
Read more about Africube's ZIMRA FDMS integration, start with the plain-English FDMS guide, or tell us what you are running.