CRM reconciliation:
what to check before acceptance.

1. Define the evidence before comparing it.

Write down the object or subset, extraction time, filters, expected source population and the fields that matter. Keep a copy of both exports and the rules used for each run.

The checker records input hashes and selected rules. A file hash helps identify the bytes used for a run; it cannot establish that the extraction itself included the right population. The migration owner must verify the exports against the intended scope.

2. Establish record identity.

The current checker expects a stable source identifier retained in the destination export. A destination system’s newly assigned ID is not a substitute unless the agreed matching route preserves the source ID.

Inspect missing identifiers, duplicate identifiers and source records without a match. Multiple destination rows carrying one retained source ID create an ambiguous match. Resolve the ambiguity before treating those records as compared.

3. Agree what equality means for each field.

Use exact text when the value must be preserved as written. Decimal equality can compare numeric representations such as 2500.00 and 2500, but it does not establish the correct currency, unit or business meaning.

If a migration deliberately changes a value, document the expected transformation before accepting it. An explicit accepted mapping should describe the approved change. Retain the original findings and rule set when rules change, so the reason for the rerun remains visible.

Two blank fields can be equal while both are invalid business data. Comparing an owner or company ID as text also cannot establish that the referenced record exists or has the right access.

4. Read coverage alongside findings.

Record how many source records were compared and how many were skipped. Read identity findings before interpreting field differences. Equal source and target row totals can hide missing records and duplicates.

Both runs have the same row totals. The original still contains a duplicate, a missing record and three selected-field differences. The corrected sample deliberately restores the matches and chosen values.

Read the HTML, CSV and JSON evidence. These are fictional fixtures, not measured customer outcomes.

5. Keep a decision record and rerun the same scope.

For each finding, capture the record ID, affected field, source and target evidence, decision, responsible owner and next action. Classify expected transformations separately from defects that need correction.

After corrections, rerun the agreed comparison using fresh exports. Preserve the earlier report. If the fields, rules, scope or extraction filters changed, document that change; a lower finding count alone cannot establish that the same checks passed.

The website’s review notes are separate annotations. Marking an item reviewed does not alter the checker’s finding or repair the underlying record.

6. Keep the wider acceptance decision visible.

State what the comparison covered and what still needs separate evidence. A zero-findings result applies to the supplied rows, selected fields and rules. It does not certify the whole migration.

• Confirm extract completeness against the intended business population.
• Check unselected fields and required business values.
• Test attachment content and accessibility.
• Review effective permissions, automations and workflows in the live system.
• Verify relationships and downstream behaviour where relevant.

A named business owner should make the final acceptance decision using the combined evidence and unresolved risks.