beginning balance Archives - Confessions of a Dynamics 365 Business Central Consultant

How to Enter Beginning Bank Balance for Dynamics 365 Business Central v18 and Above

Overview

On Dynamics 365 Business Central release 18, Microsoft made significant changes to the bank reconciliation features. Most of the articles and videos on entering beginning bank balances are still based on the older versions Dynamics 365 Business Central or Dynamics NAV.

Just thought I would share with the community on setting up your beginning bank balances if you’re moving to Business Central from your legacy accounting /ERP software

The goal is to have your bank balance match your G/L account. Just posting whatever is in your G/L to your bank is not the way to go and you’ll run into trouble later in future reconciliations.

Do it right initially will save you tons of trouble later.

Here are the steps to enter the beginning balances of your bank when you’re migrating from your legacy ERP/accounting software to Dynamics 365 Business Central.

What You Need

As with anything, preparation is key. There are a few things you need before entering your beginning bank balance.

Assuming you’re going live with Business Central on December 1st, they are:

Previous bank reconciliation before you go live. For example, if you plan to go live on December 1st, you’ll need the bank statement from November 30th.
A list of outstanding checks and transactions not cleared by the bank up to November 30th
Your reconciled G/L bank balance from your old legacy system. This means you need to do one last bank reconciliation from your legacy system up to November 30th

How do you know if you have everything put ready? Here’s a simple formula:

Your G/L balance for your cash/bank account as of November 30th
+/- Outstanding bank transactions that’s not been cleared
= Amount on the Bank Statement as of November 30th

For example:

G/L Balance as of 11/30 = 10,000
Outstanding uncleared checks and deposits as of 11/30 = 2,000
The bank statement that you got from the bank on 11/30 should be 12,000.

If the above formula is not true, do not proceed! Get it right so it can save you headaches down the road.

How This is Going to Work

Once you post the entries via General Journal (make sure the Account Type is Bank Account), run your first bank reconciliation as November 30th, or the period before you go live.

When you run your bank reconciliation for November 30th, manually enter the previous bank statement total in the Bank Statement Line section. DO NOT run the bank feed import for this period as nothing you import can be reconciled against.

Click on Matching -> Match Manually to match the entry that you’ve made for the Beginning Bank G/L Balance entry.

Once the matching is done for the beginning entry, you can post the reconciliation.

For your bank reconciliation for the following period, all of the unreconciled transactions will display for you to clear against.

Conclusion

Now you may be asking “But wait Alex, we won’t get your bank statement until a few days after we go live!”

That’s okay!

You don’t need your bank beginning balances as soon as you go live. We typically get the bank beginning balances (and other non-operation related balances) setup about a week after go live.

Entering Beginning Bank Balance for Dynamics NAV (Navision) for a New Implementation

During a new implementation of Dynamics NAV (Navision), most Dynamics NAV (Navision) consultants understand how to load in A/R and A/P beginning balances. However, when it comes to bank beginning balance. The subject is usually more murky. On one hand, you need to put in the bank balance so it shows up on the bank ledger, on the other hand, if you put in just a lump sum, doing the first bank reconciliation will be a nightmare.

The goal when entering a beginning bank balance, is to update the bank ledger to ensure the amounts are correct. In addition, the bank transactions that are not cleared needs to be come up so it can be properly reconciled.

In this example, we’re going to assume the Navision client is going live on 1/1/2010.

Here’s the information we need from the client:
1. The G/L bank ending balance as of 12/31/2009
2. The last bank statement (from the bank obviously) on 12/31/09
3. The beginning G/L balance

First of all, the Dynamics NAV (Navision) client or the consultant needs to itemize what checks are outstanding (not cleared yet as of the 12/31/09 bank statement).

We all know that to load in beginning G/L balance, we use the General Journal. We typically use loading of beginning balance as the same step as we load in the bank balance.

Let’s say the Dynamics NAV (Navision) client has the following:
Bank Balance on 12/31/09: $10,000.00
Outstanding Check #123: -$2,500.00
Outstanding Check #124: -$500.00
Deposit on Hold: $1,000.00

While we load in the beginning balance, we set the Account Type as Bank Account. Doing this will automatically update the bank ledger and the G/L ledger based on your Bank Account Posting Group.

So your beginning G/L balance would look like the following:

Beginning Entry for Bank Balance for Dynamics NAV

Assuming you received a bank statement on 1/31/2010. There were no transactions that were cleared and no additional transaction made to the bank. Your bank rec would look like the following:

Doing so, the transactions will match exactly to the bank statement and to the G/L.

In conclusion, you can say that the bank beginning balance is the Bank Balance + Outstanding Checks – Deposits on hold.

Entering Beginning Inventory Balance

When moving from a legacy system into Dynamics NAV (Navision), one of the areas you want to try and avoid is messing with the inventory G/L accounts. Most systems are usually pretty good with open A/R and A/P accounts, they can be transferred using the “posting back to the same account” technique that most implementers do. The beginning A/R and A/P G/L accounts would be based on your entry on the General Journal. This is assuming that the A/R and A/P aging reports matches the G/L.

Inventory valuation is one of the areas where we find the most discripencies based on what is entered on the Item Journal from the physical count and the inventory valuation report from the legacy system. Depending on your requirements, sometimes it doesn’t make sense to go through line by line on the item journal to see where the differences are.

A rule of thumb I always go by is to let Navision determine what the inventory value should be in the G/L based on the positive adjustments posted from the Item Journal.

To accomplish this, do the following:

Suppose you have the following G/L accounts:
11000 – Inventory
58850 – Inventory Adjustment

When posting a positive adjustment in the Item journal, it will post a debit to Inventory and credit to Inventory Adjustment.

When you’re ready to enter your beginning G/L balance, enter the G/L balance for Inventory to account 58850. This way, the difference between the inventory G/L balance from the legacy system and Navision will be reflected on account 58850.

If you do not want to reflect the adjustment in the current period due to financial reporting reasons, you can adjust the difference into an asset account. We usually recommend create a separate account (i.e. 11100 – Inventory Suspense) to store this difference until you can depreciate it.

By not posting any general journal entries to the inventory accounts, you’ve ensured that inventory valuation reports will ALWAYS match G/L, making everyone happy in the process.