global chart of accounts lessons learnt from 15 years global implementations hans kolbe, celantra...

Global Chart of Accounts

Lessons Learnt from 15 years Global

Implementations

Hans Kolbe, Celantra Systems Inc.

NorCal GEO Training Day August 2012- Copyright Celantra Systems

Celantra Systems: Celantra Systems provides international program management services with a strong focus on multi-org, inter-

company, global compliance and implementation issues. The key element in our approach is the alignment of

operational efficiency, legal/tax compliance and management reporting. Our goals are: - Single global structure across country, currency, language, accounting and tax regime

- Variations are transparent to operator and business user community

- Flexibility for business growth, acquisitions, or other changes in business or legal model

- Ease of support and upgrade

Former and current clients include GE, Trident Microsystems, Terex, UPS, Xerox, Tektronix, British Telecom, Assa

Abloy, Yahoo, Texas Instruments, PPG, State Street Bank, Xilinx, Dionex and others.

Hans Kolbe has managed and advised software implementation projects for over 15, global projects for over 12

years. His extensive knowledge on Oracle applications is combined with a formal background as a German attorney,

trained in international and comparative law.

E-mail: [email protected] Ph: + 1 (415) 730 - 1131


1. Chart of Accounts – Fundamentals

2. Examples and Compromises

3. International Statutory Accounting – Legal COA

4. Local Details in Global COA – example Banks and Tax

5. Additional Reporting Dimensions – which way to go?

6. Are we really locked into our COA structure? How to

make changes

7. Conclusion

Agenda


Section 1COA – Fundamentals


What does the Chart of Accounts provide? 1) Reporting Structure (Dimensions)2) Framework for Global (finance) Processes

Chart of Accounts for Multi-Nationals


A Global Chart of Accounts supports consistent global reporting A Global Chart of Accounts supports consistent global processes.

You can write a standard set of financial reports that each location in each country around the world can run.

You can design a set of standard accounting processes (for example vendor or customer invoice accounting) that each location in each country around the world can run.

YOU CAN FOOL YOURSELF OR BE FOOLED: • Some companies ‘think’ a global chart of accounts means that every set of books has the same

number of segments and they are called the same thing, but underneath they all have unique value sets and different values.

• Some companies think that a common chart of accounts allows each country to define their own values in a sub account.

• In both of these cases, the standard financial statement reports will not yield any benefit. If all segment values are not defined in common value sets you have not achieved your goal of a common chart of accounts design.

• Single, global chart of accounts, means one accounting flexfield structure, one set of value sets and one set of values used worldwide.

What does single Chart of Accounts not mean?


It does not mean that all locations use the same accounts regardless of region, business, country? Accounts are only used as the location requires them.

It does mean that all variations and additional details for local business or legal accounting are pre-defined in the global value sets. Variations can be accommodated by

globally provided compliance tools.

It does not mean that all locations have identical processes.

It does mean that all variations and additional details for local business or legal accounting are pre-defined in the global value sets. Variations can be accommodated by

globally provided compliance tools.

Chart of Accounts – Fundamentals

Purpose of COA: • Reporting Structure (Dimensions)

– Financial Management / Budget / Analysis– Statutory Reporting (Source and Audit Trail for Filing)– Statistical Reporting (used for allocation)– Business Management (Projects, CC, Line of Business,

Region, Sales Channel….)

• Structural Backbone for Global Processes– Enforce global financial structure and parameters

(processes) – Capture required global data elements (Reference Data)


Chart of Accounts – Constraints

Constraints • Capture all required dimensions and data elements

– Allow sufficient detail for local statutory reporting– Needs segment for each reporting dimension– Allow sufficient length for details and roll-up structure

• Simple, short, easy to understand & train, truly global – Minimize overhead in operational processing fewer

and shorter segments are easier– Minimize adjustments to standard reports maximum

length approx 28 chars

There is no Right Answer! It is a balancing act!


Chart of Accounts as Reporting Structure

Global COA Structure needs to be Augmented − Secondary COA structure for local legal / fiscal reporting

− Additional Trial Balance reporting by business unit, product line

− Additional financial reporting dimensions on Revenue, Margins, Budget to Actual

− by Region, Country,

− by ProdLine, Cost Center,

− project, customer, sales channel

−So - Do I still need 10 Segments in my COA?


Chart of Accounts as Reporting Structure

