Well, the time finally came to go-live with my implementation of Dynamics 365 Business Central. You may have assumed that’s what was happening if you looked at any of my other posts (like this one). Unless you’re a consultant, going live with any new finance system or ERP is something that ideally doesn’t happen a ton. Since this is so uncommon, it seems to me that there should be some details provided from Microsoft on how this would practically work when coming from another system. Here’s a little bit of how I worked through it. DISCLAIMER – there’s about 100 other ways to do this and probably at least 99 of them are better than the way I did.
Overview
There are a few steps, generally, when going live in a new ERP. 1. pick a timeframe and schedule a go-live, 2. get your data from whatever your source system is, and 3. post your opening balances.
Pick a timeframe and schedule a go-live
Proper selection of a go-live date will allow you to easily transition from your legacy system to BC. Transactions that need to post in your GL with a posting date before the go-live date will be posted in your legacy system and transactions with a posting date on or after your go-live date will be posted in BC. Depending on how long your month-end or year-end close process is, you’ll likely be doing transactions in both systems for a few days after the go-live date. It’s important that all your users understand which transactions should post in which system. If possible, stopping future periods in your legacy system will reduce the opportunity for errors.
What did I do?
In my case, I chose the end of the first half of the year, 6/30. All month-end transactions for June are happening in the legacy system, but all new transactions July 1st and later will happen in BC.
Get your data from whatever your source system is, prepare BC, and post your opening balances
There are two main types of data that needs to be migrated during a go-live; subledger and general ledger. If you have open subledger documents (like posted AR invoices or open work orders which picking has already happened), you’ll need to account for those so that you don’t double-post into your control accounts.
What did I do?
I started with the general ledger. To make sure I was able to report on 2024’s GL data at a summary level in a single system, I wanted to bring opening balances of the GL accounts as of 1/1/24 and then summarized net activity for the first 6 months of 2024. I did this by extracting 6 trial balance reports from my legacy system (one for the net activity of each month) and then used the Edit in Excel function to create general journals. I did this one month at a time, and reviewed and posted the journal prior to importing the next month.
As you can see in the screenshot above, the journal entry can be super simple – there are only like 6 fields that are required, and the line number is automatically generated. I took my CSV of my monthly activity, copied whole columns at a time, and then pasted in the values as needed. Once I had the file populated, I hit the publish button and pushed a whole month into a single entry. Once the entry is published from Excel to BC, I then reviewed the entry in BC, checked to ensure the accounts were being affected as desired, and then posted.
When you do this, you’ll need to ensure that you have all your ledger accounts in BC that you had activity in for the last 6 months. Lots of times, people will try to clear up their accounts prior to a go-live, but then will realize they had activity in some of these old accounts and will need to re-create them. If it really bothers you that much, do the opening entry and then block the account so that no one can use it anymore.
I repeated this for each month of 2024 up until the end of May (June is still being closed; I’ll do that entry in a few weeks). I then ran a YTD trial balance in both systems to compare them to make sure I did everything right. I hadn’t – I used April’s numbers twice and the trial balances didn’t match. I reversed the erroneous May entry and then reposted it with the correct numbers. Ran the trial balances again, and everything worked.
Next, I had to deal with the subledger. Generally, the approach is to recreate any transactions that are still open at the time of go-live so they can be paid or dealt with in the new system. I had only a few invoices, so I was able to manually enter them in BC at cutover. I opened my legacy system on one screen, opened BC on the other, and started keying.
Based on my simplistic approach for my ledger balances, my open AP, AR, and bank balances were already included in the entries I already created. To make sure I didn’t double count the open transaction amounts in the GL when I was recreating the subledger, I used a little trick. When posting open AR invoices, I used a “ledger account” line and then specified the account to be my control account. This was the debit and credit cancel each other out, and then sales account isn’t affected.
If you look at the posting preview, you’ll see that the GL is unaffected as the debit and credit go to the same account.
Although each of the invoices had a number of lines on them, I just needed to get the invoice totals entered and the customer balance to be correct, so I only used a single line.
There’s another way to do this. You can create an offset account used just for data migration. You can use this account as the offset both when you post the GL entries and also when you post the open invoices. This would allow you to doublecheck that the GL and subledger amounts tie out, as the balance of that offset account should equal zero. It’s more complicated, though, and I didn’t feel like the extra check.
The same approach is done for the bank accounts and the AP accounts, just in slightly different ways. For AP and bank accounts, I just used a general journal and offset the subledger with the control account that links the GL to the subledger.
After you’re done with these transactions and everything has been posted, there should be no net activity in your GL accounts. You can use AR / AP aging reports to compare your data to make sure everything is correct.
Things to be aware of
Dates. You want to think through both when you want these things to post and what you’re going to use in the system for payments and such. If you want to post the open transactions back in the appropriate posting dates, go right ahead, just make sure the document date matches the invoice date so that the due dates can calculate correctly. This will make it easier to reconcile, as you can use the AR and AP aging reports from both systems to make sure everything came in right.
Master / setup data. Like I mentioned above, you’ll want to make sure you have the master data records to handle the open transactions you’re doing. If you’ve been in business for a while you might have some open AP or AR invoices that should be closed out or are from companies that no longer exist. Either close those transactions out in your legacy system prior to cut-over, or make sure you have a customer / vendor record to handle those transactions. If you don’t, your Edit in Excel publishing will fail and you’ll have to create them during cut-over.
More help. There are some great videos from Sune Lohse (here) that walk through each of the different types of transactions, but I still thought there was some value in providing my own thoughts. He has videos that walk-through inventory, too.
Hope this helps.
Leave a Reply Cancel reply