• Home
  • About Me
  • Contact
  • German
  • TestPage

Microsoft BizApps Finance & Controlling

Microsoft BizApps Finance & Controlling

Tag Archives: Dynamics AX 2012

Incidental Acquisition Costs – Part 1

24 Sunday May 2015

Posted by Ludwig Reinhard in Inventory

≈ Comments Off on Incidental Acquisition Costs – Part 1

Tags

Allocations, Dynamics AX 2012, Freight charges, Inventory valuation

Within this post I will describe how incidental acquisition costs such as transportation and handling costs can be incorporated into the total acquisition costs of a company’s inventory.

Background
Most accounting regulations such as German business law, IFRS and US-GAAP explicitly require including incidental acquisition costs into the cost of a company’s inventory. For details, see e.g. §255 HGB, IAS 2, ARB 43 Ch. 4.

Implementation Dynamics AX
One option to incorporate incidental acquisition costs, such as freight charges, into a company’s inventory is using a charge code that is setup with a debit posting type “item” as illustrated in the following screenshot.
EN_15-1Using charge codes is a good practice in Dynamics AX as long as a direct relationship between the direct and incidental acquisition costs of an item exists. Yet, if this relationship does not exist – e.g. because your freight forwarder send summary invoices for all shipments that have been made within a specified period – using charge codes similar to the one illustrated above might not be the right solution. That is because manually allocating freight charges to the different purchase orders and items is not manageable in practice. One possibility how this problem can be overcome will be illustrated below based on the following example.
EN_15-2Within this example I assume that a company purchased various items (cameras, computers, etc.) for 100 mio. EUR in a given year. The different vendors that supplied the items charged 1.4 mio. EUR for transportation & freight to deliver the items to our warehouse. Those freight costs were recorded in Dynamics AX by using a charge code that has a debit posting type “item” setup. As a result, 101.4 mio. EUR were recorded as total inventory costs in the company’s inventory accounts (140300-140399).
EN_15-3In addition to the direct freight costs, indirect freight cost invoices for another 600 TEUR were received and recorded in Dynamics AX. As those invoices had no direct relationship to purchase orders and/or item transactions, those invoices were directly recorded as an expense on ledger account 600725. Because of this treatment, the total inventory value is understated by 600 TEUR.
EN_15-4
EN_15-5

To avoid similar undervaluations in subsequent years, the following changes are introduced:

Step 1
The first change is setting up a new charge code (“freight allocation”) similar to the one previously used. The main difference is that this new charge code is setup with an offset (credit) posting type “ledger account”.
EN_15-6

Step 2
Thereafter, the newly created charge code is setup as an automatic charge code to ensure that every item transaction gets an additional 2% freight charge allocated. (Note: the 2% charge value is derived from the relationship between the total freight costs and the purchase volume in the previous year).
EN_15-7

Step 3
To avoid that freight charges are included twice in a company’s inventory value, a new direct freight charge code (“Freight new“) is setup next. This charge code is used in all purchase orders to record freight charges that vendors invoice directly. That is, this code will be used in situations where a direct relationship between purchase orders/item transactions and freight charges exists. Note that this freight charge code is setup with a debit posting type “ledger account”.
EN_15-8In the following year, a total of 2.64 mio. EUR of direct and indirect freight cost invoices are recorded in Dynamics AX. Due to the newly setup direct freight charge code “Freight new” – see step 3 before – all freight costs are recorded on expense accounts (account 600720 and 600725). Thereof, a total of 2.4 mio. EUR are allocated to the inventory accounts due to the automatic charge code that was setup in step 2 (see the balance on ledger account 600735 below). The difference between the actual recorded freight costs of 2.64 mio. EUR and the allocated freight costs of 2.4 mio. EUR represents the amount by which the company’s total inventory is undervalued.
EN_15-9 EN_15-10This undervaluation can be explained by the automatic freight allocation percentage that was setup (2% of the purchase volume) and the actual freight costs recorded (2.2% of the purchase volume). The following graph exemplifies this relationship by showing actual and allocated freight costs and the resulting over-/underallocation for the current year.
EN_15-11

At this point the question arises how to deal with the remaining over-/underallocated freight costs:

