BC Data Migration: What Finance Must Validate Before Go-Live -

The Finance-owned data migration workstreams that IT cannot complete without Finance’s accounting knowledge, the accuracy validation procedures Finance must run before trusting any migrated data, the opening balance reconciliation that must be complete before the first live transaction posts, 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 must claim its migration accountabilities explicitly rather than waiting for IT to hand them over. The table below maps the key BC migration workstreams by primary owner.

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

The Five Finance Data Migration Validation Procedures

Finance Validation Procedures—Required Before Any Migrated Data Is Trusted

GL Trial Balance Reconciliation—Account by Account, Not Total by Total
- Finance exports the BC trial balance as of the opening 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. A difference in a specific account—even if offset by an opposite difference in another account—is a migration error requiring investigation. Finance documents every reconciling item and its resolution before signing off on the GL migration. This reconciliation is Finance’s primary evidence that BC correctly reflects the financial position as of go-live.
Customer Ledger Validation—Invoice-Level and Customer-Level
- Finance runs the BC Customer Aging report as of the opening date and compares it to the source system AR aging for the same date at two levels: total AR outstanding (must agree exactly) and customer-level balance for a sample of 20–25 customers (comparing each customer’s outstanding balance and open invoice detail). Finance also confirms the migrated AR total agrees to the migrated GL AR control account balance. Any customer-level discrepancy is traced to the specific invoice that migrated incorrectly.
Vendor Ledger Validation—Invoice-Level and Vendor-Level
- Finance runs the BC Vendor Aging report as of the opening date and compares it to the source system AP aging using the same two-level approach: total AP outstanding and vendor-level balance for a sample of 20–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 BC. 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 correctly.
Fixed Asset Register Validation—Asset-Level and Category-Level
- Finance runs the BC Fixed Asset projected value report as of the opening date and compares net book value by asset to the source system fixed asset register for the same date. Finance validates a sample of 15–20 assets, confirming for each: acquisition cost, acquisition date, depreciation method, useful life (original, not remaining), accumulated depreciation to date, and net book value. Finance also confirms total NBV by asset category in BC agrees to the migrated GL net asset accounts by category. Any asset where BC’s depreciation calculation does not match the source system is a depreciation configuration error that will produce wrong depreciation for the remaining life of the asset.
Customer and Vendor Master Accuracy Sample
- Finance selects a random sample of 20 customers and 20 vendors and compares the Finance-critical fields in BC to the source system and original master data files. For customers: Customer Posting Group, Payment Terms, Credit Limit, Currency Code, VAT Registration Number. For vendors: Vendor Posting Group, Payment Terms, Bank Account Number, Currency Code, Gen. Bus. Posting Group, VAT Bus. Posting Group. Any sample record with a discrepancy in a Finance-critical field is an error that must be corrected before go-live. A Vendor Posting Group error on a vendor master record 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 Migration Validated by Total Balance Only—Account Transpositions Hidden for 11 Months

The implementation team validates the GL migration by confirming the total of all debits equals the total of all credits. The trial balance is in balance. Two accounts were migrated with transposed amounts: Prepaid Expenses carries the Accrued Liabilities balance and Accrued Liabilities carries the Prepaid Expenses balance. Because both accounts carry a balance and the trial balance totals agree, the transposition is undetected. For 11 months, the balance sheet shows Prepaid Expenses and Accrued Liabilities at incorrect values. A new Controller hired 11 months post-go-live investigates an unusually high Accrued Liabilities balance and discovers the transposition during the investigation. Restating 11 months of balance sheets is required.

Fix: GL migration validation must be account by account, not total by total. Finance produces a reconciliation with one row per GL account showing the source system balance, the BC migrated balance, and the difference. Every non-zero difference requires investigation before go-live acceptance. The account-level comparison for a 200-account COA takes 90 minutes and catches transpositions, sign errors, and account mapping mistakes that total-only validation misses entirely.

⚠️ Customer AR Migrated as a Single Balance Entry per Customer—Collections and Payment Application Both Break

To simplify AR migration, the implementation team migrates the AR opening balance as one journal entry per customer: a debit to AR and a credit to an offset account for each customer’s total outstanding balance. No individual invoices are migrated. Finance goes live with AR balances that exist in BC but have no underlying invoice detail. The collections coordinator cannot send customers a statement of specific overdue invoices because there are no invoices—only a balance. When a customer payment arrives, there is no invoice to apply it to. The payment must be applied to the balance entry, which does not age correctly. Finance spends two months after go-live manually reconstructing invoice detail for the top 30 customers from the source system and paper files.

Fix: Customer open invoices must be migrated at the invoice level—each outstanding invoice as a separate Customer Ledger Entry with the correct customer, invoice date, due date, invoice number, and remaining amount. The invoice-level migration is required for: the collections process (aging and prioritization), payment application (payments applied to specific invoices), aged debtor analysis (correct aging bucket assignment based on due date), and cash flow forecasting (payment timing projections require invoice-level due dates). Finance validates the invoice-level migration by comparing BC AR aging bucket totals to the source system aging for the same date—a balance-level migration will show all AR as current regardless of actual invoice age.

