In the previous two articles on SAP GL conversions, we discussed the process of GL conversions, journal entry flows, and how to handle reconciliation accounts. In this final article, we’ll look at a couple pain points and keys to success that arise in SAP GL conversions.
In the GL, there is usually more than one currency type – say document, local, and group being tracked. See here for more information. While performing conversions, it’s incredibly critical to properly populate each currency type. Usually the local currency is the most critical to have correct as it is feeding consolidations, but other types should be considered.
The group currency tends to create the most trouble. If this value is tracked in the legacy system, then it can be populated in SAP. If the group currency isn’t being tracked, then a useful estimate should be created by populating a blended exchange rate
Account and Management Rollups
As previously mentioned, it’s critical to ensure that how accounts are classified and rolled up in legacy matches that of SAP. For instance, if the legacy system has an account “Rent Income” that is classified in the “Non Operating” section of the P&L, there would be a problem if the Rent Income account is mapped to the “Revenue” section of the P&L in SAP.
A similar issue occurs if profit centers and cost centers are not mapped correctly or if the hierarchies are not properly constructed. For instance, if a profit center A is mapped to division 1 in legacy, then it’s critical to ensure the activity is converted to a profit center in division 1 in SAP.
Correct Cost Objects on Correct Accounts
When the GL is designed, a structured approach is taken to what type of cost objects are valid for each account. For instance, revenue accounts require COPA segments or profit centers, expense accounts require cost centers, and balance sheet accounts require a profit center. It’s important that the conversion mapping respect the GL design and map the correct cost object to the correct account type, otherwise data corruption may result.
Just like a business process or custom development must be tested, likewise, a conversion should be heavily tested. Executing a conversion multiple times into a test environment enables finding errors, mistakes, and bugs prior to the conversion being finalized. That makes the final, production conversion much easier and much more likely to succeed in the given time frame.
Having more than one person validate conversions will help ensure that the data is correct. Also, be sure to feed the converted data into the consolidation system prior to go-live. Otherwise, unexpected problems will crop up when the data is fed to the consolidation program.
In this series, we covered the process, journal entry flow, and keys to success for performing GL conversion. I hope that you found this series helpful and informative.