D365 F&O Data Migration: What Finance Must Own Before Go-Live -

The Finance-owned data migration workstreams that IT and the implementation partner cannot complete without Finance’s accounting knowledge, the accuracy validation procedures Finance must run before trusting any migrated data, the opening balance reconciliation Finance must complete before the first period closes, and the five data migration failures Finance discovers in reconciliations that should have been run on Day 1.

The Finance-vs-IT Data Migration Ownership Map

Finance and IT share the data migration workstream, but the boundary between their respective accountabilities is almost never clearly defined at the start of a migration project. Finance must claim its accountabilities explicitly—not wait for IT to hand them over. The following table maps the key migration workstreams by primary owner.

Data Migration Ownership—Finance vs. IT vs. Shared Accountability

The Finance Data Migration Validation Procedures

Finance Validation Procedures—Required Before Any Migrated Data Is Trusted

GL Trial Balance Reconciliation—Account by Account
- Finance exports the D365 F&O trial balance as of the cutover date and compares it account by account to the source system trial balance as of the same date. The comparison is at the individual account level, not at the category total level. A difference in a specific account—even if it is offset by an opposite difference in another account—is a migration error that requires investigation. Finance documents every reconciling item and its resolution before accepting the GL migration as complete. This reconciliation is Finance’s primary evidence that the D365 F&O GL correctly reflects the financial position as of go-live.
AR Subledger Validation—Invoice-Level and Customer-Level
- Finance runs the D365 F&O AR aging report as of the cutover date and compares it to the source system AR aging report for the same date. The comparison is at two levels: the total AR outstanding (must agree exactly) and the customer-level balance (a sample of 25 customers selected by Finance, comparing each customer’s outstanding balance and open invoice detail between the two systems). Any customer-level discrepancy is traced to the specific invoice that did not migrate correctly. Finance also confirms the migrated AR total agrees to the migrated GL AR control account balance.
AP Subledger Validation—Invoice-Level and Vendor-Level
- Finance runs the D365 F&O AP aging report as of the cutover date and compares it to the source system AP aging report for the same date, using the same two-level comparison: total AP outstanding and vendor-level balance for a sample of 25 vendors. Finance specifically tests partially-paid vendor invoices—invoices where a partial payment was made in the source system and only the remaining balance should appear in D365 F&O. These are the invoices most likely to migrate incorrectly because they require the migration to carry both the original invoice amount and the payment history. Finance also confirms the migrated AP total agrees to the migrated GL AP control account balance.
Fixed Asset Register Validation—Asset-Level and Category-Level
- Finance runs the D365 F&O fixed asset balance report as of the cutover date and compares the net book value by asset to the source system fixed asset register for the same date. Finance validates a sample of 20 assets, confirming for each: acquisition cost, acquisition date, depreciation method, useful life, accumulated depreciation to date, and net book value. Finance also confirms the total NBV by asset category in D365 F&O agrees to the migrated GL net asset accounts by category. Any asset where the depreciation calculation in D365 F&O does not match the source system is likely the result of a depreciation method or useful life configuration error that will produce wrong depreciation for the remaining life of the asset.
Vendor and Customer Master Accuracy Sample
- Finance selects a random sample of 25 vendors and 25 customers and compares the Finance-critical fields in D365 F&O against the source system and the original vendor/customer files: posting group, payment terms, bank account (vendors), currency, VAT registration, and credit limit (customers). Finance documents the sample selection, the fields compared, and the results. Any sample item with a discrepancy in a Finance-critical field is an error that must be corrected before go-live—not after. A posting group error in the vendor master propagates to every invoice posted for that vendor from Day 1.

Five Data Migration Failures Finance Discovers in Reconciliations That Should Have Run on Day 1

⚠️ GL Opening Balance Migration Validated by Total—Individual Account Errors Hidden for 14 Months

The D365 F&O implementation team validates the GL migration by confirming that the total of all migrated debit balances equals the total of all migrated credit balances—the trial balance is in balance. Individual account balances are not compared to the source system. Two accounts were migrated with transposed amounts: Prepaid Expenses was migrated with the balance that belongs to Accrued Liabilities, and Accrued Liabilities was migrated with the balance that belongs to Prepaid Expenses. Because both accounts carry a balance and the trial balance totals agree, the transposition is not detected by the total-only validation. For 14 months, the Prepaid Expenses balance sheet line shows the accrued liabilities figure and vice versa. A new CFO hired 14 months after go-live asks Finance to explain the Prepaid Expenses balance, which is dramatically higher than industry peers. Finance investigates and discovers the transposition during the investigation.

