Define the migration data and operational starting point

Separate customer, supplier and product records from opening balances and historical transactions. Agree the period from which live operations will start and whether the project includes older transactions or only balances and open items.

If you choose not to migrate older details, plan how they will remain accessible in the previous system or organized files. This is a project-planning recommendation, not a statement of statutory retention periods or permission to delete older documents.

Prepare the source before importing

Review duplicate customer and supplier names, product codes, units of measure and accounts used for the same type of transaction. Assign an owner to review each data group and approve changes. A file passing technical import checks does not establish that its contents are correct for accounting purposes.

If you find unexplained differences, record them and agree their treatment before approving balances. Do not hide a difference in a temporary account simply to finish migration without a clear agreement to review it.

Map the old chart of accounts to the new one

Create a table showing the source account, corresponding Odoo account, balance type and any change in classification. Ask how receivable and payable detail will be preserved, rather than importing customer and supplier totals without usable supporting detail.

Data group Reconciliation to propose to the project team
Account balances Compare the source trial balance with the migration result
Customers and suppliers Reconcile open items to total balances
Inventory, where included Review quantities and valuation, and tie value to the accounts
Cash and banks Compare balances with available documents and reconciliations

This is a suggested migration acceptance checklist, not confirmation that your data has been reviewed or that every item is included in an implementation proposal.

Test work after migration

Try sales and collection, purchasing and payment, and inventory movements where included; then review the resulting reports. Ask team members to perform their own tasks during training, rather than only watch the implementer.

For invoicing, ZATCA explains that the integration phase requires the electronic solution to connect with its systems and generate invoices in the required format. Keep balance-migration testing distinct from invoice-readiness and integration testing when that work is included in the project scope.

Agree the move into live operations

Before stopping entry in the source, agree who records transactions during the transition, how duplication will be prevented, and how issues that prevent go-live will be handled. Keep reconciliation results and a list of known differences, and assign responsibility for follow-up after operations start.

There is no fixed duration suitable for every migration. Base the go-live decision on data, testing and team readiness, not simply completion of file uploads.

Sources

https://zatca.gov.sa/en/E-Invoicing/Introduction/Pages/What-is-e-invoicing.aspx

Start with the condition of your data

If you cannot rely on current balances, start with an Accounting System Health Check for a written findings report within the agreed scope. The check excludes remediation, which requires a separate proposal. Once the migration requirements are clear, ask Aleem to scope an Odoo Accounting Implementation, including the agreed data, balances, testing and training.

Aleem Consultations