Written by Helene Abrams Tuesday, November 10 2009
Growing globally is an engrained goal of organizations that adhere to the principle of increasing shareholder value. New markets for product adoption often must be pursued across national boundaries as local markets approach saturation. Strategies must be developed to both create and manage operations overseas. One of the difficulties inherent in operating globally is that different localizations, such as regulations and currency, complicate business operations since the business must comply both with global and local policies. So, while the company must abide by localized tax laws and regulatory requirements, it is also important for management to maintain a concise view of financial performance of the company as a whole.
Enterprise resource planning (ERP) systems were developed as a solution to this problem, as well as other problems. However, complexities that result from international operations are still a major hassle, and there comes a point when a business must evaluate its current structure and determine if changes to the fundamental setups of certain ERP components should be undertaken.
Chart A is a depiction of the financial translation structure of a multinational corporation. It is clear at first glance that the structure of the company is forcing a difficult financial consolidation process, but it is worth taking a closer look at the relationships between the entities in order to better understand how time-consuming and error-prone month- and year-end accounting processes must be.
According to Chart A, the company has operations in the following ten locations: the US, Canada, New Zealand, Australia, Mexico, Brazil, Chile, Taiwan, the UK, and Russia. Reporting requirements mandate that the financial transactions be reported in multiple currencies, while maintaining drill-down capabilities to all the subledgers. In order to facilitate financial reporting based on both currencies and location, the company has structured a number of different units by which to categorize transactions:
- Operating Units – grouped by currency type
- Sets of Books (AAA and BBB) – grouped by currency type (AAA) and country (BBB)
These consolidations are grouped and ungrouped by a combination of spreadsheets and by using the financial consolidation in GL. Looking first at the AAA US Set of Books (marked in orange in Chart A), we can see that it is comprised of eight balancing segments that originate from USD transactions from eight different locations that operate with USD as one of their currencies. The financial translation from the AAA US Set of Books to the BBB Books involves separating the 8 balancing segments into 7 different new sets of books as the grouping method changes from grouping by currency (AAA) to grouping by country (BBB). What this means is that an accounting error made in the AAA US Set of Books could have far-reaching implications, potentially causing an error in 7 different BBB Sets of Books (US SOB, BBB NZ, BBB AUS, BBB TWN, BBB BRZ, BBB MEX, and UK SOB).
Another example is shown in green and involves an extra translation step. When the company first implemented E-Business Suite, they created a separate set of books for each currency (rather than have an entered currency translated to the functional currency for the transaction). The transactions for Legal Entity (Balancing Segment Value) 007 are in 3 separate sets of books: one for each currency. So, if the company wants to find out how LE 007 is performing, they have to consolidate all the transactions for LE 007 across all sets of books. When they bring that data into their OBIEE implementation, they need to do a join for every transaction across 3 sets of books. There is no drill down from their reports, and no way to determine the accuracy of the data entry on the spreadsheets.
These are just a couple of examples – imagine what a significant number of errors (they happen) in multiple sets of books would set off: it would resemble a chain reaction, the kind that a nuclear bomb undergoes before it causes virtually irreparable damage. Also imagine what happens as the company acquires a new legal entity, or wants to sell part of their business. No company wants to endure an irreparable financial mistake, certainly in today’s era of Sarbanes-Oxley, IFRS, and countless other regulations. The problem is that some organizations are sufficiently complex that avoiding mistakes involved in financial consolidation becomes impossible. It is a common occurrence, but one that is all too frequently overlooked.
In Oracle E-Business Suite R12, the company will have a primary transaction ledger and then create ledger sets to create the accounting for each of the reporting currencies. But, there is really no way of getting to a R12 subledger accounting function given the complexity of the consolidation rules currently implemented. The company is in the process of re-evaluating their legal entity structure, their operating unit structure, and moving to a global chart of accounts before moving to R12. They will use Multiple Organization Access Control (MOAC) to report from different operating units. They estimate that the close cycle will be reduced from their current 20 days to 3 days, that they will have increased visibility into the enterprise operations as a whole, and that they will reduce the number of spreadsheets significantly.
| < Prev | Next > |
|---|
Related Articles
Related Pages
Enter your email address to sign up for our Newsletter
January Puzzle
A traveler gets lost on a deserted island and finds himself surrounded by a group of n cannibals.
Each cannibal wants to eat the traveler but, as each knows, there is a risk. A cannibal that attacks and eats the traveler would become tired and defenseless. After he eats, he would become an easy target for another cannibal (who would also become tired and defenseless after eating).
The cannibals are all hungry, but they cannot trust each other to cooperate. The cannibals happen to be well versed in game theory, so they will think before making a move.
Does the nearest cannibal, or any cannibal in the group, devour the lost traveler?
Solution
The short answer is the traveler’s fate depends on the parity of the group. If there is an odd number of canibals, the traveler will be eaten, but if there is an even number, the traveler will survive.
To prove this, we will consider small groups and use mathematical induction to explain the solution for larger groups.
Case n = 1: this is an obvious case. If there is one cannibal, the traveler will be eaten. It doesn’t matter that the cannibal will get tired because there are no other cannibals around as a threat.
Case n = 2: this is a more interesting case. Each cannibal wishes to each the traveler, but each knows he cannot. If either cannibal eats the traveler, then he will become defenseless and the other one will eat him. So each cannibal uses backwards induction to realize that the only strategy is to not eat the traveler. The hapless traveler finds a bit of luck, therefore, and actually survives.
Case n = 3: this is where the problem gets interesting. The best strategy is for the closest cannibal to make a move and eat the traveler. The cannibal will be defenseless after eating, but ultimately he will be safe. Why is that? The reasoning is due to induction: once the cannibal eats the traveler, the resulting situation has 2 unfed cannibals and the 1 defenseless cannibal. But as we just showed above, when there are 2 unfed cannibals, neither will make a move for fear of being eaten by the other! Thus the first cannibal to make a move will be safe as the remaining 2 cannibals block each other.
We can prove the higher cases using mathematical induction. If the number n is odd, then the closest cannibal can safely eat the traveler because the remaining number of unfed cannibals is even (and by induction, with an even number of unfed cannibals no one makes a move). If the number n is even, then no cannibal will eat the traveler, for if he did, the remaining number of cannibals would be odd, meaning he will get eaten by the induction hypothesis.
Success Tips for Oracle Project Management
- Create a standard for documentation at the beginning of your project, and hold team members accountable for completing documentation requirements as well as keeping them at and above the standards required.
- Before promulgating user documentation or training, it’s also a good idea to choose a representative from the among the business users base to review materials first.
- If you are not sure about the resources and budget required, obtain several estimates from people that have experience with the same size and scope of your project.
- Be explicit, before beginning the project, what internal resources are required for execution. This includes people, infrastructure, hardware, and software.
- Help the project champion understand the impact your project will have on the organization and how its successful completion will make him or her an internal hero or heroine for supporting it.
- Break up your project into smaller projects (try for projects that can be completed in 4-6 months, especially early on) to get success and demonstrate momentum.
- Make sure that your testing includes reports, upstream and downstream interfaces, customizations, enhancements, and workflows.
- Ensure that comprehensive transition reports and meetings between departing and incoming personnel are completed.
- Instead of spending time and resources implementing third-party reporting, consider consolidating multiple instances, moving to a global chart of accounts (CoA), and/or standardizing on a consistent calendar.
- Include governance, risk, and compliance management as part of the project plan.
- Finally, celebrate the successes. Too many projects focus on defects, failures, or small cost over-runs without looking at the big picture and what was accomplished.
The Analyst Corner
John Van Decker, Research VP of Gartner, states:
"A single chart of accounts allows consistency in financial reporting across the enterprise by standardizing on common metrics and reporting structures, reduces dependencies on a separate financial consolidation system, and significantly reduces the costs incurred with ongoing, complex conversions and translations."
