When implementing multiple ledgers across many countries, it is a best practice, especially in release 12 and above, to have One SINGLE Global Chart of Accounts, using Secondary Ledgers for “local” chart of accounts and statutory reporting.
- Sub Ledger Accounting Methods
- Complexity in Mapping Rules from Primary Chart to a Secondary Chart
Subledger Accounting Methods
To understand why Sub Ledger Accounting Methods are important, the user should know what factors are combined to make a Sub Ledger Accounting Method, and how that ties to a primary ledger versus a secondary ledger.
A subledger method determines the accounting rules applied in the subledgers. Oracle has default rules that if left alone, pass through to the general ledger with no transformation.
A subledger method is defined using the combination of an “Accounting Flexfield” and “Transaction Flexfield”. All ledgers using the same Accounting Flexfield use the Same Transaction Flexfield, and can therefore use the same Subledger Accounting Method. A Secondary Ledger MUST use the same Transaction Flexfield as the Primary Ledger. This is true, because the Subledger are associated to the Primary Ledger, and NOT the secondary ledger.
Any Primary Ledger that uses a different Accounting Flexfield, by definition has a different Transaction Flexfield, and therefore cannot use the same Subledger Accounting Method.
When all Primary Ledgers use the same Accounting Flexfield, global accounting policies are easily applied. If a Primary Ledger uses a different flexfield (the local flexfield, for example), then global rules will not apply to that ledger. They will not be able to be applied to the secondary ledger, because the secondary ledger must use the same Transaction Flexfield as the Primary Ledger.
Therefore, any “Corporate Ledger” that is defined as a “Secondary Ledger” will not be able to follow corporate accounting policies without having totally custom SLA rules that can transform a local chart into corporate policies.
Understanding the above logic, there is no way to conclude that the Primary Ledgers should ever utilize a local chart of accounts, unless the company decides that company-wide accounting policies should not apply to the corporate ledger in that country. Assuming that corporate policies should apply across all corporate ledgers, the conclusion must be that a single Global Chart of Accounts permeates all primary ledgers, and use Secondary Ledgers to drive statutory reporting.
Secondary Ledgers can have their own SLA rules to override corporate policies based on business logic and account mappings from Primary into Secondary.
Accounting Flexfield to Transaction Flexfield Relationship
When an Accounting Flexfield is defined, Oracle automatically creates a “mirror image” called the “Transaction Flexfield”.
The Transaction Flexfield is what is actually used when defining subledgers.
If you build 5 accounting flexfields, you will have 5 Transaction Flexfields (all a mirror of its associated accounting flexfield)
When defining your subledgers, you DO NOT HAVE A CHOICE as to which Transaction Flexfield you can use.
Oracle automatically uses the Transaction Flexfield associated to your Accounting Flexfield which is associated to the Subledger’s Primary Ledger Assignment.
You cannot use the Secondary Ledger’s Accounting Flexfield for your subledgers.
With the understanding of this relationship, and the understanding that Subledger Accounting Methods are defined as a combination of Accounting Flexfield and Transaction Flexfield, if one Primary Ledger’s chart is different from other Primary Ledger’s, you cannot use the same subledger accounting method, and therefore the secondary ledger, if used as your corporate chart, cannot share corporate accounting policies.
In the simple example above, Ledgers 1 and 2 share the same Accounting Flexfield (AFF), and therefore the same Transaction Flexfield (TFF). The corporate accounting policies defined in the Subledger Accounting Methods are easily shared.
The secondary ledgers can either share the corporate accounting policies or use their own accounting policies, without having impact to the corporate accounting policies and associated SLA rules.
In the case of Ledger 3, the Accounting Flexfield is different. It is “Local”. It has a different Transaction Flexfield. The secondary ledger (now defined as the corporate ledger) shares that Transaction Flexfield, even though it is using the corporate accounting flexfield, because it is using the configurations from the subledgers which are “tied” to the primary ledger. The corporate accounting policies cannot be applied to this ledger. It has have its own set of Sub Ledger Accounting Rules, and to attain corporate policies, this could be very complex.
Complexity of Mapping Rules from Primary Chart to Secondary Chart
If mapping rules are “One to One” from primary chart values to secondary chart values, then implementing a secondary chart in a secondary ledger is quite simple. Then, users can either make manual reclassifications in the secondary chart for statutory reporting purposes, or the secondary ledger can have their own SLA rules to override values that are fed in from the subledgers based on business rules. You can use hundreds of attributes to determine what the accounting should be in a primary or secondary ledger through the use of Account Derivation Rules.
If mapping rules are complex, and you would have one to many mappings, then there are two possible solutions:
- Add accounts into your primary chart to facilitate the mappings (make them one to one)
- Use SLA rules based on the transaction attribute to determine how the accounts should map.
If the rules are too complex, it may be best to add the values into the corporate chart of accounts.
There is still no reasonable conclusion to set the Primary Ledger to your local chart of accounts given these options
Impact to a Global System if the Primary Ledger is Set to a Local Chart
Should the decision be made to set the Primary Ledger to a local chart, the client will not be able to easily apply corporate accounting policies against corporate ledgers, which would ordinarily all be in the primary ledger.
All subledgers would effectively have a unique Transaction Flexfield applied, making it virtually impossible to apply global rules.
Each secondary ledger would have unique SLA rules that would be potentially more complex than if configured in accordance with best practice.
The design, if changed “mid-stream” in an implementation, or even worse, after go live, may cause a butterfly effect of having to re-implement the entire system or restart the design of the system from the ground up. Either of these options will be very costly to the client.
Best of Both Worlds Solution
A segment in your chart of accounts called “local activity”
The global chart will then have a natural account (corporate chart) and a local activity.
Corporate can insert “000000” into the local activity if not required.
Each country can use the local segment by having their unique values in the local activity segment.
The chart of accounts can then feed “one for one” into the secondary ledger, and adjustments and/or subledger accounting rules can then be applied to the secondary ledger without design limitations on the corporate ledger or chart of accounts.
Use first 2 characters of local activity as country code.
Cross Validate “Local Activity” with Legal Entity to ensure data integrity. Use “Global Activities” prefixed with “99”. These are activities that all countries may have in common.
Proposed Design – Use a “Local Segment”, Maximize Flexibility, Maintain Corporate Charts Across Primary Ledgers, Utilize Secondary Ledgers for Statutory Reporting
- Adding a local segment into your global chart of accounts allows your client to maximize the functionality of a global chart of accounts and secondary ledgers.
- One common set of subledger accounting rules across the corporate ledgers for corporate accounting policies.
- Optionally add secondary sets of SLA rules to satisfy statutory reporting, and/or use manual entries for adjustments.