Why there is no list price
Africube does not publish a price for FDMS integration, and any number quoted before someone has looked at your setup is a guess. The cost follows a short list of facts: which fiscalisation route you take, how many places you invoice from, how many documents you raise, what you keep your books in, and how much of the work you hand over.
For the shape of the system itself, start with what FDMS is.
The obligation that sets the floor
ZIMRA describes fiscalisation as configuring fiscal devices so they record and transmit sales and other tax information at the time of sale to the ZIMRA servers, for use in Value Added Tax administration. Its fiscalisation guidance 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, and 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. The same page applies that obligation to taxpayers with an annual turnover below the VAT registration threshold of USD 25,000.00.
ZIMRA's notice on offences and penalties in fiscalisation sets out 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, not exceeding one hundred and eighty-one days, after which continued default is an offence liable on conviction to a fine not exceeding level seven, imprisonment for a period not exceeding 12 months, or both. The penalty counts points of sale, the same number that drives most of your integration cost. Requirements are revised from time to time, so confirm your current position with ZIMRA or your own adviser before you commit a budget.
The device decision, and what it does to the bill
ZIMRA's fiscalisation overview lists four broad categories of fiscal device: fiscalised electronic registers, also referred to as cash registers or electronic tax registers; fiscalised printers; electronic signature devices; and virtual fiscal devices. A fiscal memory, on ZIMRA's definition, is a special read only memory permanently built into a fiscalised device to store tax information at the time of the sale.
The same guidance allows VAT registered operators and taxpayers not registered for VAT to choose any fiscal devices they prefer, based on the nature of their business and their capacity to implement the chosen option. Hardware fiscal devices should be acquired from the approved suppliers, who ZIMRA says will assist in identifying appropriate devices, install them and provide training. That part of your bill is set by the device supplier.
Incentives attach to acquisition. ZIMRA states that registered operators can claim 50% of the cost of acquisition of the fiscal electronic registers as input tax on their VAT 7 return, and the remaining 50% is spread over two years and claimed as SIA on the income tax return (ITF 12C). The same page lists a rebate of duty for approved suppliers, no VAT on importation by them, and zero-rating on local supply.
Virtual fiscalisation and the free API
Virtual fiscalisation is the use of software based virtual fiscal devices, an application programming interface, or POS applications 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 a direct interface from the taxpayer's accounting or POS system to the ZIMRA server. 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, especially those processing transactions on connected servers, accounting systems or point of sale systems, and states that small traders can also use virtual fiscalisation through mobile point of sale.
ZIMRA states that the API for the virtual fiscalisation option can be accessed by taxpayers free of charge from its website, where the fiscalisation API documentation is published for download. What you pay a supplier for is the work of building against it: configuration, field mapping, testing, correcting what testing exposes, and keeping the connection working once it is live.
Till points, branches and document volume
The count of places where a fiscal document is created is the largest single driver. A back office raising invoices from one accounting system is one point; a shop floor with six tills is six. Each site is set up and tested on its own, so a business trading from five towns carries five times the setup work of the same business trading from one, and the penalty described above scales on that same count. Volume tells at the top end, where queuing and retries have to hold documents through an hour of lost connectivity and submit them in order once it returns. Give any prospective supplier a monthly document count.
Your accounting system, its version and where it runs
Sage Evolution, Sage Pastel and QuickBooks each store invoice data differently, and versions of the same product differ from each other. An older version may not expose what the connection needs, which turns an upgrade into part of the project. Extra fields, modified document layouts and add-on modules are mapped by hand.
Where the system runs matters as much as what it is. A server in your own office, a server you rent, and an instance hosted for you by a third party each present a different access problem. For fiscalisation our access to your accounting data is read-only. We read, never write. Your books stay untouched. If read access cannot be granted under your current arrangement, that arrangement has to change first, and the change is part of the cost. Existing Sage Evolution work in your environment shortens the assessment.
Which documents are in scope, and who gets trained
A tax invoice is the starting point and almost never the end of it. Credit notes, debit notes, cash sales, account sales, returns, zero-rated and exempt lines, and documents carrying more than one currency each have to be mapped and tested. Write down every document type you issue, including the awkward ones you issue twice a year, then ask each supplier which of them the quote covers.
Historical documents are usually out of scope, which suits most businesses until there is a gap between existing records and the go-live date. Training scales with people and places. Support covers the hours you need cover for, how quickly you need an answer, and who takes a stalled or rejected submission back to your device supplier or to ZIMRA.
What is one-off and what recurs
One-off in most projects:
- Scoping, and the compatibility assessment of your system and version
- Configuration, field mapping and development for the non-standard parts
- Testing, and correcting what testing exposes
- Going live, with cover over the first trading days
- Training
Recurring in most projects:
- Support and maintenance at the level you choose
- Monitoring, and clearing stuck or rejected submissions
- Hosting, where any part of the solution is hosted
- Adding branches, till points or document types later
Compare the two lines over thirty-six months: a low one-off with a heavy monthly charge can overtake the quote that looked expensive on day one.
Getting a number for your business
We scope before we quote, and the conversation is short if you arrive with the facts: your accounting system, its version and how it is hosted; branches and till points; a monthly count of documents by type; the currencies you invoice in; and whether you already hold fiscal devices.
Our ZIMRA FDMS integration is built to the ZIMRA FDMS specification. Send us your setup and we will come back with a costed proposal and the assumptions it rests on.