Quick answer: Reconcile the legacy system, migration files and target ERP against the same approved cutoff. Check completeness, account balances, open invoices, aging, assets and currencies—not just whether the import completed. Then reconcile each target subledger to its general ledger control accounts before releasing users to transact. Microsoft recommends a mock cutover and complete reconciliation before new transactions are created. (learn.microsoft.com)
Required output: A reconciliation workbook linking every control to source evidence, target evidence, differences, exception owners and approval.
This guide is for controllers, finance leads and ERP migration teams. The workflow is adaptable; product-specific examples refer to Microsoft Dynamics 365 Finance, not Business Central. The workbook and acceptance rules below are proposed controls, not vendor-prescribed thresholds.
1. Define the migration scope and freeze the comparison point
Start with a signed scope matrix. Microsoft distinguishes configuration data, such as currencies and tax codes, from migrated master data and open transactions. Keep those categories separate in your plan. (learn.microsoft.com)
For each legal entity, record:
- Financial scope: Opening balances, current-year movements, historical detail or a defined combination.
- Subledger scope: Open AP and AR documents, payments, credits, fixed asset books and bank reconciliation items.
- Master data: Accounts, dimensions, customers, vendors and assets.
- Exclusions: What remains in a legacy archive, where it can be accessed and who owns access.
- Comparison point: Cutoff date, time zone, posting status, report filters and extract identifier.
Choose a comparison point that both systems can reproduce. If the source remains operational after extraction, maintain a separate register of subsequent postings and settlements. Include those movements in a controlled final incremental load rather than silently replacing the original baseline.
Keep two baselines: the untouched source extract and the approved, transformed migration dataset. That lets reviewers distinguish an authorized mapping change from a missing record.
Also document how subledger loads and GL opening journals interact. Make the intended posting effect explicit so reviewers can check that opening control-account balances are represented once, not twice. Microsoft’s reconciliation guidance calls for both agreement with legacy balances and agreement between target subledgers and the ledger. (learn.microsoft.com)
2. Prepare a repeatable sandbox and cleanse with traceability
Use a migration test environment with the intended configuration, mappings, extensions and import packages. Microsoft recommends planning environment capacity, migration dependencies and responsibilities, and testing migration in both system integration testing and user acceptance testing environments. It also advises separating migration activity from other testing that it could disrupt. (learn.microsoft.com)
Before each rehearsal, confirm:
- Approved accounts, dimensions, calendars, currencies and posting configuration are present.
- Import operators and finance reviewers have the access their tasks require.
- External payment, email and integration outputs cannot reach live recipients unintentionally.
- The starting state is known, and the environment can be reset through an approved procedure.
- File versions, transformation rules, job identifiers and report parameters will be retained.
Cleanse data through recorded rules, not undocumented spreadsheet edits. Suggested checks include duplicate business identifiers, invalid account combinations, inconsistent dates, missing currencies and references to excluded master records.
Keep a crosswalk showing each legacy identifier and its target identifier. Where records are merged, split or excluded, record the reason and approval. Do not assume that one source row must always become one target row.
Assign cleansing decisions to business data owners. Microsoft’s governance guidance places responsibility for cleansing and standardization with the users most familiar with the data, supported by data stewardship policies. (learn.microsoft.com)
3. Track completeness from extraction through target posting
Treat migration as a chain of controls:
Source extract → transformed file → import staging → target records → posted balances
In Dynamics 365 finance and operations apps, the data management framework uses data entities and supports import/export projects, execution history and staging diagnostics. Import processing can proceed with valid records while failed records are corrected later. Therefore, an import that has progressed is not, by itself, evidence that the entire financial scope arrived. (learn.microsoft.com)
For every migration batch, record:
| Control | Practical check |
|---|---|
| Source completeness | Compare the extract to the approved source population |
| Transformation | Explain exclusions, merges, splits and changed values |
| Record counts | Distinguish documents, lines and generated accounting entries |
| Financial totals | Compare debits, credits and open amounts separately |
| Currency totals | Keep transaction-currency totals separate |
| Rejected records | Account for every failed or skipped record |
| Target status | Separate staged, imported, validated and posted records |
Calculate an expected target count from the documented transformation rules. Investigate both shortfalls and excess records.
For Dynamics 365 import failures, review View staging data and View execution log. Microsoft documents correction in staging or correction of the import file followed by reimport. If a staging correction is used during testing, capture the underlying fix in the repeatable migration process as well. (learn.microsoft.com)
4. Reconcile the trial balance, then AP and AR detail
Use three comparisons:
- Legacy financial reports to the approved migration dataset.
- Migration dataset to the target ERP.
- Target subledgers to target GL control accounts.
This follows Microsoft’s recommendation to reconcile migrated balances and open transactions to legacy systems and reconcile all subledgers to the ledger before new transactions begin. (learn.microsoft.com)
For the trial balance, compare each mapped account by legal entity and each required reporting dimension. Normalize debit/credit signs before calculating differences. Where accounts are combined, show the many-to-one mapping rather than comparing unlike account lists.
Check opening balances and period movements separately if both are in scope. A balanced target ledger is only one control; require account-level comparisons too.
For AP and AR, use a detail-level comparison containing:
- Customer or vendor identifier.
- Document identifier, document date and due date.
- Currency and remaining open amount.
- Credits, unapplied payments and partial settlements.
- Target control account and relevant dimensions.
Then compare aging buckets using identical report settings. Dynamics 365 customer and vendor aging reports allow different date criteria and include options affecting transaction details, negative balances, currencies and unsettled payments. The customer report also distinguishes the aging date from the balance cutoff date. Preserve these settings with the evidence. (learn.microsoft.com)
If the total agrees but aging differs, check dates, bucket definitions and settlement treatment before changing amounts.
5. Validate fixed assets and currencies independently
For each migrated asset and book, include acquisition cost, accumulated depreciation, other valuation movements and net book value in the reconciliation. Compare both individual assets and totals.
Dynamics 365’s fixed asset roll-forward report provides opening and closing balances, acquisitions, depreciation and other movements, with individual-asset, group and legal-entity reporting. Microsoft documents Electronic reporting configuration prerequisites, so verify those before the rehearsal. (learn.microsoft.com)
Also check operational fields: in-service dates, depreciation methods, useful lives, last depreciation dates and remaining depreciation settings. As an acceptance test, run the next depreciation calculation in the sandbox and have the asset accountant review its result.
For currencies, keep three comparisons distinct:
- Transaction currency: The document’s original currency.
- Accounting currency: The ledger’s accounting amount.
- Reporting currency: The additional ledger currency, where configured.
Dynamics 365 uses configured exchange-rate types to convert transaction amounts into accounting and reporting currencies. Check each currency layer separately rather than accepting agreement in only one. (learn.microsoft.com)
Record whether source balances include revaluation and how the migration preserves or recreates it. In Dynamics 365, AP/AR revaluation updates subledgers and posts a GL entry; Microsoft recommends a simulation before processing. Do not run revaluation merely to make an unexplained migration difference disappear. (learn.microsoft.com)
6. Build a reconciliation workbook with explicit acceptance rules
Use separate tabs for Scope, Mappings, Control totals, GL, AP, AR, Assets, Currencies, Exceptions and Sign-off.
For each control, retain the run ID, entity, cutoff, currency, source and target evidence references, difference, tolerance, status, owner and reviewer.
Worked example: a missing AP credit
The following figures are synthetic, for one hypothetical entity at one cutoff. Monetary amounts are USD. AP liabilities are displayed as positive amounts, with credits reducing the balance.
| Control | Source | Target | Target − source | Assessment |
|---|---|---|---|---|
| GL debits minus credits | 0 | 0 | 0 | Balanced only |
| Open AP document count | 120 | 119 | −1 | Fail |
| AP open balance | 84,000 | 85,200 | +1,200 | Fail |
| AP GL control balance | 84,000 | 85,200 | +1,200 | Fail against source |
| AR open balance | 210,000 | 210,000 | 0 | Amount passes |
| Asset acquisition cost | 300,000 | 300,000 | 0 | Amount passes |
| Accumulated depreciation | 90,000 | 90,000 | 0 | Amount passes |
Suppose the exception review identifies an omitted vendor credit of −$1,200:
Expected AP = $85,200 − $1,200 = $84,000.
The target AP subledger and GL agree with each other, but both disagree with the source. The document-count control exposes the incomplete population. Correct the rejection, use the tested reload procedure and repeat the affected reconciliations.
For a spreadsheet layout with source in column B and target in C, calculate the difference with =C2-B2. Keep monetary, count and date controls separate.
Proposed acceptance rules
Have the controller approve these before the final rehearsal:
| Control type | Suggested acceptance rule |
|---|---|
| In-scope records | No unexplained missing or duplicate records |
| GL and subledger balances | No unexplained monetary differences |
| Mandatory fields and mappings | No unresolved invalid values |
| Aging | No unexplained document or bucket differences |
| Rounding | Only evidenced differences within preapproved limits |
| Critical exceptions | None unresolved at release |
These are proposed project controls, not universal accounting or vendor requirements. If rounding tolerance is necessary, define both a per-item limit and an aggregate limit by entity and currency. Do not let opposite-sign differences cancel into a pass.
7. Assign exceptions and decide whether to rerun, defer or roll back
Give every exception a named owner, affected records, amount, root cause, proposed correction, deadline and retest evidence. Suggested ownership is AP/AR managers for open items, the asset accountant for assets, the controller for financial acceptance and the migration lead for repeatable technical corrections.
Before authorizing a rerun, ask:
- Is the cause isolated and corrected in the controlled process?
- Does the load insert, update or reject existing records?
- Can the affected batch be reset or reversed through a tested, supported method?
- Will dependent reconciliations be repeated?
- Is there enough time to finish and review before the decision deadline?
Defer release when critical differences remain unexplained, required reports cannot be produced or the remaining validation exceeds the agreed cutover window.
For a rollback decision, confirm the approved recovery point, restoration method, integration state and treatment of any transactions created since cutover. Do not assume that a sandbox reset procedure is available in production or that restoring the ERP reverses external payment or integration activity.
The final sign-off package should contain the approved scope, final extracts, mapping versions, execution logs, reconciliations, resolved exceptions and remaining accepted limitations. Require named finance and technical approval before opening transaction processing.
A zero difference is an important result. The release decision should also establish what was compared, what was excluded and whether the team can reproduce the evidence.