Budget Transactions vs Budget Upload

Today’s #TipTuesday is a brief post about Budget Transactions. Introduced in GP 2010, Budget Transactions were a feature to add more control over budget changes in Dynamics GP. Here is a brief post on how it works.

Why would I use this?

In the past with Dynamics GP, prior to GP 2010, changing a budget meant uploading a newer version of the budget using the Excel Budget Wizard or manually opening the budget in GP and editing the values as needed. It was like editing a customer or vendor: changes were made but you have no real idea who made them or where the numbers came from. Any control of the process was entirely outside of Dynamics GP, using methods like versioning your budget import spreadsheets.

With this feature, it added new ways to handle budget changes in a transaction format. The transactions resemble journal entries, for the most part at least.

Budget Example

I’m using Fabrikam for my example, GP 2018 (hence the dates are way into the future!). In my case, I’m using account 000-4110-01, a sales account in Fabrikam. The simple scenario here is the budget was $15MM per year, starting at $1MM per month and then later in the year increasing each month. Here’s the budget before I made any changes:

I wanted to increase this forecast by 1.2%. So, I click on Budget Transactions (Financial navigation pane > Transactions area), and recorded the following transaction. For the most part, the window resembles a General Entry transaction except that it’s requiring a Budget ID and has some budget-related fields around change methods.

In terms of calculation method, I wanted to change the budget by a percentage but the options are there for changing the budget by a certain dollar amount or setting the budget periods to a flat amount as well. The last alternative is typing in the periods the adjustment amount you want to see. To make the change, the Calculate button takes what you input in this section and makes the change in the Adjustment column. It reads the Typical Balance of the GL account to know, for instance, that an increase in a Sales account budget should be a credit.

After posting this entry, a Budget Trx Posting Journal will come up (after posting a batch, or after posting by transaction and closing the window, the same behaviour that occurs on other transactional posting activities).

After I posted this entry, I went back to my Budget Detail report to view the new budget and verify the changes:

General Ledger Setup (upgrades)

One caveat to Budget Transactions, or any new feature in GP really: if you upgrade to a version with new features like this one, you always want to re-check your setup windows! New features, particularly transactional ones like this, will nearly always have some new option in the Setup window of the module that by default will tend to be unmarked. That is a general reminder for customers using prior versions of GP since new customers who started with GP 2010 or newer, these settings would have been part of a typical setup discussion and marked accordingly.

In this case, in General Ledger Setup there were 2 new fields introduced in GP 2010 called Next Budget Journal Entry and a Maintain History option for Budgets. The Next Budget Journal Entry always defaults to 1 (this shows 2 since I posted a test entry first!). The Maintain History defaults to unchecked so that may be important to review prior to starting to use this. (The whole point of using a feature like this is to track the history of changes to a budget!).

In closing, I think this feature would be useful for some organizations where they perhaps aren’t complex enough to have gotten into any third party budgeting software which would help manage changes, but large enough to want more formality around budget changes. What this does is force changes through a transaction process, which means an opportunity to have a point of review, control over posting etc. prior to a change being committed to the budget. What it does require though is looking at your GP security around budgets to ensure you have the controls you need to prevent users from changing budgets “the old way” where a number has changed and no one knows who or where the change came from!