FDMS Onboarding Checklist for a Fiscal Software Project
Treat FDMS onboarding as a controlled technical and operational project. This checklist turns the public ZIMRA process into evidence that a business can review before activation.
1. Establish scope and ownership
- Name the taxpayer, branches, points of sale, currencies, VAT status, document types, responsible owner, technical contact, and escalation contact.
- Confirm whether the proposed route is hardware fiscalisation, a virtual fiscal device, or a direct server or POS interface.
- Record who will communicate with ZIMRA and who is authorised to approve configuration and sample output.
- Use a test environment and dummy data until the required output has been reviewed.
2. Inventory data and integration boundaries
Map how a sale becomes an invoice or receipt, where taxes and prices originate, how the document is numbered, and when it is committed. List payment methods, currencies, returns, credit notes, debit notes, buyer details, discounts, stock effects, and any upstream accounting identifiers.
Document the boundary between the POS, fiscal device or software, cloud service, and FDMS. Every retry needs a durable identifier so that a network interruption does not create an accidental duplicate.
3. Validate fiscal state and sample output
- Verify taxpayer and branch identifiers against current authoritative records.
- Record the registered device identity, certificate validity, fiscal-day number, receipt counters, and last acknowledged server state.
- Generate and review the sample fiscal invoice, credit note, debit note, close-day output, and QR or verification data required for the selected onboarding process.
- Keep approval messages and accepted samples with a date, reviewer, configuration version, and test evidence.
4. Rehearse failure and recovery
Test loss of network, app restart, device restart, duplicate submission, server rejection, expired credentials, fiscal-day mismatch, printing failure, and a partially completed sync. Decide which actions remain available offline and which must stop.
A restore package should never silently overwrite active device identity or counters. Reconcile the device and server state, record the decision, and require an authorised recovery step when the histories differ.
5. Activate and observe
- Approve a change window, rollback decision, backup, and named go-live owner.
- Confirm live registration before processing production transactions.
- Watch submission results, queue age, rejections, certificate expiry, fiscal-day state, and gaps in receipt sequence.
- Review the first fiscal document and first day close, then retain the signed-off evidence.