The new system shows the same number of products as the old file, but one product's quantity belongs to the wrong warehouse. Counts agree; operations do not. ERP migration acceptance therefore needs a reconciliation report you can trace, rather than a screenshot saying the import succeeded.
Ask the provider what it compares, against which version, and how it explains differences before you approve the outcome. Reports vary by data type and transformation method. Moving opening balances differs from moving complete transaction history. Do not let “migration” conceal that difference in a proposal.
Fix the comparison scope first
In a fictional example, an office supplies distributor moves products and quantities from two warehouses into a new ERP. The agreed scope covers thirty active products and known starting quantities, while previous years remain in a separate archive. These are teaching boundaries, not a recommendation to move only balances or discard history.
The report needs the source name, extraction date, selection criteria, transformation-map version and test environment. If discontinued products are excluded, show their count and the reason. Comparing the entire source file with a result covering only active items produces a misleading difference even when the import works correctly.
Six layers in the reconciliation report
| Layer | Evidence to request | What it does not establish alone |
|---|---|---|
| Coverage | Included and excluded types, periods and warehouses. | That all company history moved. |
| Counts | Accepted, rejected, excluded and pending, with explanations. | That every record's contents are correct. |
| Fields | Source, target, transformation, unit and format mapping. | That relationships to other records are correct. |
| Control totals | Quantities by product, warehouse and approved unit. | That an overall total reveals every error. |
| Relationships | A sample connecting products, warehouses and required documents. | Completeness of excluded attachments. |
| Exceptions | Reason, owner, decision and verification after correction. | That a pending case passed validation. |
For financial scope, the appropriate finance specialist defines acceptable reports, totals and criteria. This table is a framework for accepting a technical service, not an accounting policy or permitted financial variance threshold. Do not combine different currencies or units without an approved, disclosed conversion rule.
Make different representations explainable
The old system might represent a pack of ten units as one entry while the new system uses base units. In our fictional example, five packs mean fifty units if the data owner approves that definition. Comparing five with fifty does not automatically reveal an error; the transformation rule must be recorded and tested against a clear sample.
Odoo documentation covers imports, field mapping, identifiers and relationships between records. These details explain the need for transformation mapping, but file acceptance does not establish that the data's meaning is correct. The process owner reviews meaning; the implementer demonstrates what the migration tool performed.
Separate moved data from validated data
AWS DMS documentation distinguishes validated, pending, mismatched and unvalidatable records. The product compares source and target data within its supported boundaries. The useful distinction here is between migration and validation; DMS is not required, nor does this imply that it verifies every ERP business rule.
Request pending cases separately rather than adding them to successful ones. Each discrepancy should lead back to a source identifier and its target result or the reason it is absent. A lengthy error file without a decision owner is not a completed reconciliation report, even if technically delivered.
Test the report with a known error
In a test environment, prepare an agreed case with quantity assigned to the wrong warehouse, another requiring unit conversion and a third deliberately excluded. Ask the report to detect the first, explain the second and separate the third. This tests the acceptance tool itself; it does not require corrupting live production data.
After correction, show what changed, why it was accepted and the verification version. Do not rely on an undocumented manual correction that cannot be repeated during final migration. If the transformation map changes, ask which previous results must be checked again because of it.
Define the data cutoff
Work may continue in the source after the test sample is extracted. Agree how later changes will move, when final comparison occurs and who authorizes operation. Approval should identify a report version and known exceptions, rather than generally approving all data that might arrive later.
Consult customer duplicate rules when identity merging is included; that is different from proving reconciliation. To request ERP data migration from Nextwave, send a scope, a sanitized sample and the report layers you require, then discuss unknowns before committing to final migration.
Validation sources
The official Odoo 19 import documentation source and AWS DMS data validation documentation were opened on 3 November 2026. They support mapping mechanisms and validation states. The example and proposed report are neither an accounting audit nor a guarantee of migration completeness.
