It amazes me that GL conversions go so wrong so often. The recipe is straightforward and if the legacy data is good enough, there is rarely an excuse to have trouble during GL conversions. Yet, I’ve seen quite a few go off track. So in this series of posts, I’d like to talk about the critical points to doing them correctly.

What we’re converting

In general, most GL conversions are done on a period by period basis to ensure that the trial balance, P&L, and balance sheet are correct for the periods in question. Usually line item detail is left behind in the legacy system. So at the end of the conversion process, I should have worksheets that tie out each new account balance drilled down to the relevant cost objects and profit center for each period.

Let’s suppose that we have a GL conversion from a legacy system to our SAP GL that is supposed to span three years of data – 2011, 2012, and 2013 (YTD). We cannot just start with 2011 though. The end balance sheet for 2010 must be loaded to ensure that the starting position is correct. The P&L for 2010 does not necessarily need to be loaded as long as retained earnings is loaded correctly.

The GL conversion process

GL Conversion Process (ETL)

The GL conversion process is usually done in three steps that follows the acronym ETL. First, the existing GL balances are extracted from the legacy system. The balances data is placed into a staging location. This location could be a simple as a flat text file on a file server or as complex as complete database system with a web front end.

Next, the data in the staging table is transformed from the legacy GL characteristics to the new SAP GL characteristics. This step is accomplished with mapping tables that take the legacy value onto the SAP value.  These mapping tables can become exceedingly complex if the logic is ugly.

Third, the transformed data is loaded into the new SAP system. This step is usually done with an LSMW that injects the standard GL posting program, but I’ve also seen other methods such as Idocs and recordings. At this point, all of the GL data should be loaded into the SAP system.

Key checks in a GL conversion

Throughout the GL conversion process, it’s important to ensure that each step succeeds. At the absolute bare minimum, when the data is loaded into the new SAP system, it’s critical to ensure that legacy balances match the new SAP balances per each costing object and period and in each relevant currency. It’s much better though to make checks throughout the process. Often times, a few heuristics will detect problems much earlier. A couple suggestions:

  1. Debits=Credits. If your trial balance doesn’t balance at each step, something is obviously wrong.
  2. P&L matches. The P&L should always match throughout the process. If it doesn’t, something went wrong.
  3. Assets, Liabilities, and Equities match. Each major class should
  4. All values mapped. Once the transformation step is complete, all accounts, company codes, cost objects, etc should be mapped. If any aren’t, the mapping table isn’t complete or there is a bug in the transform logic.

Finally, it’s incredibly important to ensure that the roll-up of the legacy accounts and cost objects matches that of the new SAP system. That means ensuring that an account that is mapped as an asset in the legacy system is still mapped as an asset in the new SAP system. Even more complicated, it means ensuring that a profit center in a management entity is mapped to the same management entity in the new SAP system. Usually the consolidations team will have a lot to say here.

Each mapping of GL accounts should preserve the account group

In our next installment of Performing GL Conversions Correctly, we’ll explore a standard journal entry flow and how to handle sub-ledger accounts.