Everything this blog has covered, distilled into what Finance most needs to hear in the first week of a BC implementation—from the perspective of someone who has seen every mistake in this series made by smart, capable Finance teams who were given the wrong information or not given enough information at the right moment.
Dear Controller,
You just signed the contract. The implementation partner has scheduled the kickoff meeting. Someone from IT is configuring the project environment. There are workshops on the calendar for next week, and the week after, and most weeks between now and the go-live date. The implementation is underway.
I want to talk to you before the workshops start, because the decisions that will matter most for Finance’s experience with BC over the next five years are being made in the next four weeks, and the way most implementations are structured, Finance is not fully engaged in those weeks. You are finishing a quarter-end. Your CFO wants a budget update. The partner is moving fast because the project timeline is fixed. And the foundational decisions about how BC is configured for Finance are being made by people who know BC but do not know your Finance operation the way you do.
Here is what I want you to know.
The Chart of Accounts Is an Accounting Policy Decision, Not a Data Migration Task
Someone is going to suggest—probably in the first or second week—migrating your existing chart of accounts into BC. It will be framed as the practical choice: it’s what the team knows, it’s what the auditors are familiar with, and redesigning it would take time you don’t have. The argument is reasonable. It is also wrong, at least partially.
BC’s financial dimension architecture changes what a well-designed COA looks like. In your prior system, you may have embedded cost center codes in your account numbers because the system had no separate dimension structure. In BC, financial dimensions carry that analytical information and your main accounts can be cleaner. The COA you migrate may carry 300 accounts where 150 accounts plus dimensions would produce better management reporting, less trial balance complexity, and fewer reconciliation exceptions.
You do not need to redesign the COA from scratch. You need to evaluate it deliberately against what you need BC to produce for Finance. Spend three hours with your implementation partner answering this question: for every management report I produce today and every management report I want to be able to produce in BC, what account and dimension structure do I need? If the current COA answers that question, migrate it. If it doesn’t, now is the time to change it. You will not get another cost-effective opportunity to restructure the COA for years.
Block the Fit-Gap Workshops on Your Calendar
The fit-gap workshops are where BC’s capabilities are mapped to your organization’s requirements. The implementation partner facilitates them. Your team describes what you do. The partner proposes how BC will handle it. Decisions are made about posting profiles, dimension structure, approval workflows, and the close process—decisions that become the configuration Finance lives with for the life of the implementation.
Finance leadership is present for the Finance sessions. Not your Finance analyst with a notebook. You. The Controller’s institutional knowledge of how the close works, which reconciliations are critical, where the auditors focused last year, and what the CFO actually wants to see in the management pack—that knowledge cannot be delegated to a junior team member in a workshop that the partner will not revisit.
Block the Finance module fit-gap sessions on your calendar before the kickoff meeting. This is the highest-leverage investment of your time in the entire project.
The Implementation Scope Defines Your Starting Point—You Define What Done Means
The implementation scope was written by the implementation partner based on a discovery conversation that happened before the contract was signed. It covers what they know how to build. It does not automatically include everything Finance needs to operate effectively from day one.
Review the scope document and ask yourself: when this scope is delivered, will Finance be able to close the first period correctly? Will the management report package be producible from BC without Excel intermediate steps? Will the purchase invoice approval workflow be configured and tested? Will the vendor master approval workflow exist? Will the period-close checklist be documented?
If the answer to any of those questions is no, you have a choice: add it to scope now, with budget, or define a post-go-live plan with a named owner, a deadline, and a definition of done. “Finance will get to it post-go-live” is only acceptable if there is a specific date and a specific person responsible. Without both, post-go-live items become permanent deferrals.
Test the Close Before You Go Live
Most BC implementations test transactions in UAT: create a sales order, post an invoice, enter a payment. Very few test the close sequence end-to-end. Finance goes live having tested individual transactions but not the experience of sitting down on close day one and working through the full sequence in a live environment.
Ask the implementation partner to include a full close simulation in the UAT scope. Run a complete period in the test environment: post all transaction types, run the bank reconciliation import, run the depreciation batch, post accruals, run the Management Reporter income statement. Every step that fails or produces unexpected output in UAT is a problem you found before go-live. Every step you discover for the first time during a live close costs you the time pressure of a live close on top of the investigation time.
Data Migration Accuracy Is Finance’s Responsibility to Validate
The data migration will confirm that 847 customers migrated, 1,240 vendors migrated, and the trial balance total migrated. What it will not automatically confirm is that each customer’s posting group, payment terms, and credit limit migrated correctly, or that each vendor’s bank account number was transcribed without error.
Finance validates the accuracy of migrated Finance data, not just its completeness. Pull 25 vendor records and compare each Finance-critical field against the source. Pull 25 customer records and do the same. Reconcile each GL opening balance account by account. Run the AR aging and AP aging in BC and compare customer-level and vendor-level balances to the same reports from the prior system as of the migration date.
A posting group error discovered during data migration validation is a 30-minute fix. The same error discovered six months after go-live is a 14-month retroactive correction with a conversation to have with your auditor.
The Implementation Partner Is the BC Expert. You Are the Finance Expert.
Your implementation partner knows BC well. They have configured it many times, for many organizations, in many industries. What they do not have is your specific knowledge: how your close process actually runs on the days it is under pressure, which reconciliation consistently produces surprises and why, what the CFO looks for in the management pack that is not obvious from a requirements document, and what went wrong in your Finance operation last year that you want BC to prevent going forward.
The best implementations are collaborations, not delegations. Finance provides the operational knowledge and the requirements. The partner provides the BC architecture and the configuration expertise. When Finance delegates the requirements-gathering to a junior team member and approves the configuration without reviewing it, Finance gets a BC environment that is technically correct but operationally incomplete.
You are the expert on your Finance function. Bring that expertise to the project from day one.
BC Is a Platform You Will Grow Into—Plan for That
You will not use everything BC offers on day one. The cash flow forecast module will wait. Invoice Capture will wait. Finance Insights will wait until the training data is there. That is fine. The platform has more capability than any Finance team uses fully in the first year.
What you should plan for is a Finance adoption roadmap: a rolling 12-month view of which BC capabilities Finance intends to enable next, based on the operational impact each capability would have for the Finance function. The Controller who reviews this roadmap quarterly and moves items forward is the Controller who, three years from now, is running Finance on a mature platform rather than still working around the same gaps that existed at go-live.
BC is not a system you implement and then use. It is a platform you implement and then build. The building continues for the life of the platform. Finance should plan for it that way.
One More Thing
This blog has centered on Finance’s relationship with Business Central. Every post was written for the Controller who wants to understand BC deeply enough to configure it well, maintain it correctly, and demand more from it as the organization grows. Every mistake documented in this series was a real mistake made by a real Finance team. Every fix was something that Finance could have done differently with more information at the right moment.
The information is now available to you, in this series, before you make the decisions that determine whether your BC implementation produces the Finance platform your organization deserves.
Use it well.
Bobbi
D365 Functional Architect · Recovering Controller
Thank You for Reading
If a post helped you solve a real problem, share it with a Finance colleague who is in the middle of a BC implementation or a post-go-live optimization. If you have a topic that I haven’t covered, please reach out. There is always one more post worth writing.
Leave a Reply