COA configuration question

[panadm]

All,

We are a US Company implementing JDE in multiple countries and I have a query related to COA and accounting.

Given local and statutory differences vs US GAAP, Should the (per country) COA design be done with Global reporting in mind or local GAAP compliance. If I go down the route of local GAAP I have 35 different potential GAAP's to deal with making COA maintenance and Global Reporting a nightmare.

Another thought is to record entries on the AA ledger compliant with Global Reporting and then use a secondary Local Ledger (LL) for making local GAAP related adjustments. The corporate financial statements would report off AA ledger and any local statutory reporting using (AA+LL).

i.e. if a JE is booked on account X in AA , in LL ledger the reversing entry will reverse the entry on account X and then hit accounts Y & Z. This way corp reports (using AA) will show the JE on X and any offsets while the local statutory (AA+LL) will show Y&Z with any offsets.

The approach mentioned above introduces complexity but I have not come up an easier solution. Any insights from your experience are appreciated especially in Italy.

Thanks,
KS

JDE 9.0 Update 1, 8.98.3.1 on iSeries

 

[panadm]

Or to put it simply..Our Controller in Italy and their Audit partners are saying that that AA ledger should be driven by the statutory account structure and not by the Global COA account structure.

KS

 

[Alex Blasenheim]

KS,

I’ve been involved with several International implementations. One of the biggest factors in each of the implementations was how the global consolidation was done.

In one scenario, the COA was built based on the localization requirements. However, a set of both Business Unit category codes and F0901 reporting codes were reserved by corporate. These codes were then used to pull and summarize the global requirement line items and eventually imported into both JDE Corporate and Hyperion. The local Financial team needed to understand how these codes worked so that whenever new accounts were assigned, these were setup properly. Besides a custom report that pulled the “categorized” data, there was a “kick-out” report showing any accounts not categorized. I did not design this system but was very impressed because maintenance was kept to a minimum. I did the fun part. I implemented the global piece in each of the countries! One important factor: always work with a business partner of the local country. Because the COA was setup for local requirements, there was far less customized work for the local business partner to do! This was a big cost savings.

In a second scenario the COA was built based on the Global Requirements. Every country had to adhere to it up to level 6. In some countries this worked fine. In others, what we did was a simple index allocation at the end of the close into another company where the COA was setup for localization purposes. The same AA ledger type was used and adjustment entries were made at this point. This was especially useful where the fiscal year was different! Global reporting was simple because all corporate needed was balances of all level 6 accounts. I implemented this scenario for 3 different Global companies. Global reporting was done in JDE for one and I do not remember the other two. Because the COA was setup for local requirements in the “allocated” company, there was far less customized work for the local business partner to do! This was a big cost savings.


In a third scenario, the COA was built based on the Global requirements. Local requirements were based on a combination of a different ledger like you described, several custom reports had to be written by the business partner. I thought (but I was wrong) that this scenario would be advantageous as adjustments can easily be made during the month and not at month-end. Only some allocations were needed and the category codes were heavily used. I recently ran into a consultant who I worked with on this project. She indicated that it took several months to get all the kinks out but the client is now pretty stable.

A fourth scenario, the COA was built for local (USA) requirements and we used a series of multi-tiered allocations and custom reports to feed into corporate (Germany). At every month-end close the US corporate controller would test all the complex allocations in a test environment and when satisfied, ran it in production. I was not overly thrilled with this scenario but I was only involved on the US local side. Global corporate did not care how the US COA was setup as long as they received their set of spreadsheets in their format.

The bottom line is to come up with a scenario that involves the least amount of human interaction with high efficiency and of course satisfying all requirements.

 

[ccornagg]

Hello,

I think your Italian controller is right.
Here you are a simple list of topics explaining why it's really advisable to have AA ledger for IT-GAAP and AA+AnotherLedger for US-GAAP:

1. Here in Italy we have to print / provide a GL Legal Book (see standard R09404 working on F0911) where all GL transactions are printed, thus it's not sufficient to get a balance reclassification at period end. As you know all GL transactions coming from AP / AR modules can be booked in AA ledger type only. As a consequence AA (Actual Amount) is the main ledger type in JDE framework, and the main ledger type should (IMHO) be printed in the Legal Book.

2. The ledger type management is usually not sufficient to gain a correct result on Italian Statutory and Fiscal perspective. The other important item to be sorted out is the different inventory logic in GL. I would advise to have a look at the difference between perpetual vs periodic inventory methods (see http://ccba.jsu.edu/accounting/perpetualperiodicje.html). In essence: JDE standard is based onto "perpetual inventory logic" while in Italy your balance sheet should reflect "periodic inventory logic" JEs.

Kind regards,

Carlo

 

[panadm]

Hi Alex & Carlo,

Thanks and I appreciate you taking the time out to respond to my query.

Alex, We are already using COA Category Codes to extract data from all companies for Global financial consolidation in Cognos and that is working fine. I am also using Cat Code 21 for Statutory reporting in Spain without issues. Along with Global Consoldiation I am also trying to standardize the processes so that ongoing maintenance is easier, to your point. I wish JDE supported functionality simailar to what they have in Oracle apps for secondary ledgers and accounting methods builder.

Carlo, you are right about the R09404 requirement and using AA Ledger as the basis for that. Are you aware of of any regulatory requirement that would stop me from modifying R09404 to use an (AA+LL) type approach to print all activity (including the adjustments from AA to LL). I'm not able to justify to myself why this would be an audit issue with the detail available in JDE but I might be overlooking something.

Thanks and a Happy New Year to the jde list community

.

KS

 

[ccornagg]

Kulvir,

I did not say you have to modify/customize R09404: you can use the standard UBE and change your data selection to print AA and LL ledger types together if you want. That's not the issue.

The headache is on how to exclude / prevent from printing (not only within R09404, but in any Fiscal/Legal Balance Sheet) some object accounts / GL transactions you have in AA ledger type, when AA is your US-GAAP.
That's the reason why I was mentioning the perpetual vs periodic GL entries differences (IMHO a key concept you cannot do without if you want to gain a good result from your JDE implementation).

Just to give you some examples:

1. If you setup AA Ledger Type to be your US-GAAP, you will have DMAAI 4220 driving COGS (Cost Of Good Sold), while COGS object account does not exist in periodic inventory framework.

2. If you setup AA Ledger Type to be your US-GAAP, you will have DMAAI 4310 driving Inventory (that's a BS account), while a "Purchases" (P&L account) object account should be used in periodic inventory framework.

In essence you can use two implementation approaches to try surviving with both periodic and perpetual inventory systems in a unique framework:

A. Obtain the "perpetual" / US-GAAP by summarizing AA and another ledger type.

B. Obtain the "perpetual" / US-GAAP by using AA ledger type only, but driving some object accounts (see for example COGS) to a different range (see for example prefix 9 within OBJ field) to allow an easy exclusion of them for local accounting purposes.

Kind regards,

Carlo