There are some critical issues when designing a set of books in a multi OU scenario especially if the OUs operate in the same country.
For example, let us say that you want to create 4 OUs for the Indian Operations. Since the Chart of accounts, Calendar and Currency are the same, the standard procedure is to create a single set of books and link it to each of the OUs differentiating the OUs through the value of 'Company' segment in the chart of accounts.
However the above approach has two associated issues. The first issue is related to the period closing. While each OU tracks their receivables and payables separately, they would like to close the sub ledger periods once their transactions are completed. However this cannot be done in the above scenario since OUs are linked to the same set of books and closing the period in one OU will prevent other OUs from transacting further in the above set of books.
The implication is that in the above scenario, you can close the period only if you complete the transactions in all the OUs. This may not be acceptable to the customer.
Another issue is related to the 'Document Sequencing'. Since the document sequencing is set up at the SOB level, you cannot design different document sequencing rules for different OUs. In this scenario, for example, Payables Invoice No 10002 will pertain to OU1, 10003 to OU2 etc. This has significant audit and control issues and normally auditors object to this solution.
How do we handle this situation?
The solution is to have separate Set of Books for each of the above OUs and get the financial reports from a consolidated set of books which consolidates data from each of the above set of books. Though it appears complex, this is in reality a very simple solution from mapping point of view.
However there are some problems associated with this solution. First of all, this is counter intuitive. If you look at it carefully, this is equivalant to the OUs maintaining their independent books and hence goes against the concept of 'set' of books. In addition, you have to do period closing for multiple set of books and also for the consolidated set of books. Since the consolidated set of books is not the responsibility of any OU, it might get neglected.
Another related issue is the intense knowledge transfer required in the above scenario. There should be a clear KT processes in place to replace the user in charge of running the consolidation process.
For example, let us say that you want to create 4 OUs for the Indian Operations. Since the Chart of accounts, Calendar and Currency are the same, the standard procedure is to create a single set of books and link it to each of the OUs differentiating the OUs through the value of 'Company' segment in the chart of accounts.
However the above approach has two associated issues. The first issue is related to the period closing. While each OU tracks their receivables and payables separately, they would like to close the sub ledger periods once their transactions are completed. However this cannot be done in the above scenario since OUs are linked to the same set of books and closing the period in one OU will prevent other OUs from transacting further in the above set of books.
The implication is that in the above scenario, you can close the period only if you complete the transactions in all the OUs. This may not be acceptable to the customer.
Another issue is related to the 'Document Sequencing'. Since the document sequencing is set up at the SOB level, you cannot design different document sequencing rules for different OUs. In this scenario, for example, Payables Invoice No 10002 will pertain to OU1, 10003 to OU2 etc. This has significant audit and control issues and normally auditors object to this solution.
How do we handle this situation?
The solution is to have separate Set of Books for each of the above OUs and get the financial reports from a consolidated set of books which consolidates data from each of the above set of books. Though it appears complex, this is in reality a very simple solution from mapping point of view.
However there are some problems associated with this solution. First of all, this is counter intuitive. If you look at it carefully, this is equivalant to the OUs maintaining their independent books and hence goes against the concept of 'set' of books. In addition, you have to do period closing for multiple set of books and also for the consolidated set of books. Since the consolidated set of books is not the responsibility of any OU, it might get neglected.
Another related issue is the intense knowledge transfer required in the above scenario. There should be a clear KT processes in place to replace the user in charge of running the consolidation process.
No comments:
Post a Comment