Your clerk raises an invoice in Sage Evolution or Sage Pastel. ZIMRA's Fiscalisation Data Management System has to receive a fiscal record of that sale. Everything between those two events is integration work, and its cost depends almost entirely on how your Sage installation was built.
Sage stays your system of record. Your team carries on invoicing as today, while the fiscalisation layer reads a finalised sales document, assembles the submission, sends it to FDMS, and returns the fiscal details for the document you hand the customer. Africube builds that integration to the ZIMRA FDMS specification, published as ZIMRA's fiscalisation API documentation; the product sits on the ZIMRA FDMS integration page.
Who has to fiscalise
ZIMRA defines fiscalisation as configuring fiscal devices to record and transmit sales and other tax information at the time of sale to the ZIMRA servers, for use 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 FDMS, per ZIMRA's page on fiscalisation explained.
The obligation reaches past the VAT register. The same guidance 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 this applies to taxpayers with an annual turnover below the VAT registration threshold of USD 25,000.00.
Where a Sage integration sits
ZIMRA describes fiscal devices as electronic devices that record transactional data before it is sent to the ZIMRA servers, hardware based or software based, in four broad categories: fiscalised electronic registers, also called cash registers or electronic tax registers; fiscalised printers; electronic signature devices; and virtual fiscal devices. A fiscalised device carries a fiscal memory: a special read only memory permanently built into it to store tax information at the time of the sale. Operators registered for VAT and those who are not may choose any fiscal devices they prefer, based on the nature of their business and their capacity to implement the chosen option.
Virtual fiscalisation, in the same guidance, is the software route: software based virtual fiscal devices, an application programming interface, or POS applications compatible with FDMS for recording, transmitting or interfacing with ZIMRA servers. The two options named are a direct interface from the taxpayer's server to the ZIMRA server, and one from the taxpayer's accounting or point-of-sale system. A Sage integration sits in the second.
ZIMRA calls that route suitable for medium to large taxpayers, especially those processing transactions on connected servers, accounting systems and point-of-sale systems, and says small traders can use it through mobile point of sale. Eligibility turns on taxpayer needs and the ability to develop APIs for interfacing with FDMS, and the API is available free of charge from the ZIMRA website.
Where hardware forms part of your answer, ZIMRA states that hardware fiscal devices should be acquired from approved suppliers, who help taxpayers identify devices, install them and provide training. Registered operators can claim 50% of the acquisition cost of 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).
Evolution and Pastel are two different jobs
People say "Sage" as though it were one product; for this work it is two assessments. Evolution installations are normally backed by a SQL database on a server, often carrying several companies, branches and user roles. Pastel installations are more often a smaller footprint on a shared drive or single machine, the layout customised by whoever set it up years ago.
That difference changes how a finalised invoice can be read, and how the fiscal details reach the printed document. A quote given without knowing which you run, and which version, is a guess.
Where the invoice data lives
An invoice that looks finished on screen is not always finished in the data. In many Sage setups a document sits in a working state until processed or posted, and only then becomes a fixed, numbered record. Fiscalisation hooks onto that record, so part of the assessment is mapping when a document becomes final in your configuration and agreeing that moment as the trigger. Where your team processes in batches at day end, that shapes when the fiscal record appears.
The same applies to anything kept outside the standard fields. Custom columns, user-defined fields and a description line carrying the customer's order number all have to be mapped into the shape a fiscal invoice takes.
The read-only position, in plain terms
Africube's fiscalisation access to your accounting data is read-only. We read, never write. Your books stay untouched.
In practice that means a restricted account with read rights to the sales documents in scope. No journals are created, no balances adjusted, no transactions posted back into your ledgers. The fiscal details FDMS returns are held in the fiscalisation records and printed through your invoice layout. Get that written into the scope document by whoever quotes you.
What changes for the accounts team
The day-to-day change is smaller than most people fear.
- Your invoice layout is amended so the printed document carries the fiscal details FDMS returns.
- Someone in accounts owns the status view, looks at it daily, and knows what to do when a submission sits in a failed state.
- Most failures are data problems: a missing customer detail, an unmapped tax code, a document type nobody tested. Where the trouble sits with a device or with FDMS, your supplier or ZIMRA resolves it.
- Connectivity drops in Zimbabwe. The design has to say what happens to documents raised during an outage.
The team that copes best knows in advance which shortcuts will stop working.
What failing to fiscalise costs
ZIMRA's page on offences and penalties in fiscalisation states that any 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, not exceeding a period of one hundred and eighty-one days, and that a person who continues to be in default after 181 days is guilty of an offence and liable on conviction to a fine not exceeding level seven or to imprisonment for a period not exceeding 12 months or to both. It also references SI 104 of 2010 as read with SI 148 of 2016 and SI 153 of 2016.
The civil penalty runs per point of sale, so it scales with the number of tills you run.
What to prepare before an assessment
ZIMRA publishes public notices, among them one on compliance with the FDMS. On the Sage side, seven things make the first conversation useful:
- The product, edition and version number, from the About screen. Older versions may not expose what is needed.
- How and where Sage is hosted, and who administers it. This decides whether a reliable connection to FDMS can be held at all.
- Two or three sample invoices and one credit note, with confidential details removed.
- The tax codes in use, your zero-rated and exempt lines, and how discounts, rounding and currencies are handled.
- Invoice volume, branch count and number of invoicing users.
- Any customisation: modified layouts, add-ons, user-defined fields, anything a previous consultant built.
- Your current fiscalisation position and what you have registered with ZIMRA.
With those in hand, a compatibility conversation takes an hour. Without them it takes three meetings. Where the wider need is getting Sage data into reporting and other systems, that scope sits under Sage Evolution integration.
None of this is tax or legal advice. Fiscalisation requirements and deadlines change and what applies depends on your circumstances, so confirm your obligations with ZIMRA or your tax adviser before committing to a plan.