Microsoft Dynamics GP documentation has a new home!

Microsoft Dynamics GP documentation has a new home!

I have mixed feelings about this. I really feel like vendors should document their products. There can be nuances that are not well described when users create documentation. But the reality of the world we live in means that you can now help keep up the documentation for GP.

It’s put your money where your mouth is time. If you want better documentation, you can build it.


GP Controller Series: Providing Consistency with Dates

One of the most common causes for transaction problems in GP revolves around dates, especially posting dates. Users simply post transactions into the wrong period.  Keeping periods closed when not in use is helpful, however, there is always a time around month end where two periods are open. Date management in GP is just complicated enough that keeping dates straight requires a mix of setup, process, and training.

In GP, most subledger transactions can be posted at the transaction level or as a batch of transactions. A few transaction types, mostly banking related, can only post per transaction.

If batch posting is available, use batch posting. In many cases transaction posting ignores posting settings and doesn’t post through the GL, meaning it has to be posted twice, once in the subledger and once in the GL. Obviously, this is less than ideal. Additionally, posting via batch typically uses a single batch for the date making it easier to validate.

Most subledger transactions have two dates, a transaction date, and a posting date. In AP, for example, the transaction date (technically document date in AP) on a voucher is the date of the vendor’s invoice. This is used to age the invoice properly, regardless of when it arrived. For transaction posting, the posting date defaults to the document data and that’s typically not the appropriate date. The actual posting date is hidden behind an expansion button (blue arrow) where users often don’t see this setting to change the posting date. With subledger batch posting, the posting date is assigned at the batch level and applied to all transactions in that batch.

It is important to note that for GL transactions, the transaction date is always the posting date. There is no date on journal entry batches.

The keys to managing dates in GP are:

  1. Post by batch where ever possible.
  2. Disable transaction posting for items using batch posting to prevent rogue transactions.
  3. Train people to double check posting dates for transaction posted items.
  4. Review transaction or batch dates prior to posting.

Links to all the posts in this series can be found at

Summit 2018, now with more community.

We hear community preached a lot around GP, AX/D365FO, NAV/D365BC, etc., but it felt like it was really on display at Summit 2018. Each of the groups had a space uniquely it’s own making it easy for users with common interests to congregate during the day.

It’s easy to be overwhelmed at Summit, especially if you are there alone as the only representative of your company. It ’s tough to split time when there are conflicting sessions. It’s easy to be unmotivated to go out in the evenings. Even if you come with others from your organization, sometimes you don’t want to spend all day and night with them. 

That’s why it was cool to see the Orlando GPUG group hanging out together at a party. This is a group that has gotten to know each other at events throughout the year and now they know each other well enough to have some fun together. It was great that they had picked up a few stragglers along the way, but it’s a lot more fun to be part of the group. 

A number of people commented that they come to Summit to learn, but also to see their friends. I have other friends, but they don’t really understand what I do for a living so it’s fun to hang out with people who do.

Go spend some time with your local UG group this year. Get to know people in your area this year and then come to Orlando and have some fun at Summit 2019. But you have to start now so block out the next local user group on your calendar.

GP Controller Series: Improving Bank Reconciliation

Reconciling the bank account to the general ledger is critical because it is one of the few areas that provides independent confirmation of transactions. Companies are reviewing internal records, the GL, to external records from the bank. This is a critical exercise and a key control point. I’ve personally seen more than one significant mess resulting from missing bank recs.

Most companies reconcile monthly. The monthly reconciliation is tedious and time-consuming, usually coming during the pressured-filled month-end period. Monthly is also a little slow in today’s environment. If a bank rec is missed, it’s another month before it’s complete. Inconsistency around bank recs is a key harbinger of other problems in the organization.

I’m a strong proponent of daily bank account reconciliation. The time required is generally very short. Missing a day, because someone is out, is easily caught up. Errors and problems are identified quickly, not a month later, and month end bank rec becomes simply reconciling the last day of the month.

Daily bank recs support the idea of a lot of little corrections to make sure that things are on the right path. There are details of how to do this at with options for automated, manual, and third-party options. The key as a controller is making the decision to implement daily bank reconciliations and following through to ensure that it’s happening.

Links to all the posts in this series can be found at