Option 1
Given that the over-/underallocated freight cost amount is small and negligible from a global company perspective, the first option is not to make any adjustment to the over-/underallocated freight cost amount and to leave the remaining amount in the profit and loss statement.

Option 2
If a significant amount remains on the freight accounts in the income statement, a General Ledger allocation rule can be used to shift the un-allocated amount from the freight accounts in the income statement to the inventory accounts in the balance sheet. This can be realized by specifying that the sum of the freight expense accounts (600720-600735) will be allocated to an inventory account used for posting manual adjustments; in the example used, account no. 140301.EN_15-12After running the ledger allocation rule in General Ledger the sum of all inventory accounts (140301-140340) equals the total purchase cost plus the total (direct and indirect) freight costs. In the example used 122.64 mio. EUR. At the same time, the freight expense accounts in the income statement (600720-600740) add up to 0 EUR, illustrating that all freight costs are recorded in the balance sheet.EN_15-13Note that using this option has the disadvantage that the remaining over-/underallocated freight cost amount is shifted to the inventory accounts in the balance sheet at the General Ledger level only. In other words, the postings generated by the allocation rule cannot be identified in the inventory module.

Option 3
To overcome the disadvantage of the previous option, a direct inventory value adjustment can be recorded in the inventory module as illustrated in the next screenshot.
EN_15-14The major advantage with this option is that inventory values in General Ledger and the Inventory module match automatically. Yet, this advantage comes at the cost of a higher complexity and effort to identify and record the amounts that need to be adjusted. (Among others, you have to clarify how to distribute the remaining over-/underallocated amount to the different inventory items).

Irrespective of the option chosen to handle the remaining over-/underallocated freight costs, it is a good practice to review the automatic freight allocation charge setup at least once a year to ensure that the total over-/underalloacated amount remains small.

Allocations & Cost Distributions in GL

10 Sunday May 2015

Posted by Ludwig Reinhard in General Ledger

≈ Comments Off on Allocations & Cost Distributions in GL

Tags

Allocations, Cost accounting, Dynamics AX 2012

Some of you might know that Dynamics AX ships with a cost accounting module that is primarily used by companies in Central Europe. If you consider using this module but find it too complex and difficult to set up, have a look at the ledger allocation functionality that can be found in the General Ledger (GL) module.
EN_14-1This blog post illustrates how you can set up ledger allocation rules for distributing costs between different financial dimensions, such as departments, cost centers, business units, etc.

Scenario
The following screenshot shows you a report with different costs that have been posted on three different departments (finance, sales and operations). Because the finance department is providing services for the other two departments, all costs that have been recorded on the finance department shall be allocated to the sales and operations departments at the ratio of 20 : 80.
EN_14-2To realize the allocation between the different departments, you can follow the next steps:

Step 1: Setup & activate a ledger allocation rule
The first step required is defining and activating a ledger allocation rule as illustrated in the next screenshot.
EN_14-3

Step 2: Select allocation method, date interval and journal name
EN_14-4After you setup the ledger allocation rule you have to define the method that Dynamics AX uses to allocate your cost. Currently you can select among one of the following methods:

  • Basis
  • Fixed Percentage
  • Fixed Weight
  • Distribute the source document amount equally

To me, the first two methods (basis & fixed percentage) seem to be the most important ones in practice. (Note that the basis allocation method allows making allocations based on amounts that have been posted on other ledger account – financial dimension combinations).
After having decided on the allocation method, you have to select a date interval code that defines the period Dynamics AX is calculating and posting allocations for. Note that making no selection or a wrong selection in the date interval code field often results in allocations that users are not able to follow up.
The last setup required in this window is the journal that is used for posting the allocations.

Step 3: Setup offset window
The setup in the offset window determines the offset ledger account–financial dimension combination used for posting the ledger allocation.
EN_14-5Users can choose between “source” and “user defined” when making this setup. The difference between both options is that selecting “source” results in a cost distribution while selecting “user defined” results in an allocation.