⚠️ Vendor Posting Group Migrated Incorrectly for 15 Vendors—15 Months of AP Posting to the Wrong Account

The source system’s vendor classification maps to BC’s Vendor Posting Groups during migration. The mapping for a category of 15 intercompany vendors is incorrectly configured—the intercompany vendor posting group maps to the standard trade creditors GL account instead of the intercompany payables GL account. For 15 months after go-live, every invoice from 15 intercompany vendors posts AP to the trade creditors account instead of the intercompany payables account. The intercompany payables GL account shows zero when it should carry material balances. The trade creditors account is inflated by the intercompany amounts. Finance discovers the error when preparing the intercompany reconciliation for the group consolidation and finding no intercompany payables in BC for any entity.

Fix: Finance validates the Vendor Posting Group assignment for a sample of vendors from each posting group category before go-live. The validation confirms: the posting group assigned in BC is the correct group for that vendor category, and the GL account mapped to that posting group is the correct payables account for that vendor type. Finance also posts a test vendor invoice in sandbox for each posting group and traces the resulting GL entries to confirm the payables account is correct. A 15-minute posting group validation test in sandbox prevents 15 months of incorrect AP account mapping in production.

⚠️ Fixed Asset Useful Life Entered as Remaining Life—Depreciation Accelerates for All Migrated Assets

The fixed asset migration loads each asset with its remaining useful life rather than its original useful life. BC’s depreciation calculation for straight-line assets uses the life entered in the Depreciation Book to divide the net book value into equal period amounts. For an asset that is halfway through a 10-year life, the source system shows 5 years remaining. The migration enters 5 as the useful life. BC divides the current NBV by 5 years and depreciates it over 5 years—correctly. But for an asset that is in year 1 of a 10-year life, the source system shows 9 years remaining. The migration enters 9 as the useful life. BC depreciates it over 9 years instead of 10—10% faster than the correct rate for the first year. The error affects every migrated asset and produces cumulative depreciation overstatement that compounds over the remaining life of the entire migrated asset register.

Fix: For straight-line depreciation assets, Finance enters the original total useful life in BC’s Depreciation Book, along with the Depreciation Start Date equal to the asset’s original placed-in-service date and the accumulated depreciation to date. BC uses the original life and the start date to calculate the depreciation schedule from the beginning, correctly calculating both the historical accumulated depreciation and the future period depreciation. Finance validates this approach in sandbox by entering a test asset with a known history and confirming BC calculates the same accumulated depreciation as the source system for the period through the migration date, and the same future period depreciation as the source system going forward.

⚠️ Migration Cutover Date Different From GL Balance Date—Twelve Days of Transactions in Neither System

The source system produces a trial balance as of March 31. BC go-live is April 12. The implementation team uses the March 31 trial balance as BC’s opening balance. April 1–11 transactions—invoices posted, payments received, journals posted in the source system—are not migrated to BC because nobody identified the April 1–11 gap as a migration scope item. When Finance tries to produce April financial statements from BC, the first 12 days of April are missing. Twelve days of sales invoices, vendor payments, and customer receipts exist only in the source system. Finance must manually re-enter all April 1–11 transactions into BC to complete the April financial statements. The manual re-entry takes three days and introduces several entry errors that are discovered during the May close.

Fix: The migration strategy must explicitly address the period between the last extracted balance date and the go-live date. The cleanest approach: 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 before the migration begins: either delay go-live to the start of the next period, run the first partial period in both systems and reconcile, or migrate mid-period transactions as part of the data migration load. Finance documents the chosen approach and confirms it is accounted for in the opening balance reconciliation methodology.

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 sign-off
Migrate customer open invoices at the invoice level with correct due dates, not as a single balance entry per customer
Validate Vendor Posting Group assignments by posting a test invoice in sandbox for each posting group and tracing the GL entries
Enter fixed asset original useful life (not remaining life) in BC’s Depreciation Book and validate the depreciation calculation in sandbox before go-live
Explicitly plan and document the migration strategy for the period between the balance extraction date and go-live
Run AR and AP subledger reconciliations as the first validation 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 the Vendor Posting Group sample validation—a wrong mapping propagates to every invoice posted for every vendor in that group from Day 1
Enter remaining useful life instead of original useful life in BC’s Depreciation Book for migrated assets
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 record count alone without financial accuracy verification

Up Next:

Data migration accuracy is the foundation everything post-go-live builds on. The series continues with the Finance topics that apply across BC’s operational life for project-based businesses: Project Accounting in BC—What Finance Must Own When Operations Runs the Projects—how BC’s Jobs module handles cost accumulation, billing, and revenue recognition for professional services and project-based Finance teams, the configuration Finance must own even when the project manager controls day-to-day project activity, and the five project accounting failures that produce margin surprises Finance discovers when a job closes and the final result is not what anyone expected.

— Bobbi

D365 Functional Architect · Recovering Controller

If a post helped you solve a real problem, share it with a Finance colleague who is in the middle of an implementation or a post-go-live optimization. If you have a topic the blog series did not cover, reach out. There is always one more post worth exploring.

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

BC Data Migration: What Finance Must Validate Before Go-Live