In this article
- Key takeaway
- The challenge: two systems, uncertain ownership
- Illustrative case: a duplicated sales invoice
- The approach: validate transactions, not impressions
- Define one source of truth per process
- Include a month-end close
- Results: measurable exit criteria for ERP parallel runs
- Illustrative case: the month-end exception queue
- The exit principle
- Who owns the parallel-run controls?
- Frequently Asked Questions
- How long should ERP parallel runs last?
- Can staff enter data in both systems?
- Who should reconcile the two ERP systems?
- What Zimbabwe data-protection controls matter during a parallel run?
SERPA — ERP Implementation and System Assurance Team
Key takeaway
Define one authoritative system for each process, reconcile transactions and investigate exceptions before cutover. End parallel processing when approved evidence meets the agreed exit criteria, with clear ownership and controls over duplicate records and personal data.
A Harare finance manager may see matching totals in a new Odoo system and the legacy ERP, yet still face duplicated invoices, omitted credit notes or conflicting customer records. A parallel run should provide evidence for a safe transition, not create a permanent second accounting process.
Parallel running also requires careful data governance. Where ERP records contain personal information, Zimbabwe’s Cyber and Data Protection Act and Statutory Instrument 155 of 2024 make appropriate accuracy, security and accountability controls important. POTRAZ is the designated Data Protection Authority. The applicable controller-registration, access and data-handling requirements must be assessed for the organisation’s circumstances.
The challenge: two systems, uncertain ownership
A parallel run operates legacy and new processes at the same time to test whether financial and operational outcomes agree. It is useful when it has a defined scope, owner and exit decision. Without these, dual processing increases workload and the risk of inconsistent records.
A typical failure occurs when a supplier invoice is entered in the old system by one employee and again in Odoo by another employee, while an integration or migration load also posts a copy. Document ownership and the sequence of entry before dual processing begins.
Matching grand totals are weak assurance on their own. A missing credit note can offset a duplicated invoice; incorrect account mappings can remain hidden behind a balanced trial balance. Validate the underlying transactions, exception records and audit trail.
Illustrative case: a duplicated sales invoice
Consider a fictional Zimbabwean distributor, Mbare Industrial Supplies. Sales invoices are entered in both systems while selected records are also imported into Odoo. One invoice is posted manually and again by import. A month-end total does not immediately make the duplicate obvious, and the team must investigate debtor balances and correcting journals.
The preventive control is to name one system of record for each transaction type, assign unique cross-system document identifiers and route suspected duplicates to a reviewed exception queue before posting. An independent reviewer should confirm that the same economic event is not recorded twice.
The approach: validate transactions, not impressions
Design the parallel run to prove equivalence, then support a documented go/no-go decision. Compare transactions, control totals and exceptions every day, reconcile at month-end and use reviewers who are independent of the original data entry where practical.
Avoid asking all departments to duplicate all work indefinitely. Prioritise processes with material financial, customer, tax or inventory consequences, define a validation method and establish which platform has operational authority during the trial.
| Validation method | Best use | What the team checks | Why it matters |
|---|---|---|---|
| Transaction-by-transaction reconciliation | High-risk activity such as sales invoices, supplier invoices, payments, and journals | Document number, date, value, tax treatment, customer or supplier, account, and posting status | A total can agree while an individual document is duplicated or absent. |
| Control-total reconciliation | High-volume processes where every document check is not proportionate | Record count, total value, batch totals, and opening-to-closing movement | It tests whether the complete population moved through the process. |
| Exception-based sampling | Critical fields and unusual movements | New master records, changed bank details, unusual variances, and rejected documents | It directs experienced review to records with the highest control risk. |
Compare accounting journals and reports on a like-for-like basis: consistent transaction dates, currencies, company entities, account mappings and cut-off rules. Independent verification helps expose omissions that the original data-entry employee may overlook.
Define one source of truth per process
Create a process-by-process source-of-truth register before the run. The legacy system may remain authoritative for payment release while Odoo is tested for purchase-order processing. Publish that decision so users know which record may trigger an external transaction.
Control master data just as carefully. Assign ownership of customer and supplier creation, bank-account amendments, item codes and account mappings. Restrict access according to roles, preserve change logs and remove unnecessary parallel copies of personal data when the validation purpose ends.
Include a month-end close
Include at least one complete month-end close in a financial parallel run, unless a documented alternative test provides equivalent assurance for the approved scope. Accruals, cut-off, journal review and reconciliations reveal errors that may not appear during routine daily processing.
The acceptance decision should cover a repeatable close: trial balance, aged debtors and creditors, tax mapping, reconciliation evidence, material journal exceptions and management reporting. Completing invoices alone is not sufficient.
Results: measurable exit criteria for ERP parallel runs
Agree measurable exit criteria and a named decision-maker before the parallel run starts. Otherwise, the business may keep both systems active because no one is authorised to decide that the evidence is sufficient.
Set acceptance thresholds based on transaction volume, materiality and control risk. Treat unresolved high-risk exceptions separately from low-risk timing differences. The aim is a defensible decision, not an arbitrary claim that every system must match perfectly at every instant.
| Indicator | What to measure | Decision use |
|---|---|---|
| Unmatched transactions and value | Count and value of records not reconciled | Shows the financial exposure still unresolved. |
| Reconciliation rate | Percentage of in-scope transactions reconciled | Tests coverage, not just whether selected records match. |
| Duplicate-document rate | Repeated document IDs or repeated economic events | Exposes the direct risk created by dual entry and migration loads. |
| Aged unresolved exceptions | How long each variance remains open | Prevents old exceptions being hidden in a growing list. |
| Month-end close duration | Time needed to complete the close in each system | Reveals whether the new process is operationally sustainable. |
| Rework hours and input errors | Correction effort and user-entry defects | Identifies training, workflow, or integration issues before go-live. |
Illustrative case: the month-end exception queue
Consider a group migrating finance processes into Odoo while keeping the legacy system for comparison. Control totals match, but the exception queue includes supplier bank-detail changes and journals mapped to incorrect accounts. The apparent balance conceals control problems.
Assign each exception an owner, priority, resolution date and approved disposition. Material exceptions must be corrected, reconciled or formally evaluated by the accountable financial process owner before sign-off. The board should receive a clear summary of accepted residual risks.
The exit principle
A parallel run ends when approved evidence meets the exit criteria, not when employees have become accustomed to entering data twice.
For lower-volume operations, full transaction-level review may be reasonable. For higher volumes, use transaction-level checks on sensitive processes plus controlled totals and targeted exception review elsewhere. Payment, tax, supplier bank details and journal controls deserve particular scrutiny.
Who owns the parallel-run controls?
Give each control a named business owner before any duplicate processing begins:
| Role | Responsibility | Evidence |
|---|---|---|
| Finance process owner | Define reconciliation rules and sign off financial results | Reconciliation pack and signed exceptions |
| Operational process owner | Validate stock, fulfilment and customer transactions | End-to-end scenario results |
| Data and IT lead | Govern access, document IDs, interfaces and data copies | Access log, mapping record and exception trace |
| Executive sponsor | Approve exit criteria and the retirement of the legacy process | Go/no-go decision and risk acceptance |
Archive validation evidence securely, restrict legacy access after approved cutover and plan for retention or deletion of duplicate personal information according to the applicable legal requirements.
Frequently Asked Questions
How long should ERP parallel runs last?
Continue long enough to test normal activity, material exception scenarios and at least one financial close cycle, or a documented equivalent for the scope. The duration depends on operating complexity and whether the agreed exit criteria have been met.
Can staff enter data in both systems?
Only where the company has defined the authoritative system, input sequence, duplicate prevention and approval controls. Uncontrolled dual entry can create duplicate records and conflicting reports.
Who should reconcile the two ERP systems?
An independent finance or process-control reviewer should reconcile results wherever practical, with ownership assigned to the relevant process lead. The data-entry user should not be the only person certifying that the transaction is correct.
What Zimbabwe data-protection controls matter during a parallel run?
Apply appropriate access controls, accurate and current data handling, logging of sensitive changes and documented exception resolution. Confirm the organisation’s obligations under the Cyber and Data Protection Act and S.I. 155 of 2024, including controller requirements where relevant; the parallel run does not exempt an enterprise from data-protection duties.
A well-governed parallel run gives finance and operations a reliable reason to retire the old system. Speak with SERPA Africa about a tailored Odoo ERP readiness review, reconciliation plan and cutover support consultation.