Performing GL Conversions (part III)

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.

Convert Often

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.

Many Eyes

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.


Sivasankaran S says:

Hi David,

It’s a nice compilation of GL currency conversions, specially you have nailed on its head when it comes to emphasizing the critical need to ensure appropriate mapping of various GL accounts from a legacy to SAP master data mapping.

Many a times, I come across inappropriate mapping or classification of Profit Centers, Cost Centers during master data creation as business user has an aspect in mind, which is transformed rightly to the SAP team in terms of ‘relevance’ from the business perspective, and somehow it leads to incorrect mapping from a design point of view, end of the day, many users complain they aren’t happy with the way it has been rolled out. These are core issues that one must address in the design and development phase to avoid troubles during testing. Thanks a lot indeed!!

David says:

Hello –

Thanks for reading and commenting! You’re absolutely correct. It’s critical to have as many people involved in both the design and structure of the GL as well as validating all phases of the conversion to avoid such issues.

You also touch on another good point as well. The GL conversion is very much the proving ground to ensure that the design of the GL is done correctly. I also see this with asset conversions as well where the conversion digs up missing configuration and design.

Krupali says:

Hi David, your knowledge on group currency is very sound. We have very complex situation. We have LC1 = SGD and we are converting LC2 = USD through SAP SLO. While converting we need to reconcile the value with ECCS reported value (which is in USD). Now for reconciling ECC & ECCS Journal entry needs to be posted. Question is how to post this difference will be at each GL level or it would be at Group level. Example Fixed Asset APC account and accumulated Depreciaiton account will have difference between SAP FI & ECCS reported value. Quesiton is that for this difference posting should we create new GL account to group it with APC & Accumulated Depreciation account or should create dummy asset and post the value in LC2 so as to reconcile..

David says:

Hello –

Apologies for not responding quicker, things are a bit crazy. I’m not particularly familiar with ECCS. If you do have SLO involved, I would actually check with them as they should be able to give you better guidance than I could. Good luck!


Dana says:

I am working on GL balance conversion. I have not worked on this task before. It is SAP to SAP conversion. The client is being spun off from a larger company that was already on SAP. Can you please advise of best strategy to do balance conversion for balance sheet & P&L. LMSW will be utilized to load the balances. Only transactional & open item will be converted. No History. It will be about 3 -4 periods of transactional data. Can you please advise which tables to request balances from. For B.S accounts data should be posted at comp code, GL, PC level, correct? For P&L comp code, GL Cost center level. What other levels need to be considered. What is best strategy in preparing files to ensure balance is kept intact from what is received and loaded.

Leave a Reply