I was recently contacted by the accounting manager of a large distributorship that used SAP to enter the journal entries forwarded to it from 15 subsidiaries. She wanted to know the best way to handle journal entry posting in such a situation -- do you keep it at the corporate level and risk a bottleneck when the corporate department is flooded with postings, or force this task back down onto the subsidiaries?
My response was:
- Normally, it makes sense to centralize journal entries with the smallest number of G/L accountants, since they are experts in making such entries, and can therefore minimize journal entry errors and duplications.
- Since G/L entries have become a bottleneck operation, you have two choices: beef up your corporate G/L data entry capacity or push some or all of it back onto the divisions. Here are the ramifications of each:
- Adding more corporate G/L staff requires a greater expense, and since this is a cost center, will not go over well with your CFO if there are any viable alternatives that do not increase costs. On the other hand, you will have greater control over the accuracy of the entries being made.
- If the journal entry volume only somewhat exceeds the capacity of your G/L staff to handle it, then consider dumping smaller, less consequential entries back onto the divisions while retaining responsibility for all remaining entries. This will require you to open access to the SAP journal entry capability, so more people will have the ability to make entries, which will probably increase the error rate. However, by restricting the divisions to only the easier and smaller dollar-volume entries, it will be less likely for them to make erroneous entries. This is probably your best option.
- If you just want to unload the whole function onto the divisions, be aware that error rates will increase, which will call for the use of more training at the division level, procedures, error checking, and probably an occasional internal audit. Because of all these factors, this is a less viable option.