Fix: GL migration validation must be account by account, not total by total. Finance produces a reconciliation that has one row for every GL account, showing the source system balance, the D365 F&O migrated balance, and the difference. Every non-zero difference requires investigation before go-live acceptance. The account-level comparison for a 300-account COA takes two hours and is the control that catches transpositions, sign errors, and account mapping mistakes that total-only validation will never find. Finance signs the account-level reconciliation as the go-live acceptance evidence for the GL migration—without this sign-off, Finance has not actually validated the GL migration.

⚠️ Open Purchase Orders Not Migrated—Encumbrances Missing From Budget Control From Day 1

The implementation team migrates open AR invoices, open AP invoices, and the GL trial balance. Open purchase orders are not included in the migration scope because the implementation team classified them as operational data (IT’s responsibility) rather than financial data (Finance’s responsibility). Finance goes live with no historical purchase orders in D365 F&O. Two consequences emerge immediately: (1) when vendor invoices arrive for POs that existed before go-live, there is no PO to match against, so all pre-go-live PO invoices must be processed as non-PO invoices bypassing the three-way match; and (2) for organizations using budget control with encumbrances, the pre-go-live purchase orders represented committed appropriation that is now absent from D365 F&O’s budget availability calculation. Departments see inflated budget availability because their pre-go-live PO commitments are invisible to the system. Two departments proceed to make additional purchases against what appears to be available budget, unknowingly exceeding their appropriated amounts.

Fix: Open purchase orders as of the go-live date must be migrated if the organization uses PO-based three-way match, budget control with encumbrances, or vendor portal PO visibility. Finance identifies the scope of open PO migration during the implementation design phase and confirms with IT that the PO migration is included in the data migration scope. Finance validates the migrated open POs against the source system open PO report: total outstanding PO value should agree, and a sample of individual POs should be confirmed in D365 F&O with the correct vendor, status, quantity remaining, and line amounts. For budget control environments, Finance also confirms that the migrated POs have created encumbrances in D365 F&O and that the budget available calculation reflects the committed amounts.

⚠️ Customer AR Balance Migrated Without Invoice Detail—Collections Is Impossible and Audit Trail Is Missing

To simplify the AR migration, the implementation team migrates the AR opening balance as a single journal entry per customer: a debit to AR and a credit to an offset account, with the amount equal to the customer’s total outstanding balance as of the cutover date. No individual invoices are migrated. Finance goes live with AR balances that exist in D365 F&O but have no underlying invoice detail. The collections team cannot send customers a statement of specific overdue invoices because there are no invoices—only a balance. When the AR coordinator attempts to apply a customer payment, there is no invoice to apply it to. The payment must be applied to the balance entry, which does not age correctly. Customers dispute balances because Finance cannot provide an itemized invoice list. The auditor, reviewing AR, cannot trace the opening AR balance to specific invoices. Finance spent three months after go-live manually reconstructing invoice detail for the top 50 customers from paper records.

Fix: Open AR invoices must be migrated at the invoice level—each outstanding invoice as a separate transaction with the correct invoice date, due date, invoice number, and amount. The invoice-level migration is required for: the collections process (aging and prioritization by invoice), payment application (payments applied to specific invoices), audit evidence (auditor can trace AR balance to individual invoices), and cash flow forecasting (aging-based payment timing projections require invoice-level due dates). The invoice-level migration is more complex than a balance migration but is the only migration approach that produces a functional AR subledger. Finance validates the invoice-level migration by comparing the D365 F&O AR aging bucket totals (current, 1–30, 31–60, 61–90, 90+) to the source system AR aging for the same date—a balance-level migration will show all AR as current regardless of the actual age of the underlying invoices.

⚠️ Fixed Asset Depreciation Method Migrated Incorrectly—Depreciation Is Wrong for Every Asset From Day 1

The source system used straight-line depreciation for all fixed assets. The migration team maps the source system depreciation method to D365 F&O’s depreciation method configuration. The mapping uses “Straight line service life” in D365 F&O for all assets. However, D365 F&O has two straight-line methods: “Straight line service life” (which deprecates from the acquisition date over the useful life) and “Straight line remaining life” (which depreciates over the remaining life from the current date). For assets that have been partially depreciated, the two methods produce different monthly depreciation amounts. The migration team uses “Straight line remaining life” which calculates depreciation over the remaining life from the go-live date—not the total useful life from acquisition. For assets in their third year of a five-year life, the monthly depreciation increases from what it should be, because D365 F&O is depreciating the remaining NBV over two years instead of recognizing that two of the five years have already been served.