We have additional reporting tools that can be integrated

Challenges – to resolve:

− Which additional tools are in scope and available? BI, Data Warehouse, HFM?

− Synchronized configuration between systems and instances, COA &ERP structure

− Reconciliation between the results in different tools!!

− Global Data standards are needed for all of them (Item Master, Costs, Customers, Vendors, Payment Terms, what else?)


Section 2Examples and Compromises


Entity XXX (3)Account XXXXXX (6)Cost Center XXXXX (5)Activity XXXXXX (6)Intercompany XXX (3)Country Code XXX (3)Product XXX (3)Service XXX (3)Regional XXXXXXXX (8)Future XXXX (4)

COA Structure – The Beginning, early 90s.

GL as financial data repository - major Financial Institution44 characters – 10 Segments


- No Oracle sub-ledgers. Operational Processes are not integrated to Oracle GL - Legacy Systems are used for daily operations – no Oracle COA is not the primary

structure.

- Extensive customizations are needed to map legacy systems to Oracle, i.e. “preprocessors”, customizations, workflows and interfaces.

- Consistency of financial reporting is enforced through technical mapping, not business and finance managers.

- Reconciliation, Drill-Down and Audit is difficult.

- Use of Oracle COA for operational processes is overhead intensive and cumbersome.

- Limited value from some of the segments. They are Zero-filled. - Cross-Validation Rules increase in complexity.


General Ledger as Data Warehouse

COA Structure – Now GL as backbone for primary ledger (transaction structure) –

Example 19 characters – 5 Segments

Suggested Global COA Segments (Transaction Dimensions) − Balancing (Company) Segment – Required – 3 digits− Natural Account Segment – Required – 6 digits− Cost Center/Department Segment (roll-up to Dept) – 6 digits− Product Family Segment (roll-up to Prod Line, Bus.Unit) – possibly include

projects - 4 digits− Intercompany Segment (required for AGIS) – 3 digitsTotal 19 digits COA.

Discussion Points: Reporting requirements by Bus Unit or Location (TB, P/L, Balance Sheet); Management

Segment Location (included in cost center?) – 3 digits Sub-Account Segment needed? (for local and stat detail) – included in natural account

segment? . First 4 digits for global values (corp consolidation), last 2 for local detail. Projects Reporting, Product Line reporting in Prod Family segment, and in Hyperion and

sub-Ledger Customer / Region Reporting – P/L or Margin – to be done in Hyperion and sub-ledgers


Section 3Local Statutory Accounting Separate Segment Needed?


Local Statutory AccountingRequirement: Many countries have legal prescribed preferred COA

(France, Brazil, China, Belgium) or preferred

Do not use a separate local legal segment – it is not needed and will punch a hole in your single COA.

Option A) Use Secondary Ledger R12

Option B) Use GL Detail consolidation functionality to transform COA and accounting rules

Worst Case: Primary Ledger is in Local COA; consolidate to corporate COA. This means we are admitting defeat. No the mapping table becomes the guarantor of correct corporate

reporting.


Section 4Local Detail Values


Section 5Additional Dimensions –

which way to go?



Use of Subledger Accounting for Management Reporting- An On-Line Discussion I. Starting Point and Business case: Client: US based Multi-National with multi-tiered supply chain, 18 countries. Application Footprint: EBS Financials and Supply chain including FA. Some CRM; BI and Hyperion Reporting/Planning in later phase. No Projects modules. Implementation path: Greenfield Oracle, migration from SAP (50% of BUs; rest from various other systems). Some shared services in P2P and OM/AR. Current phase: Design of COA – Multi-Org, Project Plan. Multi-Org is decided and clear. For COA we decided on at least 5 segments – Balancing, Nat. Acct, CC, ProdFamily, Interco. 3 other segments are in discussion: Subaccount (for local detail), location (possibly derived from CC), BU (probably can be derived from Prod Family). Other desired reporting dimensions are: Customer Grouping, Final Ship-to Region Grouping; Project Grouping.

I am about to suggest that we build a secondary COA structure with all necessary dimensions, setup secondary ledgers with the expanded COA, and use subledger accounting to fill the additional segments wherever we can.

Exploration: we need 9 segments for reporting, but want only 5 for operations (R12 Secondary Ledger-SLA)


