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, before 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 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 the 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:

A sample budget for one sales account in Fabrikam Ltd.

I wanted to increase this forecast by 1.2%. So, I clicked 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 requires a Budget ID and has some budget-related fields around change methods.

In terms of the 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 of the adjustment amount I want to see. To make the change, the Calculate button takes what I 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.

A sample budget transaction entry for the same account.

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).

A budget transaction posting journal screenshot.

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

The same GL Account budget after the entry was made.

General Ledger Setup (upgrades)

One caveat to Budget Transactions, or any new feature in GP really: if I upgrade to a version with new features like this one, I always want to re-check my 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 before starting to use this. (The whole point of using a feature like this is to track the history of changes to a budget!).

The General Ledger Setup window shows Budget Transactions options for the next budget journal entry number and the option for enabling history for budget transactions.

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. before a change is committed to the budget. What it does require though is looking at GP security around budgets to ensure the controls needed 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!