Fix: Finance validates the depreciation calculation for a sample of fixed assets immediately after the asset migration is complete and before go-live. The validation procedure: for each sampled asset, Finance calculates the expected monthly depreciation using the source system method (monthly depreciation = (acquisition cost − accumulated depreciation − residual value) divided by remaining useful life months), then runs a D365 F&O depreciation proposal for the first go-live month and confirms the D365 F&O calculation matches the expected amount. Any discrepancy in the calculation method is a configuration error that must be corrected before go-live. Finance also confirms the migrated accumulated depreciation agrees to the source system value for the same sample assets.

⚠️ Migration Cutover Date Different From GL Balance Date—A Period of Transactions Is in Neither System

The organization’s source system produces a trial balance as of month-end (December 31). The D365 F&O go-live is January 15—15 days into the new month. The implementation team uses the December 31 trial balance as the GL opening balance in D365 F&O. January 1–14 transactions (invoices posted in the source system, payments received, journals posted) are not migrated to D365 F&O because no one specifically identified the January 1–14 period as a migration gap. When Finance tries to run the January 2025 financial statements, the first two weeks of January are missing: 15 days of sales invoices, vendor payments, and customer receipts exist only in the source system and not in D365 F&O. Finance must manually enter all January 1–14 transactions into D365 F&O to make the January financial statements complete. The manual re-entry takes four days and introduces several data entry errors that are discovered during the February close.

Fix: The migration strategy must explicitly address the period between the last extracted balance date and the go-live date. Finance defines a migration cutover date that minimizes the unmitigated period: ideally, go-live on the first business day of a new period (month or quarter), using the prior period-end trial balance as the opening position. If go-live must occur mid-period, Finance defines the migration approach for the mid-period gap: either delay go-live to the start of the next period, run the first partial period in both systems in parallel and reconcile, or migrate the mid-period transactions as part of the data migration load. Whatever approach is chosen, Finance documents it explicitly before the migration begins and confirms the approach is accounted for in the reconciliation methodology. The migration gap is the most common source of opening balance discrepancies in D365 F&O implementations and is entirely avoidable with explicit planning.

Do This / Don’t Do This

Do This

Validate the GL migration account by account—not total by total—and document every reconciling item before go-live acceptance
Migrate open AR invoices at the invoice level with correct due dates—not as a single balance entry per customer
Validate fixed asset depreciation calculations for a sample of assets before go-live by comparing D365 F&O proposals to manually calculated expected amounts
Include open purchase orders in the migration scope if the organization uses three-way match, budget control with encumbrances, or vendor portal PO visibility
Explicitly plan and document the migration strategy for the period between the last extracted balance date and go-live
Run AR and AP subledger reconciliations as the first procedure after each migration load to confirm subledger totals agree to GL control accounts

Don’t Do This

Accept IT’s technical completeness validation as Finance’s financial accuracy validation—they answer different questions
Migrate AR opening balances as single summary entries per customer without invoice-level detail
Skip fixed asset depreciation method validation—a wrong method compounds for the remaining useful life of every affected asset
Assume open purchase orders are operational data that IT will handle without Finance involvement
Allow the period between the balance extraction date and go-live to go unaddressed in the migration plan
Sign off on the data migration based on total count of migrated records rather than financial accuracy of migrated balances

What’s Next in the Series

Data migration accuracy is the foundation that everything post-go-live builds on. The series continues with Finance topics that apply across D365 F&O’s operational life: Finance-Led Process Design—Why Configuration Without Process Documentation Creates Technical Debt—how Finance organizations that document their Finance processes alongside D365 F&O configuration reduce close time, reduce audit findings, and reduce staff turnover risk; the process documentation Finance must produce and maintain; and the five process documentation failures that leave Finance organizations dependent on tribal knowledge that exists only in the Controller’s memory.

— Bobbi

D365 Functional Architect · Recovering Controller

Thank you for reading!

If this post helped you solve a real problem, share it with a Finance colleague who is in the middle of an ERP implementation or a post-go-live optimization. If you have a topic that I haven’t covered, please reach out. This platform is always evolving, and there is one more subject worth exploring.

If you are interested in learning more, below are some of my latest posts:

D365 F&O Data Migration: What Finance Must Own Before Go-Live