In this ever-changing world, finance departments have to play a much bigger role than just regular bookkeeping. The CFOs of organizations, whether small or large global companies, have to constantly keep on reorganizing to the changing environment. Gone are the days when you would consider a finance transformation initiative just one time and hope that you are done.
Consider a very common scenario. You have already gone live in the SAP system a few years ago. You would have started with an initial base configuration setup and then over time built on that. Maybe you expanded into different countries and rolled out more functionalities. Within finance that means you would have started with the base chart-of-accounts (COA) setup and then gradually expanded the use of general ledger (G/L) accounts. It is very common to see that in very short span of time, your COA would have expanded considerably. Add to that the complexities that the same account is being used differently by different groups or, if you are a global organization, by different divisions with multiple ERP instances using different standards.
In a situation like this you have only two options – completely reimplement the SAP system from scratch with a fresh new COA, which is a complex scenario and a non-starter in many situations, or a conversion.
The most effective and viable option is to consider a COA conversion. The standardization and rationalization project is a considered as a System Landscape Optimization (SLO) initiative in which you convert the G/L accounts in the live SAP system, including all the associated transactional data. This transformation and data conversion make the system transform to global standards, including the historical transactions that will look as correct as if they were from day one.
A point has come at which a simple configuration decision made many years ago is inhibiting the useful life of an organization’s system.
For example, one of our customers has a four-digit COA. Its old legacy system had fewer than 1,000 G/L accounts and setting of an SAP system with 10,000 G/L accounts sounded reasonable to accommodate the possible future expansion. Accordingly, this client set the four-digit G/L accounts (0000 to 9999). Over the period of years, the business has expanded and realized limiting the COA to four digits is not enough and now, you want to expand the G/L accounts use and want to convert all the Financials including the historical balances.
Another customer is a global giant with a complex technical landscape, with each business unit having multiple ERP systems. Each business unit has its own COA master data. You want to establish global enterprise-wide standards for COA and want to convert all the ERP systems, including all the application data.
Another customer wants to embark upon an SAP General Ledger and SAP S/4HANA journey. You want to take the opportunity to clean up and standardize key processes or data and as part of that, you want to rationalize COA and want to do the COA conversion to get ready.
(In this article, I demonstrate the approach with an example of a COA for a G/L account; however, the concept, approach, and methodology are the same for other transformation initiatives, such as a currency conversion, fiscal year/period conversion, Controlling [CO] area merger, and standardization of other SAP objects.)
In situations like this, intuitively you would think of simply changing the configuration by, for example, making the G/L account length of eight digits or even 10 digits. Sure, but that works only for going forward, but what about old balances? Transferring the balances from an old account (for example, account 1001) to a new account (for example, account 10010000) will not work as these may be customer invoices, vendor payments, or account configuration. Also, changing the configuration does not fix your old historical transactions or in-transit transactions.
For situations like these, there are no standard tools, programs, or transaction codes. The usual options, such as creating new accounts, posting re-class adjustments manually, or reimplementation, typically only offer workarounds that often offer extremely rudimentary business value, as described in Table 1.
- Many times not even possible
- May require re-implementation, basically defeating the business value
- Disruptions to business processes
- High level of manual efforts
- High costs to support the organizational initiatives
- Extremely slow and time-consuming deployments
- Multiple interruptions and less continuity
- Data flow lost
- Most effective and efficient approach, including old historical open transactions
- Absolutely minimum business interruptions
- Minimum manual efforts
- Able to leverage existing investment in systems/processes
- Rapid deployments
- Continuity and stability
- Data flow continuous
A comparison of traditional and transformation approaches
The most effective approach is with a transformation approach using SLO tools. SLO transformation tools transform the system and align the database, including all historical datasets according to uniform standards.
From a technical perspective, it’s a fairly simple concept. Technically, the conversion process converts all the old account values to the new values. A find-A-and-replace-with-B approach will find any instance of old account A and will replace it with new account B.
(Note: Systems Landscape Optimization [SLO] is a collection of ABAP programs. I call these programs SLO tools. These programs are built by SAP consulting firms or even the customers can develop these programs. However, the focus of this article is about the key considerations you need to plan carefully.)
The conversion process must cover all the application data (master data, transactional data, and even configuration data) and even should cover standard as well as custom data (Z objects) as shown in Figure 1. Monday morning business processes will work very smoothly, as if nothing had changed.
Chart-of-accounts (COA) conversion
(Note: In Figure 1 INT stands for international.)
COA Best Practices
The COA conversion involves database-level changes and needs extensive system resources to manage the conversion. However, technical data conversion is just a fractional part of the overall project. The overall COA conversion project has a significant business impact with changes to global design, data cleanup, and change processes to adapt to standardized business processes, core integration, change management, and more.
Although COA conversion sounds like a technically focused process, actually it has a significant business impact and accordingly the COA conversion project should cover much wider aspects, not just the technical conversion.
In this section, I want to elaborate on some of the best practices you must consider when planning your COA conversion initiative:
- Global enterprise standards and design
- Comprehensive scope – data/processes/technologies
- Key focus on mapping rules
- Data consistency due to mixed-bag account merges
- Consistency of financials data and processes
- Business validations (pre and post comparisons)
- Plan the COA conversion weekend
- System downtime considerations
- Consider the impact to custom Z objects and interfaces
- Get ready for a smooth transition with a seamless change-over
- Comprehensive approach to COA conversion
Global Enterprise Standards and Design
You have used your last chart for the last 20 years; more likely you will be using your new chart for the next 20 years or more, so plan your future global standards carefully. Consider the impact of upcoming initiatives, such as the SAP General Ledger (SAP S4/HANA, 606 accounting standards [i.e., FASB 606 standards, especially those impacting technical industries, refer to Revenue Recognition treatment], and more). Also, evaluate the impact of International Financial Reporting Standards (IFRS) local or country-specific accounting requirements and make sure the chart design offers flexibility and future expansions.
Comprehensive Scope – Data, Processes, Technologies
Note that the conversion must comprehensively convert all the underlying data. It is very common that some SLO tools convert master, transactional, and configuration data, but, miss many other objects and processes. G/L accounts are extensively embedded in many processes, such as Sets and Hierarchies, Cost Element Groups, Financial-Statement-Versions (FSV), Validations/Substitutions, Account Ranges, CO masked Accounts and many such special objects. Some such examples of special objects are shown in Figure 2.
Comprehensive scope covering some sample special account objects
Key Focus on Mapping Rules
In simple terms, the conversion process converts all the old account values to new values (Find-A and Replace-B). The key input to the conversion process is this mapping of Old-Account-value and New-Account-value.
Mapping (mapping of an old account to a new account) plays a very critical role for conversion. Depending on the accounts rationalization design, the mapping will be one-to-one (account rename) or many-to-one (account merger).
As part of this transformation initiative, doing a cleanup is a good idea, and the best practice is to remove unwanted, redundant, and duplicate G/L accounts by merging multiple accounts into one as shown in Figure 3.
Account mapping with account rename and account merger
Data Consistency Due to Mixed-Bag Account Merges
However, utmost care must be taken so that you do not merge accounts with different attributes. For example, if you must merge two source accounts into one target account, if one of the source accounts is open items (OI) managed and the second source-account is NON-OI-managed then the target account will end up with both OI and NON-OI line items. As you know, OI-managed accounts have line items marked appropriately for follow-on clearing processes, whereas non-OI-managed accounts do not. Therefore, merging such mixed-bag accounts causes major process issues post-conversion, with the target account having both types of line items. Although technically it may appear correct, the business process just crashed.
There are many such possibilities for inadvertently merging multiple source accounts with diverse attributes into one target account causing serious data inconsistencies. In my experience, one of the major problems with some SLO tools is the lack of such warnings. Make sure you have strong and robust analytics available to avoid such situations that cause inconsistent data.
Consistency of Financials Data and Processes
The COA conversion must preserve the integrity of financial data. Even after the conversion, Finance leadership needs to know the process preserves your legal book of records. The use of accounts must remain the same with the COA conversion; in other words, the account used for a specific business purpose must retain its usage. Existing business processes should not be negatively impacted.
Plan the COA Conversion Week-End
A very detailed and thorough conversion cutover plan must be in place with detailed step-by-step cutover tasks planned and executed. It is a standard procedure to practice test dry-run conversions. Figure 4 shows a visual representation of the cutover weekend and the step-by-step cutover must be executed for a smooth transition.
Typical COA conversion cutover
Business Validations (Pre and Post Comparisons)
The COA conversion methodology should support the extensive and granular-level of validations. Business users should not be expected to manually check millions of data records and should be able to validate with some spot checks and quick validations. Also, it is very likely the COA conversion must provide detailed audit controls and validations to be passed by internal or external auditors. The systems audit team is looking for a complete and accurate comparison of before and after conversion results and the project team should design and develop a comparative report to assure system and financials consistency. Figure 5 shows an example of extensive pre and post comparisons that provide audit controls and validations.
Pre and post comparison of Financials
System Downtime Considerations
COA conversion requires system downtime, and the COA conversion approach should support minimum system downtime. Technically, conversion is going to make a massive amount of data changes to the database and it is a very common practice to temporarily add system resources (memory, disk, CPUs), especially to large databases.
Consider the Impact to Custom Z Objects and Interfaces
Do not underestimate the efforts to adapt custom Z objects, such as custom Z tables and custom Z programs that are hard-coded for specific account values. These Z programs and Z objects must be adapted to be ready for your new chart. You also have to be very careful with the timing for making changes to these objects, to make sure the changes are effective only after the data objects are changed to new values. Similarly, you need to adapt custom interfaces to suit the new standards.
Get Ready for a Smooth Transition with a Seamless Change-Over
So, COA conversion go-live was smooth and successful. It’s Monday morning. Business users are used to looking at old accounts (for example, account A), so how are they expected to know or remember new accounts (for example, account B). As simple as it sounds, put in the place the change management processes to make the transition smooth and seamless.
.A Comprehensive Approach to COA Conversion
COA conversion is not just converting old account values (account A) to new account values (account B).
In addition to technical data conversion, the COA conversion approach must offer a comprehensive methodology as shown in Figure 6. The comprehensive approach offers a phased methodology with support for the following:
- An existing data setup
- Establishing new global standards
- Any data cleanup or process cleanup required to adapt to the standards
- Technical conversion
- Offering the most granular checks, validations, and audit controls
- Change management tools for smooth transition
Comprehensive approach to a COA conversion