On the devices we support, a fiscal day is the window sales are recorded against: opened when trading starts, closed when it ends. Most of the FDMS calls that reach us arrive first thing in the morning, from a branch whose till will not invoice because the previous day never finished closing.
What fiscalisation requires
ZIMRA describes fiscalisation as configuring fiscal devices to enable them to record and transmit sales and other tax information at the time of sale to the ZIMRA servers, for use by the authority in Value Added Tax administration. All VAT registered operators should fiscalise as outlined in SI 104 of 2010 and must comply with the requirements of ZIMRA's Fiscalisation Data Management System (FDMS), set out further in its notice on compliance with the FDMS.
The duty reaches past VAT registration. ZIMRA 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 of the same Act, and that the obligation also applies to taxpayers with an annual turnover below the VAT registration threshold of USD 25,000.00.
The device behind the problem
ZIMRA describes fiscal devices as electronic devices used in the recording of transactional data before it is sent to its servers, either hardware based (physical devices) or software based (virtual devices). Each holds a fiscal memory: a special read only memory permanently built into the device to store tax information at the time of the sale.
Four broad categories are on the market: fiscalised electronic registers, also referred to as cash registers or electronic tax registers (ETRs); fiscalised printers; electronic signature devices (ESDs); and virtual fiscal devices (VFD). VAT registered operators and taxpayers not registered for VAT are allowed to choose any fiscal device they prefer, based on the nature of their business and their capacity to implement the chosen option. Since equipment varies, we start by asking what you run and what it reports.
Virtual fiscalisation and the API
Virtual fiscalisation is the use of software based Virtual Fiscal Devices, an Application Programming Interface, or POS software compatible with FDMS for recording, transmitting or interfacing with ZIMRA servers. ZIMRA lists two options: a direct interface from the taxpayer's server to the ZIMRA server, and one from the taxpayer's accounting or POS system.
Any registered operator is eligible, depending on taxpayer needs and the ability to develop APIs for interfacing with the ZIMRA FDMS. ZIMRA describes the route as suitable for medium to large taxpayers processing transactions on connected servers, accounting systems or point of sale systems, and notes that small traders can also use it through mobile point of sale. The API can be accessed by taxpayers free of charge from the ZIMRA website.
The day was left open
The most common call is the simplest. The branch locked up without running the close, a workstation was shut down part way through it, or an overnight job failed and nobody read the log.
Query the device first and write down the fiscal day number, the date it covers and the status it reports. Work from that number through the whole reconciliation. The till journal for yesterday and the fiscal day you are trying to close become two different things once trading has run past midnight.
A closure that will not complete
Two symptoms account for most of the rest. In the first, the operator presses close and no confirmation ever appears, so the day sits half finished and the till can neither invoice nor move on. Pressing close again muddies the record. Give it time, keep polling the status, and note when the close was first submitted.
In the second, the device reports that the closure was refused. What we find underneath is a mismatch between what the till counted and what reached FDMS: a receipt issued on the till and never submitted, a receipt sent twice after a retry, or a receipt refused at validation while the till carried on counting it as a sale. Resubmitting reproduces the same mismatch. Reconcile first. Line the receipts held for that fiscal day up against the device journal by receipt counter, find the first counter where the two diverge, correct the underlying record, then close again.
Counters also drift when the device's own sequence is disturbed: a till restored from an older backup, a lost state file, two instances sharing one set of device credentials. A restored backup is the worst of them, because the device will try to reissue numbers it has already used. Stop trading on it until the sequence has been reconciled. Where the closure still will not clear once your records are right, your device supplier or ZIMRA resolves it, and the call goes faster with the device identifier, the fiscal day number and date, and the disputed receipt counter to hand.
Offline trading and the backlog
Power cuts and dropped links are ordinary here, and the devices we support keep selling through them, holding what they issue until the connection returns.
That backlog is where closure failures are manufactured. Close a day while receipts are still waiting in it and the totals submitted cannot agree with what ZIMRA holds.
The order is fixed. Restore connectivity. Send the backlog oldest first, leaving the sequence alone. Confirm nothing is left waiting. Close the day. Where a device submits offline receipts as files, keep one fiscal day to a file and never mix days. A backlog that keeps growing is worth raising with your supplier.
Buying or replacing a device
Some closure problems end with the hardware. ZIMRA states that hardware fiscal devices should be acquired from the approved suppliers, who assist taxpayers in identifying appropriate devices, install them and provide training on appropriate usage.
ZIMRA also sets out incentives. Registered operators can claim 50% of the cost of acquisition of the fiscal electronic registers as input tax on their VAT 7 Return, with the remaining 50% spread over two years and claimed as SIA on the Income Tax Return (ITF 12C). A rebate of duty applies to approved suppliers, importation by them carries no VAT, and the local supply is zero-rated.
What failing to fiscalise costs
Fiscalisation rests on SI 104 of 2010 as read with SI 148 of 2016 and SI 153 of 2016. ZIMRA's notice on offences and penalties in fiscalisation sets “a civil penalty of US$25.00 per point of sale” for each day a person who fails to fiscalise in terms of section 3 remains in default, running to a maximum of one hundred and eighty-one days. After 181 days that person is guilty of an offence and liable on conviction to a fine not exceeding level seven, imprisonment for a period not exceeding 12 months, or both.
The same notice sets out offences for manufacturing, selling or distributing unapproved fiscal devices, and for failing to comply with the Second Schedule. Requirements change, so confirm your own position with ZIMRA or your tax adviser and keep an eye on ZIMRA's public notices.
Questions we get asked
We trade below the VAT threshold. Does any of this reach us? ZIMRA states the obligation to fiscalise applies below the VAT registration threshold of USD 25,000.00.
Does clearing a closure touch our accounts? Africube's ZIMRA FDMS integration is built to the ZIMRA FDMS specification and is read-only against your books: we read, never write, and your books stay untouched.
Who resolves a refused closure? Reconcile your own records first, so that whatever you take to your device supplier or ZIMRA arrives with the fiscal day number and the disputed receipt counter attached.
New to fiscalisation? Start with what FDMS is. If a day is failing to close now, tell us what your device is reporting.