The finance team approves a new ERP, then faces the hardest cutover question: can the business still explain an older supplier balance, a stock adjustment or a credit note raised before go-live? A closing balance is not the same thing as an auditable history.
ERP data migration in Zambia should preserve financial accuracy, transaction context and access to evidence. M&J’s ERP implementation approach treats migration as a controlled business handover: extract, clean, map, reconcile, archive and obtain formal sign-off.
Whether the legacy sources are Sage Pastel, QuickBooks, spreadsheets or another application, directors, auditors, the Zambia Revenue Authority (ZRA) and operating teams must be able to retrieve records after the old system is retired.
Start with the records you must be able to explain
Zambia’s Companies Act No. 10 of 2017 requires companies to maintain accounting records that explain transactions and financial position. A migrated trial balance, without the invoices, receipts or explanations supporting it, cannot provide a complete practical audit trail.
ZRA’s general records guidance requires relevant business and tax records to remain available for at least six years. The migration design should decide what belongs in the live ERP, what goes into a controlled archive and how both can be retrieved. Check any longer period required by a specific tax, dispute or sector obligation.
Build a records inventory before selecting migration fields. We normally separate the information into four groups:
-
Transactional history: sales invoices, supplier bills, receipts, payments, journals, credit notes, stock movements and payroll results.
-
Supporting evidence: invoice PDFs, delivery notes, contracts, bank statements, approvals and scanned receipts.
-
Master data: customer, supplier, employee, product, chart-of-account and cost-centre records.
-
Control evidence: opening-balance workings, mapping tables, exception logs, reconciliation reports and migration sign-offs.
Keep source extracts with transaction IDs. An auditor should be able to move from an ERP balance to the old transaction, the underlying document and the rationale for any mapping or correction.
The judgement call on detailed history
Where legacy records are complete, consistent and useful for ongoing transactions, consider importing detailed history after testing the impact on reporting periods, taxes and audit trails. Historical records should not be reprocessed as new fiscal transactions merely because they are imported into a new ERP.
Where older data is incomplete or highly customised, a read-only archive plus validated opening balances and selected current records may be safer. Preserve source files, search indexes and the mapping that connects legacy IDs to new records; test retrieval before shutting down the old system.
Build the migration design before loading data
A migration template is not enough. The team needs written rules for what moves, what remains accessible, who approves exceptions and how the business will prove completeness.
Quick management control matrix
| Workstream | Evidence to retain | Business sign-off |
|---|---|---|
| Finance | Trial balance, aged balances, bank and asset reconciliations | Finance lead |
| Stock and operations | Item codes, stock quantities, valuation and movements | Operations lead |
| Tax and invoicing | Smart Invoice testing, credit notes and cutover exceptions | Tax lead |
| People and privacy | Payroll, NAPSA settings, data access and transfer register | HR / data lead |
| History and archive | Source exports, mappings, retrieval checks and restore tests | Project sponsor |
Step 1: Freeze the scope and period
Approve a cutover date, reporting periods, legacy sources and the level of detail to migrate. Include all records needed for ZRA’s retention period in the live system, the archive or both, without assuming every old entry must be recreated as a new transaction.
List every legacy source. Many enterprises identify Pastel as the accounting system but later find stock data in Excel, payroll data in another application, and customer contracts in shared drives. Missing one of these sources breaks the audit trail between the ledger and operations.
Step 2: Map master data with business owners
Create a mapping table that shows each legacy field, its target ERP field, its transformation rule and its owner. For example, map obsolete customer codes to an inactive status rather than deleting them if they appear in historical invoices.
Do not let the implementation team decide account mappings alone. Finance should approve the chart-of-account mapping, procurement should review supplier duplicates, and operations should validate item and warehouse records. The most common mistake is to merge similar-looking records without recording why the team made that decision.
Step 3: Clean data without erasing evidence
Correct duplicates, invalid tax codes and inconsistent names in a staging file. Keep the original extract unchanged, then maintain an exception log that states the source value, corrected value, reason, date and approver.
For example, if two supplier records represent one legal entity, retain both legacy IDs in the cross-reference table. Future users may need that evidence to match an old invoice or payment to the new supplier master.
Step 4: Reconcile before and after every test load
Run a trial balance, accounts receivable ageing, accounts payable ageing, inventory valuation, bank position and tax reports from the legacy system at an agreed date. Run the same reports after the test migration and investigate every difference, even when the total difference looks small.
Do not accept a reconciliation that only proves total debits equal total credits. A balanced ledger can still contain customer balances assigned to the wrong account, missing stock movements or payroll liabilities mapped to an incorrect period.
Consider an illustrative retailer migrating several years of supplier transactions from QuickBooks. The opening payable balance agrees with the old ledger, but the import omits the invoice references behind individual supplier balances. A later payment dispute becomes difficult to resolve because the finance team cannot trace the balance to the source documents.
The stronger approach is to preserve invoice-level references, payment allocations and the original export, reconcile supplier balances at cutover, and retain controlled read-only access. That reduces investigation time and helps protect supplier confidence without inventing a financial saving.
Treat ZRA Smart Invoice as a go-live requirement
Where the taxpayer uses an accounting package or ERP to issue invoices, test the appropriate certified ZRA Smart Invoice integration through the Virtual Sales Data Controller (VSDC). Confirm the approved product, version and live taxpayer configuration; the presence of an invoicing screen is not compliance evidence.
ZRA required VAT taxpayers to complete Smart Invoice registration and integration, where relevant, by 30 September 2024, with standard non-compliance penalties applying from 1 October 2024. The current Smart Invoice programme also covers other specified tax categories. Confirm the taxpayer’s applicable obligations rather than assuming the rule applies only to one group.
Test the full invoice cycle before approval. Include tax codes, invoice numbering, customer details, credit notes, returns and cancelled sales. Historical credit notes require particular care because finance teams must distinguish the original invoice date, the accounting posting date and the Smart Invoice treatment in the new process.
Under the rules effective from 1 January 2025, manually recorded transactions must be uploaded to Smart Invoice within 72 hours after the system is restored. Make outage numbering, recovery ownership, upload confirmations and reconciliation part of the ERP cutover rehearsal.
ZRA’s October 2026 transfer of historical tax-account data to TaxOnline is a timely reminder that technical migration and taxpayer reconciliation are different steps. ZRA asked businesses to review legacy returns, payments and other entries and supported a reconciliation period for discrepancies. ERP teams should adopt the same evidence-led approach to their own historical records.
Protect payroll and personal data
Payroll migration needs its own approval track. Zambia’s NAPSA formal-sector contribution rate is 10% of relevant gross earnings, divided equally between employee and employer at 5% each, with employer remittances due by the 10th of the following month.
For 2026, NAPSA’s monthly insurable-earnings ceiling is K37,236. The corresponding maximum is K1,861.80 for the employee and K1,861.80 for the employer, or K3,723.60 in total. These are statutory payroll parameters, not advisory-service prices. Reconfirm them whenever NAPSA publishes an annual revision.
Migrate employee master data, payroll opening balances, leave positions, statutory liabilities and year-to-date values only after payroll and HR teams reconcile them to the old system. Preserve payslips, contribution schedules and adjustment support in the archive when the ERP does not hold them in their original form.
Zambia’s Data Protection Commission asks controllers and processors to document personal-data categories, database locations, security arrangements and cross-border disclosures. Check registration status, access permissions, processor contracts and any separate overseas-transfer or storage authorisation before moving live payroll or customer records to a cloud platform.
Consider a distributor transferring payroll spreadsheets into a cloud ERP. If the project can show that employee details were imported accurately but cannot identify which vendor staff can access bank details or where cloud backups are stored, the data-governance work remains incomplete.
The better approach is to record data categories, user permissions, retention rules, sharing arrangements and security controls before loading production data. The company should also keep evidence of who approved those decisions, because a privacy register completed after a problem offers little practical protection.
Keep legacy access after go-live
Do not withdraw access to the legacy environment immediately at go-live. First complete finance, operations, tax and payroll reconciliations, test archive retrieval, assign named read-only users and approve a defined retirement plan. A secure export may replace a legacy software licence only when users can reliably open and interpret it.
Read-only access should not mean unmanaged access. Set named users, an expiry date, backup arrangements and a retrieval process. Test a few ordinary questions: find a 2022 customer invoice, retrieve a supplier payment document, trace an inventory adjustment, and produce a payroll report for a selected month.
A controlled archive is often the right answer for older data. It should contain original exports, document files, field mappings, reconciliation reports, exception logs and instructions for retrieval. Without these elements, the business may retain data but lose the meaning of the data.
Migration sign-off checklist
Before production cutover, ask each business owner to sign off on the following:
-
Finance has reconciled the general ledger, receivables, payables, cash and fixed assets.
-
Operations has checked inventory quantities, valuation and movement history where applicable.
-
Tax has tested Smart Invoice invoice creation, credit-note treatment and offline-sales procedures.
-
Payroll has reconciled employee balances and statutory contribution data, including NAPSA settings.
-
Data governance has documented personal-data access, security and any overseas transfer arrangements.
-
Management has approved the archive, read-only legacy access and retention process.
These approvals create accountability. They also show which figures the business has verified and which matters still require investigation before the legacy environment closes.
Frequently asked questions
How much history should we migrate from Pastel or QuickBooks?
Migrate the detailed history needed to operate and report accurately; archive retained records in an accessible, indexed format where full import is unnecessary. ZRA’s general six-year retention expectation still applies even when an ERP contains only validated opening balances.
Can we migrate only opening balances into a new ERP?
You can use opening balances as part of the migration, but they do not replace transaction history and supporting records. Keep the workings behind each opening balance, along with source extracts and a route back to the documents that explain it.
When should Smart Invoice integration happen?
Complete and test Smart Invoice integration before go-live for a VAT taxpayer. The target ERP must operate as a Certified Invoicing System integrated through the VSDC interface, and a post-go-live workaround can expose the business to compliance and operational risk.
When can we retire the legacy system?
Retire it only after reconciliations, user retrieval tests and management sign-off. Keep records for the required retention period and make sure authorised users can retrieve them without relying on one former employee or an unsupported machine.
A successful migration preserves both reliable balances and the evidence behind them. Speak with M&J Consultants about ERP implementation in Zambia, legacy-data reconciliation, Smart Invoice integration and a cutover plan that protects business continuity.