Planning and Configuring Chart of Accounts Part 1: Main Accounts6 min read

In this article, we’d like to focus on all the planning activities, setup, and configuration required to get started using the General ledger and finance features of Dynamics 365 Finance. We are going to start by introducing some terminology, in case you are new to Dynamics 365 since there are some terms and things that we use in Dynamics 365 Finance that may be a little unusual compared to other systems.

Then, we are going to describe a number of recommended practices for configuring your main accounts. We are also going to discuss and demonstrate how to create legal entity overrides and dive into the process and best practices around main account categories.

Terminology

Starting with the chart of accounts, by definition, this is a list of main accounts that is not legal entity-specific. Think of it as a wrapper or container for the list of main accounts, where each legal entity can be linked to a single or one chart of accounts in the Ledger form.

The next term to talk about is main accounts. Main accounts are really the core of the chart. In some systems, this may be referred to as the natural account. These accounts are used to track detailed transactions, including assets, liabilities, expenses, and so on.

Financial dimension – some other systems may refer to these as segments, but you can think of the dimensions as a way to break down your accounts by an additional attribute that further describes a transaction. Common examples include departments, costs or profit centers, and business units. 

Ledger account is a term that is specific to Dynamics 365 Finance that describes the specific combination of main accounts and financial dimensions.

Then, a ledger is actually a page in the system and is used to select the chart of accounts, account structures, fiscal calendar, and currencies that will be used for the selected legal entity.

Moving to more terms related specifically to the ledger, they would be as follow:

• General Ledger – when the term is used, it is referring to modules in Dynamics 365 Finance or to the generic term that represents the register of all debits and credits that were recorded in a financial system. 
• Sub-Ledger – a ledger that contains a sub-set of ledger transactions centering on another item such as customer, vendor, or item.

Sub-ledger

Let’s have a closer look at a subledger compared to the general ledger. The general ledger contains a set of master accounts and in Dynamics 365 we refer to these as main accounts, while a subledger contains a set of intermediary accounts. These accounts are different in each subledger, but as an example, the accounts receivable subledger stores customer account numbers while the inventory subledger stores item numbers.

When we think about the nature of the transactions that are posted into each, the general ledger is a single entry point that includes all transactions across the system. While there are many subledger that make up a subset of transactions, each of the sub ledgers links to the general ledger.

Lastly, when we think about the volume of transactions, there is a distinct difference between the number of transactions in the general ledger as compared to the sub-ledger. The general ledger transactions are typically summarized and have a lower volume of transactions while the sub-ledgers have a large volume of detail as they carry each of the individual transactions of the sub-ledger. This is why we should avoid duplicating sub-ledger data into the general ledger.

For example, the account receivable data already contains the customer account number and can be used for detailed reporting related to accounts receivable.

Financial Dimensions

There are three pillars of financial dimensions:

1. Types:
   1. Custom dimensions, which offer full flexibility of the values and behavior because you define exactly what they mean;
   2. Entity backed dimensions, that get their list of values from another source, such as an existing table in the system (customers, vendors, etc.);
   3. Organization units, which are a special type of entity back dimension that have additional functionality available in the organization administration and organization hierarchies. As an example, organization units include cost center, business unit, department and so on.
      
2. Behavior – it is important to note that all custom dimensions and some entity back dimensions are shared across legal entities. An example of a shared value is a worker, while an item is legal entity-specific.
   
   When a dimension has legal entity-specific values, you can create legal entity overrides to control the behavior of a dimension value in each legal entity. One thing to remember is that dimension values that are from different legal entities are distinct or not exactly the same, even if they look the same. For example, if customer group is a financial dimension and customer group ABC exists in multiple legal entities – each of the values is unique to its legal entity, even though they share ABC value.

The final point for the behavior is related to the ability to delete dimensions. Because of the unique architecture of financial dimensions, dimensions and dimension values cannot be deleted after they have been selected in a journal or transaction.

1. Limitations –
   1. Financial dimensions should not be used to model operational or business requirements. Creating a project dimension in place of implementing the project`s module often leads to expectations of the financial dimensions behavior that is not intended or supported.
      
   2. All of the tax functionality on main accounts is legal entity-specific, so you will always need to create a legal entity override to configure tax information – even if you only have one legal entity.
      
   3. Financial dimensions reports are not available in all reports throughout the system. Based on your business requirements and reporting needs, you may need to extend reports to allow filtering by dimensions or to display dimension data in reports.
      
      Since your dimensions are unique to your implementation, there is not an easy way to add dimensions to all your reports automatically. This means it is critical to evaluate where the dimensions are needed in your reporting.
      
   4. Lastly, it is important to note that interunit accounting is only designed to address the accounting entries. If you have business requirements across the business units or another dimension that you are using for interunit accounting, the operational aspect of those transactions is not affected by the interunit accounting process.

Sub-Ledger vs Financial Dimension

Since we have figured out what sub-ledger and financial dimensions are, let’s take a look at the difference between them and when we should use the first or the second one.

If your business requirement requires reporting on value and the ability to summarize a value, then a financial dimension can likely meet your target.

Conversely, if you have operational requirements or need individual transaction details beyond the dates and dollars that are posted into the general ledger, then a sub-ledger should be used.

 It is not generally recommended to customize the financial dimensions or general ledger to copy or track additional details in the general ledger as a substitute for using a sub-ledger that has the same functionality available.

For example, customization to put the sales order number directly in the general ledger table is no better than having a financial dimension for the sales order number and both of these options are not recommended.