Excursion:
The difference between an allocation and a cost distribution is that the former one allows you identifying the originally posted transactions while the latter doesn’t. Furthermore, selecting “source” does not require any other additional setup, while selecting “user defined” requires the specification of an offset ledger account and offset financial dimension. In the following screenshot both options are compared.
EN_14-6
In the previous screenshot the report on the left shows an allocation where you are still able to identify the transactions that have been recorded for the finance department. The report on the right shows a cost distribution where you cannot identify what has originally been posted for the finance department.

Step 4: Source Definition
The source definition is pretty straightforward as it simply requires you defining the ledger account – financial dimension combination that will be used for the allocation / cost distribution. Please note that you can use ranges as well as wildcards for the setup in this window.
EN_14-7

Step 5: Destination definition
After you defined what shall be allocated, you have to define where the costs shall be allocated to. Also this setup is pretty straightforward as you simply have to specify a percentage figure together with the ledger account–financial dimension combination.
EN_14-8

Step 6: Run the ledger allocation rule
The last step is running the periodic ledger allocation process that generates the allocation transactions in the allocation journal. When starting this process you can either directly post the allocations (selection “post only”) or generate an allocation proposal that you can check and post later on (selection “proposal only”).
EN_14-9 EN_14-10

Result
In the example used, I selected “proposal only” which resulted in the following allocation journal voucher.
EN_14-11After posting the journal, the allocations made can be identified in the lower section of the costing report.
EN_14-12

Final remarks
Please note that the ledger allocation functionality can be used for numerous other purposes (e.g. Profit tax calculations and postings).
What is more, the GL ledger allocation functionality allows making allocations across company accounts. This is something that cannot be realized in the cost accounting module. Yet, if you consider setting up intercompany allocations remember considering tax and transfer pricing regulations.
Finally, note that using the allocation functionality in GL versus the one in the cost accounting module provides you the advantage that you can analyze the allocations made in Management Reporter and the standard Dynamics AX SSAS Cubes.

GL foreign currency revaluation types

26 Sunday Apr 2015

Posted by Ludwig Reinhard in General Ledger

≈ Comments Off on GL foreign currency revaluation types

Tags

Dynamics AX 2012, Foreign currency revaluation, Vendor payments

If you record foreign currency transactions you might experience a situation in which Dynamics AX records foreign currency gains/losses on the wrong ledger account. This blog post illustrates the circumstances under which you might run into this situation and provides you a possibility how to fix this issue.

Scenario
For this example, the following (fictional) currency exchange rates between the EUR and USD are used. (Please note that the local company currency is EUR). EN_0The first transaction recorded in Dynamics AX on 1 January 2015 is a vendor invoice for 1000 USD. At the time the vendor invoice is recorded the EUR/USD exchange rate stands at 80 EUR/100 USD, resulting in an amount equivalent to 800 EUR. EN_1As the invoice is not settled until the end of January 2015, a foreign currency revaluation is run in the Accounts Payable module. This foreign currency revaluation process results in an unrealized exchange rate gain of 50 EUR (1000 USD * [80/100 EUR/USD – 75/100 EUR/USD]), which is recorded on the ledger account for unrealized exchange rate profits. The next screenshot shows the corresponding voucher. EN_4
On 5 February 2015 the vendor invoice is paid by using a wire transfer. This transfer is – as usual – recorded in a vendor payment journal in the Accounts Payable module. Because the USD appreciated to 87 EUR/100 USD at the time the payment is made, an exchange rate loss of 70 EUR is realized. This loss is recorded on the ledger account for realized exchange rate losses. At the same time, Dynamics AX cancels the previously recorded unrealized exchange rate gain of 50 EUR. The next screens show the payment made and the corresponding vouchers created. EN_6 EN_7Please note that the payment is made via a transfer account – in my example account “109053 Transfer Bank Charlie”. This transfer account is cleared on 8 February when the bank transaction is posted (see the next screenshot). EN_8As the EUR/USD exchange rate changed from 87 EUR/USD (at the time the payment was made) to 83 EUR/USD (at the time the bank transaction was posted), a balance of 40 EUR remains on the payment transfer account. This balance can be identified in the following screenshot.
EN_9To clear this balance on the transfer account the foreign currency revaluation process is run in the General Ledger module for the respective account. The outcome of this revaluation process is a balance of 0 EUR on the transfer account.EN_10EN_11If one takes a close look at the foreign currency posting that is made to clear the balance on the transfer account, one can identify that the balance was posted on the ledger account that is used for recording unrealized exchange rate losses (see the next screenshot). EN_12Posting the remaining balance of 40 EUR against the unrealized exchange rate loss account is wrong because the transaction represents a realized loss. The next figure summarizes all transactions that have been recorded for this example and highlights the remaining realized and unrealized exchange rate gains and losses recorded in Dynamics AX.EN_12aEven though the total exchange loss of 30 EUR is correct from an overall perspective, the elements that make up this total amount are wrong. That is, if your company reports realized and unrealized currency exchange gains/losses separately, your profit and loss statement shows incorrect figures.