PROS and CONS of Secondary Ledger (SLA) for management reportingMy PROs: •Create additional management reporting structure which will reconcile to the primary GL. •Keep primary COA slim and efficient•Encourage business immediately to define global data and rules to establish consistent management reporting parameters and matrices. SLA rules can be the base line for later phases to build BI and Hyperion rules. •Use SLA functionality of simultaneous posting to both ledgers where it is useful.

My CONS: •I have not used SLA in this way before. I don’t know anybody else who has. •We will have to build SLA rules for everything – because I have more segments in the secondary ledger. •There may be some duplication of effort, when BI and Hyperion are introduced later. That actually does not worry me, because we will have the main work done (mapping, define business rules) and establish consistent data. Please give me some thoughts of encouragement or talk me out of it. We will present preliminary design to the CFO next week, but I can leave this issue as “under investigation” for now.

R12 Secondary Ledger-SLA for management reporting


From Oracle – Architect of SLA – General Philosophy:We weren’t thinking of using SLA / Multiple Ledgers in this way at design time. We were thinking of the basic model being Corporate first with national reporting as an automated but secondary output. There were some caveats to that: we knew you can’t always do corporate first, so the reverse would often be true, so we consciously approached that too. And we read corporate as being both external and management, as the management numbers are used to drive decisions that are in the shareholders interest. But we weren’t thinking not to do it that way either. So theoretically, your proposal should work. I like your pros and cons. There is no necessary relationship between the primary coa and secondary. they need not have any segments in common. they need not have any value sets in common. the primary can have 3 segments and the secondary 12, or vice versa

only catch is that the further apart the charts are, the more difficult it may be to derive the secondary from the primary. this doesn't mean you can't do it, just means you will have more work setting up SLA rules. also remember that for journals that originate in GL like manual journals and allocations, all you can do is rely on a chart of accounts mapping. deriving 12 segments from 3 would be tricky unless you are going to populate an N/A value into about 9 of the target segments



Another Oracle Voice: “ Using a secondary ledger as a "thick ledger" is a valid option however; it probably depends on the specific customer requirements. An alternative approach would be SLA Supporting Reference Balances. The implementor can configure SLA to capture Customer Grouping, Final Ship-to Region Grouping and Project Grouping on the primary ledger's SLA journal lines and calculate balances for them. The advantages of the secondary ledger approach are...- tracks balances in both entered and accounting currency (supporting reference balances are accounting currency only)- can perform GL revaluation at the level of Customer Grouping, Final Ship-to Region Grouping and Project Grouping- can use GL allocations to re-distribute amounts to Customer Grouping, Final Ship-to Region Grouping and Project Grouping - out of the box reporting (and optional integration with Hyperion)



Another Oracle Voice Continued: The advantages of supporting references balances are...single ledger and therefore...

lighter solution less maintenance (of COA mappings) less reconciliation The disadvantage of supporting reference balances is that there is no out of the box reporting in R12 (although it is a candidate for a future version - no promises, no dates)

In both cases, you will have established a management reporting structure; the primary COA remains slim and efficient; and there will be global data and rules.Either way, you will need SLA rules for everything however; the architecture of SLA is such that it should be possible to build simple mapping sets that convert from Customer Grouping, Final Ship-to Region Grouping and Project Grouping attributes (or descriptive flex) to the corresponding account segment values and share them across all rules (SLA is very modular in its setup - almost everything can be shared).

I thought of another advantage of the secondary ledger approach - you can build GL hierarchies on Customer Grouping, Final Ship-to Region Grouping and Project Grouping and report on them using standard financial reporting tools.”


Section 6Are we locked into the

COA? Future Segments usefulness? Tools


Tools are available and have been used for 12 years:


Common Experience: The technical aspects are normally not the key problem. Business group agreement, executive management backing and project time line are key. Therefore even for many R12 re-implementations the COA is not changed.

Technically some changes can be simple - Extending a segment - Adding a segment (we do not recommend a future segment):

Others are more difficult: Removing segments, redefining content etc.

Standard tool available – Eprentise; there may be others.

Thank you !

Hans Kolbe, Celantra Systems [email protected]

+ 1 (415) 730 – 1131


mailto:[email protected]

global chart of accounts lessons learnt from 15 years global implementations hans kolbe, celantra...

Documents

global compliance

global projects

chart of accounts fundamentals

copyright celantra systems

consistent global reporting

single global structure

consistent global processes

global finance processes