Some of you might have noticed that Dynamics AX uses the same revenue accounts for posting sales order revenues and return order revenues. The underlying reason for this behavior is that Dynamics AX treats both order types – from an accounting perspective – similarly and always refers to the revenue accounts that are setup in the inventory posting form. Please see the following screenshot.

Many accountants are very unhappy about this standard behavior as sales orders revenues and return orders revenues are mixed in the same ledger account, which can make monthly reporting cumbersome.
Fortunately, several approaches exist that allow differentiating sales order revenues from return order revenues. Within this blog post I will illustrate you some of those approaches together with the advantages and disadvantages of applying them in a live environment.

Approach 1: Manually adjust the default account in the return order form
The first approach how one can post return order transactions on a revenue account different from the one that has been setup in the inventory posting form is to overwrite the default main account in the return order form. Please see the following screenshot for an example.

This change ensures that the main account entered is used when posting the credit note for the customer. The next screenshot shows you the result of my test transaction.

Advantages & disadvantages of this approach
The major advantages of this first approach are its simplicity and the fact that no system modification is required. Those advantages do, however, come at a price. The price is that the process can easily consume lots of time, especially if many return orders / return order lines need to be adjusted manually. A second disadvantage of this approach is that the process is – due to the required manual main account change– likely to result in errors.

Approach 2: Inventory financial link
A second possibility for separating ordinary sales order revenues from return order revenues is using the inventory financial link functionality that builds upon using financial dimensions and not main accounts for identifying and separating return order sales. This approach is based on the concept of linking inventory sites with financial dimensions, as illustrated in the next screenshots.

With the inventory dimension link setup, the only thing required when recording return orders in Dynamics AX is selecting the correct site.

The change of the inventory site ensures that the correct financial dimension is automatically picked up for the credit note posting.

As a result, return order sales can be identified by filtering on the financial dimension that has been linked to the inventory site that is used for return orders.

Advantages & disadvantages of this approach
A major advantage of this second approach is that no manual entry of a main account in the return order form is required, which considerably reduces the risk of making errors.
Yet, irrespective of this advantage, problems might arise due to conflicts with the inventory and warehouse setup. For that reason, this approach might not be feasible in all company environments. An additional disadvantage with this approach is that it might require the setup and use of an extra financial dimension.

Approach 3: Minor system adjustment
If you do not like the previous approaches for separating sales order revenues from return order revenues e.g. because they are not feasible within your company environment, you might think about making a system adjustment. In the following, I will show you one possibility how a simple system modification is able to separate sales order revenues from return order revenues.
The idea of this system adjustment is that the revenue account that is used for return order revenue postings – in my example main account 405000 – is taken from the “deferred revenue on delivery” section in the inventory posting form.

Hint: The underlying assumption is that the “deferred revenue on delivery” inventory account type is not used in your company. If you use this account type, simply chose another account type that is not used. If you use all account types, simply make an additional country-specific account type available for the only purpose of holding the ledger accounts used for posting return order revenues.

For the purpose of this example, I will continue with the invent account type “deferred revenue on delivery”. I made the following adjustment to the load segments method of the return table form to use the accounts setup in the “deferred revenue on delivery” section for return order sales transactions.


This adjustment “brutally” overwrites the main account that Dynamics AX uses by default by referring to the account that has been setup in the “deferred revenue on delivery” section of the inventory posting form. That is, by referring to the account that has been setup for the invent account type “SalesPckSlipRevenue”.

In the example chosen, the default main account 401100 transferred from the original sales order is overwritten by main account 405000 and used for posting the credit note as illustrated in the following screenshots.

Advantages & disadvantages of this approach
A major advantage of this approach is that it can be realized by implementing a minor system adjustment that makes the manual entrance of main accounts superfluous. This fact significantly reduces the risk of generating wrong postings for return orders.
The disadvantages of this last approach are (a) that you need a developer to implement the code adjustment and (b) that this approach does not help you differentiating revenues based on the reasons why customer returned items. If this differentiation is important for you, please have a look at the next subsection that illustrates how this separation of revenues based on return reasons be realized.

Approach 4: Link charge codes and disposition codes
Within this last section of this post, I will give you some hints on how you can setup Dynamics AX in a way that allows you separating (a) sales order revenues from return order revenues and (b) the reasons why items where returned from customers.
The way how this can be realized is by linking the different disposition codes – that are used when processing return orders – with automatic charge codes, as exemplified in the next screenshot.

Please note that the charge codes are setup with the category “percent” and a “charge value” of 100%.

Each of those charge codes is setup with a debit and credit posting type “ledger”, which simply serves the purpose of creating an additional posting line that allows identifying return order sales.

Let me show you an example how this works. (Please note that I disabled the system change shown in the previous section). Example:
On 1^st August a sales order invoice for 100 pcs of an item for a price of 322.00 / item is recorded in Dynamics AX and generated a voucher that posts the sales revenue on main account 401100. Please see the following screenshot.

Eight days later, the customer returns 10 pcs of the items sold. This return is recorded in Dynamics AX by using the return order functionality in the sales and marketing module.

Please note that no change has been made to the main account that Dynamics AX automatically picked up from the original sales order.
The next steps are specifying a disposition code and posting the return order packing slip and credit note.

The outcome of those process steps is a credit note voucher that recorded the return order revenue on the same main account that was used for posting the original sales order revenue. In my example, main account 401100, highlighted in yellow in the next screenshot.

Yet, due to the link of the disposition code used with a charge code, an additional posting was generated – highlighted in green color. This additional posting allows identifying the sales return revenue amount for the specific return reason.

After posting some additional return orders, the trial balance at month end looks as follows:

The amounts illustrated in the trial balance form can be interpreted as follows:

• The sum of the yellow lines (22540.00 + 6440.00 + 3220.00 = 32200.00) represent the total sales revenues that have been recorded in this month.
• The sum of the green lines (6440.00 + 3220.00 = 9660.00) represent the total amount of sales returns from customers in this month.
• As different charge codes have been setup for each disposition code, customer returns for “dead on arrival”, “ordering errors” and other reasons can easily be differentiated directly in the General Ledger by referring to the main accounts (405700 and 405800 in my example).

Advantages & disadvantages of this approach
The major advantage with this last approach is that no system adjustment is required and that all transactions can be realized with standard Dynamics AX tools. The major disadvantage is that many new ledger accounts and charges codes need to be setup and – for that reason – that the interpretation of the monthly results gets more complex.

To sum up, there are several approaches available in Dynamics AX that allow you separating sales order revenues from return order revenues. I hope that the information provided in this blog post allows you choosing an approach that fits best into your company environment.