Possible solution
In this section I will show a possible solution to the problem illustrated. This solution requires some minor system modifications that are described next.

Step 1
The first modification required is extending the Base Enum values “FinancialGain” and “FinancialLoss” of the “CurrencyGainLossAccountType” Base Enum. In my example I simply added the country codes for Germany (DE) and the USA (US). Please see the next screenshot for details.
EN_13

Step 2
The next (optional) step is to change the following two labels: @GLS109008 and @GLS109005. EN_14

Step 3
Step three requires extending the LedgerExchAdj class by the same country codes that have been used in step 1. Please note that those codes are entered slightly different (#isoDE, #isoUS).
EN_15

Step 4
A similar adjustment is required in the ledger form as illustrated in the following screenshot.
EN_16

The result of those modifications is that two new exchange rate transaction types are available in the ledger form (see the next screenshot).
EN_17

With this setup I repeat the previously recorded transactions on another (“fresh”) bank account and its corresponding transfer account. All steps and vouchers are identical except the voucher that is generated when running the foreign currency revaluation in GL for the transfer account.

As you can identify from the next screenshot, after having done the previously described system modifications, Dynamics AX does now record the exchange rate adjustment of 40 EUR on the newly setup account that represents a realized exchange rate adjustment. This change allows you reporting currency exchange rate differences correctly in your profit and loss statement.
EN_21Please note that the foreign currency revaluation process in the Bank module is also affected by the changes described here. For details, please see my previous post.

← Older posts
Newer posts →

Microsoft BizApps Deutschland Podcast

Dynamics UserGroup Deutschland

Project Accounting Book – Part 2

Project accounting book

Categories

  • Accounts Payable
  • Accounts Receivable
  • Bank Management
  • Book reviews
  • Budgeting
  • Cost accounting
  • Fixed Assets
  • General Ledger
  • Inventory
  • Management Reporter
  • Miscellaneous
  • Podcast
  • PowerPlatform
  • Project
  • Sustainability
  • Uncategorized

Tags

Advanced bank reconciliation AI Allocations Artificial Intelligence Automation Azure Bank reconciliation BizApps Budgeting Controlling Copilot Copilot Studio Cost accounting module Cost center accounting D365 D365FO Dynamics 365 Dynamics AX Dynamics AX 2012 Electronic reporting Email Environment Flow Global Warming invoice invoice recording IOT LEGO Management Accounting MS Flow MT940 PowerApps Power Apps PowerAutomate Power Automate PowerPlatform Power Platform Process Mining Project RPA Security SharePoint Sustainability Sustainability Accounting Sustainability Manager Tax time recording Vendor payments WBS workflow

Enter your email address to follow this blog and receive notifications of new posts by email.

Subcribe

  • RSS - Posts
  • RSS - Comments

Legal

  • Disclaimer

Important Websites

  • Microsoft BizApps Links

Archives

  • July 2025
  • June 2025
  • May 2025
  • April 2025
  • March 2025
  • February 2025
  • January 2025
  • December 2024
  • November 2024
  • October 2024
  • September 2024
  • August 2024
  • July 2024
  • June 2024
  • May 2024
  • April 2024
  • March 2024
  • February 2024
  • January 2024
  • December 2023
  • November 2023
  • October 2023
  • September 2023
  • August 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015

Blog at WordPress.com.

  • Subscribe Subscribed
    • Microsoft BizApps Finance & Controlling
    • Join 619 other subscribers
    • Already have a WordPress.com account? Log in now.
    • Microsoft BizApps Finance & Controlling
    • Subscribe Subscribed
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...