Implementing Dynamics AX 2012 General Ledger Dimensions

One of the strongest new features in Dynamics AX 2012 is the Dimensions in the General Ledger (GL) module.  This four-part series will provide some insight in how to set up and implement dimensional-based financial systems.

Part 1 – Dimension-based GL’s vs. Traditional Segmented GL’s

When I started to script out this blog, my initial intent was to use the typical pros and cons approach for both segmented general ledgers and the more modern dimension-based ledgers. I quickly ran into a little problem though.  I couldn’t quite find any benefits of using the traditional general ledger system.  It was a bit like modern dentistry.  Once Novocain was invented, would you really want to frequent a dentist who didn’t use it?

From a definition standpoint, a segmented general ledger is one in which the chart of accounts is a single, concatenated string that consists of various segments that capture specific information.  The defined number of segments must be present for every defined account, even if that segment doesn’t necessarily “go” with that account. For example:

This was the initial way that general ledgers were built, and there were a few problems with it, such as:

1. Account combinations were longer than the Black Friday line at Best Buy.  Back in the day, the GL was the only system we really trusted, so the tendency was to jam every financial analysis we ever wanted into the GL.
2. Accounts often had more zeros than a Houston Astros scorecard (apologies to Astros fans, but admit it…you laughed).  Since every segment was required for every account, you had to put something in the field.
3. Account definitions typically required someone to pre-create every possible combination of values.  So adding a new natural account was time-consuming because it would require potentially hundreds of entries.  Later systems, on the other hand, would explode out the combinations for you.  The problem with that approach was that you had a bunch of account combinations that would never, ever get used.
4. Charts of account that had hundreds of thousands of accounts.  I once reduced the chart of accounts for a division of a Fortune-250 company from 106,000 accounts to around 34,000 accounts.  34,000 accounts. That’s still a lot of reclasses, reconciliations, etc.
5. Users were forced to enter every single character. Let’s just say a lot of Accounts Payable keyboards had worn-out “0” keys.
6. The inclusion of “future” segments….just in case.

So as computing power grew and systems got more sophisticated, the industry moved to general ledger systems that had dynamic charts of account. The segments, or dimensions, that are required to be entered for a specific natural account would be dynamically derived during the transaction based on the main account.

The key premise is that different pieces of supporting details are needed based on the main account and its purpose. The table below provides some examples of potential dimensions that might be used in conjunction with specific main account types:

So what are the benefits of a dimension-based general ledger?

1. Significantly reduces the number of GL account combinations because you no longer need to explode dimensions against accounts that make no sense.
2. Alpha-numeric combinations. I’m a bit of a purist who doesn’t like alpha characters in their account logic. I just think keeping it numerical streamlines reporting, facilitates memorization of accounts, etc. But with dimensions such as expense purpose, it completely makes sense to use full word values like Airfare, Meals, etc.
3. Values for many dimensions default from master data, thus minimizing manual entry.  Examples include items, vendors, customers, etc.
4. When you inactivate a dimension like project or asset, it doesn’t leave gaps in the core account that is used for reporting, etc.
5. Dimensions are more extensible. How many of you have charts of account with logic built into them and then ran out of room? It’s easy to recreate a dimension with more characters if needed.
6. Dimensional data becomes part of a standard monthly reporting package, as well as any post-close analysis that you generate.
7. Dimensional data can be used in general ledger allocations.

Part 2 – Dimensional GL’s: Implementation Considerations

RSM Staff