Microsoft Dynamics NAV: Managing Multiple GAAP’s
Multi-national companies will often be required to keep their accounting books and records in multiple GAAP’s. For example, a company may have a policy to report all entities under IFRS for consolidation purposes, but local statutory requirements in local jurisdictions will require using locally prescribed accounting principles. Also, companies that have previously reported under US GAAP, but are moving towards IFRS may keep both accounting principles for a period of time during a transition from US GAAP to IFRS.
Microsoft Dynamics NAV (formerly Navision) does not explicitly address multiple GAAP’s within its functionality but there are multiple methods for achieving this goal without extensive customization or disruption to standard NAV processes.
Three methods that can be used to manage multiple GAAP’s are as follows:
1. G/L Account Nomenclature
3. Virtual Companies
Most NAV designers/consultants will initially default towards #2 above as dimensions are the system’s default functionality for capturing transaction specific tags for reporting purposes. Virtual companies can be setup to capture GAAP adjustments but managing multiple companies to capture GAAP differences can become an administrative burden and often requires frequent addition/removal of virtual companies when legal structure or accounting principle changes occur. This article discusses G/L Account Nomenclature and what we believe to be not only the simplest solution but the best option as well (#1 above).
Only a small number of G/L accounts will require GAAP adjustments from one GAAP to another and from a transaction %; less than 99.9% of transactions are actually GAAP adjustments. Therefore, we really don’t like using dimensions because there are not enough GAAP adjustments to justify putting in controls to insure all transactions are posted with the GAAP dimension.
Therefore, we use an extremely simple solution. We put a letter in front of G/L accounts to represent GAAP adjustments. For example, you may use an “L” in front of an account number that will hold local GAAP adjustments. Local GAAP reporting is only required once per year so you so you don’t want them highly visible; by using an Alpha character in front of the account, NAV will put them on the bottom of the GL account list by default. These “alpha” accounts can be summed with their related accounts for Local GAAP Reporting (and local GAAP reporting is usually only done once per year for local annual statutory filings and tax returns). The L accounts can map to the same Group account because they will always net to zero and therefore will be excluded from Consolidation reporting without any special logic being applied in the consolidation interface. You can have multiple GAAPs this way as well. For example, a company can keep their books in IFRS by default but if they must report their consolidation in an alternative GAAP (e.g. Dutch GAAP) they can setup D… accounts for Dutch GAAP and map those accounts to Group accounts for mapping into their consolidation solution (whether that is NAV or an external consolidation solution like Hyperion). Therefore, in this example, you have Dutch GAAP going into the consolidation solution and your non-alpha accounts represent your default GAAP (IFRS). There is nothing technical required at all to accommodate the consolidation interface or anything else.
In this example, only the 2x and 3x require GAAP adjustments so an abbreviated COA would look like this:
EmergeNext ADNM (an ADNM International group co
Phone: +1 (312) 380-0570
500 N. Michigan Ave.
Chicago, IL 60611
EmergeNext ADNM, LLC
Chicago | Milwaukee | Montreal | New York | Paris