How to test reconciliation during a credit union core conversion

Credit union core conversion reconciliation testing verifies that member, account, transaction and accounting data in a new core system agrees with an approved source-system baseline after conversion. It checks both record-level values and financial control totals, including share balances, loan balances and general ledger (GL) postings, so the credit union can identify unexplained differences before cutover or release approval.

What reconciliation must cover

Set the reconciliation scope from the conversion mapping and accounting controls. Include member identifiers and relationships, share and deposit accounts, loan principal and accrued interest, rates and repayment schedules, transaction history, holds, fees, delinquency status, and account status where those fields move to the new core. Include linked products and any downstream balances that rely on the converted data.

Reconcile at several levels:

• Record level: Match each source member, account and transaction to its target record using a stable key or an approved cross-reference. Compare required fields and values after applying documented transformations.
• Product and status level: Compare counts and balances by product, branch, currency, account status and other dimensions used in operational or financial reporting. This can expose a missing closed account or a misplaced loan that an overall total would hide.
• Accounting level: Confirm that converted subledger balances agree with the corresponding GL control accounts, and that debit and credit totals follow the credit union's posting rules.
• Transaction level: Check that posted transactions appear once, with the expected amount, sign, effective date and status. Treat pending, reversed, backdated and in-flight transactions according to the agreed conversion rules.

Reconciliation is different from a data-quality check. A field can be populated and valid in format while still carrying the wrong member, balance or accounting value. Reconciliation tests whether the migrated result agrees with its defined source and control totals.

Prepare a repeatable comparison

Agree the source extraction point, conversion window and target capture point before testing. Record whether extracts include transactions posted during the cutover window, pending items, accruals and end-of-day processing. An inconsistent snapshot can create apparent differences even when the conversion is correct.

The test also depends on an approved field mapping, product rules, currency precision, treatment of rounding, identifier crosswalks and documented exclusions. Use the same transformation rules in the comparison that the conversion uses. Preserve source and target extracts, mapping versions, run identifiers and reconciliation outputs so a result can be reproduced.

Use masked or otherwise authorised test data in lower environments. In production-like testing, restrict access to member-level data and retain only the evidence needed for investigation and approval.

Run reconciliation and investigate exceptions

First compare record counts and aggregate balances by product and status. Then match individual records and transactions. For each comparison, report the source value, target value, difference, matching key and applicable rule. Separate expected differences, such as a documented account-number change, from unexplained mismatches. Do not hide differences with an aggregate net total: a missing debit and a duplicate credit can cancel each other out.

Investigate exceptions by tracing the source record through extraction, transformation, load and target posting. Common causes include incomplete extracts, incorrect product mapping, duplicate loads, omitted closed accounts, sign changes, rounding differences, mismatched dates, and environment drift between conversion runs. Retest after correcting the cause, and check that the correction has not introduced a new mismatch elsewhere.

Practical example

Suppose the approved source snapshot contains 12,406 share accounts with a combined ledger balance of $8,420,315.27. The target extract has 12,405 accounts and a balance of $8,417,815.27. The count differs by one and the balance differs by $2,500. A total-only check would identify a variance, while account-level matching can show whether one account was omitted, whether a balance was transformed incorrectly, or whether the snapshot rules excluded a valid record.

The test passes only when the count and balance differences are either resolved or explained by an approved conversion rule, and the target share subledger agrees with its GL control balance. Record the exception, its root cause, corrective action and retest result. Apply the same method to loans, including principal and accrued amounts, using the credit union's defined accounting controls.

Set evidence and release criteria

Define pass conditions before execution. They should specify which totals must match exactly, which transformations may produce a known difference, who can approve an exception, and which critical product or accounting mismatches block cutover. Any permitted tolerance needs a stated reason, calculation and owner; a blanket tolerance can conceal material errors.

Retain signed-off control totals, record-level exception reports, conversion and comparison run identifiers, defect references, approvals and retest evidence. Link each control to its requirement or conversion rule. Reconciliation supports a cutover decision alongside functional, integration and operational checks; it does not establish that member-facing workflows work correctly.