A global SAP payroll system implementation that is integrated with a global SAP ERP HCM system can present many challenges. These challenges consist of both system- and configuration-related challenges as well as non-system and process-related challenges. Examples include:

• Globalizing the wage type catalogue
• Consolidating payroll areas
• Standardizing interface frameworks for data transfer between SAP ERP HCM systems and non-SAP payroll systems (in countries where an SAP payroll solution may not be available)
• Implementing expatriate or global employee processes and SAP system solutions
• Creating reusable content and libraries for leveraging work across countries

First I explain how the SAP ERP HCM system affects the SAP global payroll system. Then you learn about topics related to SAP global and local payroll systems, including global employee payroll. Finally, I address the unique challenges presented by the deployment and cutover of global payroll implementations.

SAP ERP HCM Framework for SAP Payroll

For a successful global payroll, you need a robust SAP ERP HCM system implementation. SAP ERP HCM in this instance means Personnel Administration (PA), Organizational Management (OM), Time Management, Management of Global Employees, and other similar non-payroll SAP ERP HCM modules. These modules are essential prerequisites for a payroll implementation. The following SAP ERP HCM system topics are relevant to an SAP global payroll system.

PA (Personnel Administration) Actions 

Here is a brief explanation of SAP ERP HCM payroll-relevant topics:

• PA actions. This is a mix of global and local actions. As per the principles of the global PA template, you have a list of global infotypes that are managed by global actions. In addition, local country infotypes may be managed using SAP transaction PA30 or through a local action.
• A globally sustainable enterprise structure related to company codes, personnel areas, subareas, employee groups, and subgroups.
•  Some payroll areas should be synchronized  as a part of the global agenda (this is discussed in more detail in my article, “Use a Global Payroll Strategy to Leverage the SAP Payroll System"). Payroll areas can require more effort and add time to payroll operations. Synchronizing some of the payroll areas requires work from both the payroll business side as well as the IT side.  For example, the payroll department needs to evaluate if payroll area consolidation is possible, keeping in mind company policies and union contractual requirements; IT needs to evaluate the impact of moving employees across payroll areas, including the impact on data conversions.

Once you have taken these variables into account, you should look for opportunities to consolidate payroll areas. There is value in consolidating pay schedules, especially if there is a regional shared-service center approach. You still need some separate payroll areas, but consolidating some payroll schedules helps reduce efforts and streamline the process. Therefore getting the payroll schedules and frequencies together is key to reducing time and effort.

A payroll area directly runs the payroll operations for that particular payroll area (i.e., inputs, processing, downstream processing, outbound interfaces, bank transfers, and finance postings). Therefore, every payroll area that is added in the system means more effort required of the payroll shared-service center resources. Any synchronization of payroll areas helps reduce these efforts. For example, in this scenario there are two monthly payroll areas with different pay dates. If the organization is successful in combining the pay dates (i.e., successfully consolidates the payroll areas into one), it reduces the burden on the payroll operations team.  

• Local country infotype maintenance. In a global SAP ERP HCM system implementation, you typically have 12 to 14 global infotypes (e.g., 0007, 0008, 0014, and 0015). However, every country-specific implementation has local infotypes. Some examples are:
  • France (MOLGA –  06): 0054 (social insurance) and 0098 (profit sharing)

  • South Africa (MOLGA – 16): 0149 (taxes), 0150 (social insurance), and 0151 (external insurance)

OM (Organizational Management) Actions 

Generally, OM is a global topic and is not entirely country dependent. OM structures — the strategy to create organization units, jobs and positions — is global for organizations. As a global payroll topic, the main impact of OM is on cost center assignments to organizational units or positions. These have an impact on payroll to finance postings in an individual country.

Time Management Module 

Time management is a local topic related to payroll rules and regulations. Typically the attendance and absence policies and regulations are country dependent. Therefore, time clocking and time management systems are governed by local rules. Similar to my discussion about the PA module, the payroll relevant topics are:

• Transferring time wage types from external time evaluation systems to SAP payroll
• Leave or vacation payouts through the payroll system
• Interfaces and time-clocking system files or data transfers to SAP
• Leveraging SAP time evaluation

• In many situations, time-clocking systems send override data to override hourly rates and cost centers. That data needs to go to the payroll system and then on to the financial postings as well.

Management of Global Employees Module 

This Management of Global Employees functionality was introduced in SAP R/3 Enterprise (4.7) Extension Set 2.0. Some users may use the Concurrent Employment functionality, which co-exists with the Management of Global Employees module. Most global SAP ERP HCM system implementations turn on the Management of Global Employees functionality, and a global payroll topic would not be complete without discussing the challenges presented by expatriate employees or the Management of Global Employees module. Subtopics related to this functionality are as follows:

• Hypothetical tax (commonly referred to as hypo tax). When expatriates are assigned from the home country to another country, the topic of hypo tax or tax equalization typically comes up in the implementation. The idea of hypo tax or tax equalization ensures that expatriate or global employees are taxed at the same rate as if they were in their home country. These employees are responsible for paying taxes based on the hypo tax calculation, not the host country’s tax rate. Let’s use as my example an employee who is moved from Germany to the US. If this employee stayed in the home country (Germany), he or she would have paid local taxes. (This example does not include any expatriate additional earnings — for example, if the employee has been given a school or car allowance or any other host country benefits.) Therefore, the employer pays for the employee’s taxes imposed by the host country (e.g., FICA and Medicare taxes in the US). This topic is too broad to cover in detail here, but for the purposes of this global payroll discussion, here are the SAP taxation points that need to be addressed during an implementation:

• In many SAP implementations, an external tax advisory service performs the tax calculations and an interface feeds the data to the SAP ERP HCM payroll system. In such cases, the expatriate employee’s payroll system in the host country (the US in my example) receives all calculations by interface. You also need to use infotype 0234 (withholding override) in such cases so that the employee’s taxes are not calculated or withheld by the SAP US payroll system.
• Another common scenario is one in which both German and US payrolls are run within the same SAP payroll system and the Management of Global Employees functionality is implemented. SAP has provided infotype 0722, which allows you to send and receive payroll results across two countries (Figure 1). The switch (discussed below) is a prerequisite for this functionality. The switch as shown in table T77S0 in Figure 2 is marked with an X against the corresponding entry (CCURE GLOPY).

Figure 1

Infotype 0722 (payroll for global employees)

Figure 2

Table T77S0 (global payroll switch)

Configuration for Management of Global Employees is located in the IMG path under the Management of Global Employees node. There are two portions to this configuration. The first one is found under personnel Management > Management of Global Employees and the second is under Payroll: International > Payroll for Global Employees. Most of the switches are in table T77S0. Figure 2 shows the view of table T77S0 where the applicable Management of Global Employees and Payroll: Global Employee switches are located. The switch GLOPY (Figure 2) is used to activate the global payroll.

After setting up the switches in table T77S0, there is an additional payroll-related configuration you need to update. You find the configuration that is related to infotype 0722 under the IMG menu path Payroll International > Payroll for Global Employees.

• Financial integration. It is important not to lose sight of your financial integration topic when working on global payroll implementation solutions. Payroll has to be posted to general ledgers and cost centers. Your global SAP payroll system landscape may consist of a single SAP FI/CO instance or a combination of SAP and non-SAP systems. Postings are controlled by wage type. Therefore, in each country they need to be aligned with the appropriate chart of accounts. It is also a good idea to have standard charts of accounts as well. Some challenges facing this standardization include:

• Payroll currency. The local currency for payroll is typically the currency in which the country operates and pays its employees. When you implement payrolls in countries with higher expatriate populations (e.g., Singapore or the UAE), then you may need to use US currency as the payroll currency instead of the host country’s currency. You can view the basic salary in different currencies to convert pay to US currency (or any other currency) for the annual salary. You achieve this by changing the IV date and currency fields at the bottom of the screen shown in Figure 3. The conversion rates used are from the SAP FI system currency tables. This does not update infotype 0008.

Figure 3

Currency in infotype 0008

• Posting currency. The accounts posting currency may be different from the payroll currency. In many cases it could be an international currency such as US dollars or the Euro. In such scenarios, currency conversions with specific value dates are necessary.

SAP Payroll System: Global Aspects 

Using the SAP payroll system, you can apply the principles of standardization and harmonization across countries, as shown below.

Wage type catalogue — While wage type catalogues are created and arranged by country in SAP payroll systems, it is worthwhile to standardize the global wage type catalogue (at least 50 percent of wage types associated with earnings can be standardized). Although wage type catalogues are country dependent, they need to follow standardized numbering and nomenclature. Follow SAP’s best practices documentation for this topic. You can access these best practices at https://help.sap.com/bp-baseline. In the SAP payroll system, the functionality for creating wage type catalogues is available within each of the payroll country configurations and therefore is country-code (MOLGA) dependent.

Payroll data maintenance — In the three scenarios (i.e., the country has standard SAP payroll, uses SAP international payroll, or is outsourced to an external provider) global data maintenance standards are needed. Table 1 provides a sample of standard payroll data maintenance. My definition of payroll data includes all infotypes that are necessary to run payroll in a particular country. Table 1 shows a list of global and sample local infotypes for Canada. 

Table 1

Payroll data maintenance for Canada

You need a table that identifies the country-specific global and payroll infotypes for each country included in the implementation. Within each global infotype you need standardization (for example, if infotype 0008 is global then wage type 1000 = salary and wage type 1001 = hourly should be standard across all wage type catalogues for each country).

Global reporting from payroll clusters — Most global implementations have a requirement to track payroll costs and expenses. If you standardize wage types and postings, then tracking payroll costs and expenses is much easier (for example, use standard headings for earnings that contribute to payroll, such as basic pay, overtime, and bonus reporting). If wage type numbering standards are followed (for example, all earning wage types are included in the range of 1000 to 1999) then this range can be used to track a country’s payroll costs consistently across all countries.

SAP Payroll: Local Aspects

The following subtopics of the SAP payroll system affect the local country payroll as well.

Country-specific payroll schemas — The SAP payroll system provides country schemas for each SAP payroll country. My case study example has the list of country-specific SAP schemas and payroll drivers shown in Table 2.

Table 2

Examples of SAP payroll schemas and drivers by country

Country-specific wage type catalogues — Like payroll schemas, wage type catalogues are country dependent. The model wage types are provided by SAP by country. Figure 4 shows the wage type catalogue creation and the selection of the MOLGA (country code).

Figure 4

Creation of country wage type catalogue

Country-specific payroll drivers — Payroll drivers are similar to schemas and wage types in that each country has its own payroll driver. Table 2 lists the sample drivers for some of the payroll countries.

Country-specific payroll rules — These rules are dependent on MOLGA, as shown in Figure 5. You may be in a situation in which the logic of rules could also be replicated across countries. For example, a certain wage type needs to be calculated or manipulated in the same way across multiple countries. Therefore, it makes sense to capture rules in global libraries.

Figure 5

Creation of rule and country code selection

Country-specific business processes — Examples of country-specific business processes are as follows. (These processes differ by country and therefore vary. For each country you need an extension or delta fit-gap or business blue-print document to address these variations.)

• Taxes:
  • Data maintenance processes. The tax data infotypes for each country need to be maintained and based on the HR service delivery model. The data maintenance responsibility, authorization, and process differ (for example you use the 04xx series for Canada or the 02xx series for the US).
  • Tax update processes. In many countries, tax rate tables need to be updated and verified; therefore you need a process to maintain tax updates. In unique scenarios such as  the US, the BSI Tax factory needs to be updated with appropriate Tax Update Bulletins (TUBS).
• Garnishments:
  • Data maintenance process. Similar to taxes, garnishments are country dependent and need a business process of their own (for example, infotypes 0194 and 0195 in US and Canada).
• Benefits:
  • Country-specific benefits enrollment and administration processes. Many countries have benefits administration that includes health plans, retirement plans, and stock plans among other benefits. Although outsourcing of benefits administration is quite common in SAP ERP HCM implementations, you need processes and objects to integrate the benefits environment with payroll.

  • Integration with payroll. This topic mostly concerns interfaces and related development objects. Each country, however, needs its own processes to manage the data and interfaces along with managing any errors. This involves the interfaces to and from benefits providers or outsourced vendors. Each country needs to chart out these processes and ensure the alignment with global design. Especially in the case of benefits, the data comes from both HCM master data and payroll data.

SAP Payroll: International Aspects 

SAP has provided an international schema and international functionality for addressing the countries where the SAP payroll module is not directly available. For example, in the case study analysis in my article, "Use a Global Payroll Strategy to Leverage the SAP Payroll System," you want to use the international schema for a payroll system implementation in Costa Rica. There are a few questions you need to ask before starting work on the international schema:

• Is there an SAP system-delivered MOLGA in table T500L? Figure 6 shows the view of this table and the two-character country codes that are normally used in SAP systems.
• How is the financial company code arranged for this country (e.g., which company code receives the postings related to payroll)?
• Which currency is used in this country? Is there any currency conversion to US dollars required?
• What is the wage type catalogue in the country? How do you configure them (e.g., what model wage types do you use)?

Figure 6

Table T500L (country codes)

International schema (X000) — The SAP system provides payroll schema X000 with the sub-schemas and rules that can be used to modify and fit the country requirement. Similar to any standard SAP payroll country, you can use the naming convention for the copied schema.

International driver (RPCALCX0) — Payroll drivers are available in each individual country (Table 2 shows examples of a one-character country code in the driver name).

Wage type catalogue — When you follow IMG menu path Payroll International > Basic Settings > Environment of wage type maintenance > Create wage type catalogue, you get a selection screen similar to Figure 3. From the country drop-down list, if you choose the Other countries option, you get a wage type catalogue in which you can copy and create wage types. Let’s say you choose a country such as CY (Cyprus) from the drop-down country list for creating wage type catalogues. Because Cyprus is not a standard SAP payroll system country (although the country code is available in T500L), there is no wage type catalogue. You need to create it yourself if you choose to use this country code.

Creating Common Libraries and Interfaces

In most global payroll implementations, the core team (typically located in the large country or headquarters) drives the project. The development teams are also typically at a single location, including off-shore locations. It is therefore very important for central operations to create global common or reuseable libraries at the beginning of the project. Although this can be a bit of a challenge at the outset, the continuing benefits of this approach is well worth the initial extra effort. While carrying out global blueprints and collecting individual country requirements, it is important to keep in mind these libraries. In a typical multi-country payroll implementation about 60 to 65 percent of the configuration and programming can be leveraged or re-used across the different countries (i.e., wage type catalogs, rules, and routines). The delta for each country can be reduced by standardization and harmonization of the process, as discussed in "Use a Global Payroll Strategy to Leverage the SAP Payroll System."

For some industry- and company-specific requirements, it may be necessary to develop new functions and operations and, therefore, also develop new payroll sub-schemas. This could be related to requirements such as sales commissions, bonuses, or earnings that are specific to a company’s business or industry. Development of custom operations, functions, and sub-schemas then can be re-used across countries. Some of the development objects may need a MOLGA during the development of objects, and individual countries tend to do their own developments.  However, such libraries share the developments across countries (for example, payroll rules have country codes). Rules are country dependent and therefore parts of the code built for one country could be copied to use in another country to reduce effort and make it more reusable.

Outsourcing Country Payroll 

I have mentioned two categories of country-specific SAP payroll systems — standard delivered and those that leverage an international payroll framework. In the case study, Nigeria and Peru continue to outsource payroll solutions. Since XYZ Corporation in this case study wants to keep the SAP ERP HCM as the system of records, there are interfaces from the SAP ERP HCM system to outsourced payroll providers.

The SAP system has traditionally used interface toolbox PU12 to outsource payroll in this type of scenario. In the current ECC6 version it is listed under the payroll menu as Outsourcing. This toolbox allows the central SAP ERP HCM system to export master data and time data to the payroll system.

SAP Deployment in Global Payroll 

There are three main approaches to SAP deployment in a global payroll scenario. These are:

Approach 1 – Big-bang global deployment. Deploy multiple countries in one single go-live through a single cutover and rollout plan.

Approach 2 – Regional deployment. Deploy multiple countries within a region — for example, European rollouts, American rollouts, and Asian rollouts. This approach helps manage similar countries in one region and also within similar time zones. Typically regional HR service delivery centers are aligned with this approach.

Approach 3 – Pilot deployment. Deploy pilot countries in different regions. The criterion for selecting the pilot countries varies according to the criteria of the organization. For example, it could be one pilot country in each region or several pilot countries from different businesses of the organization. (The most common reason for using for this approach is that it allows the implementation team to cut their teeth on a smaller implementation so that they can use the lessons learned to improve later rollouts.)

Deployment Challenges and Options

Global payroll cutover and deployment pose several different types of deployment challenges. These challenges are easier to understand by using a single country example. Here is a list of the challenges:

• Big-bang vs. phased rollout. Early in the implementation, the deployment strategy needs to be finalized on whether it’s a single big-bang deployment or phase, or wave deployment.
• Big bang for case study. In the class solution of the case study in “Use a Global Payroll Strategy to Leverage the SAP Payroll System,” there are 10 to12 SAP in-house countries that need to be implemented together in one go-live. These countries represent a mixture from different regions and time zones. In a cutover scenario, as systems move from legacy payroll to an SAP payroll system, there is always a data conversion.  The data conversion and transition to a new system invariably needs a freeze period. In a multi-country, big-bang environment, this freeze period has to fit all countries, their payroll areas, and their time zones. 

You could look at multiple options for a phased deployment, such as option 1 for my case study: regional deployment. If you decide to go with the regional deployment option, then the case study example looks like this:

• American rollout: Five countries in phase 1
• European rollout: Six countries in phase 2
• Asian rollout: Four countries in phase 3

Let’s assume that XYZ Corporation wants to complete the entire project in 18 to 24 months. In this case, the calendars have to be managed so that all three phases are completed within the stipulated time. While the phased or wave approach is followed, keep in mind that a phase can have a combination of SAP country payroll, international payroll, and outsourced payroll.

While you manage SAP country payroll and international payroll in a similar way, you may want to keep outsourced payrolls in a phase by itself. These are some considerations to keep in mind if you are using outsourced vendors and interfaces:

• Country tax calendar and year-to-date data conversion affect the go-live dates and deployment schedules
• It helps to do regional deployments because the payroll solutions and country regulations are usually aligned with each other 

Instead of using three phases according to region, option 2 in the case study is a pilot implementation in the smaller countries followed by big-bang implementations for the rest of the countries. In this option, XYZ Corporation wants to be risk averse and wants to try smaller countries first. Using the case study example, it was decided to use following countries:

• Brazil with 350 employees
• Dubai and the UAE with 400 employees

Of these two countries, one is a standard established SAP payroll country, while the other one is using an international schema and an international driver. Therefore, the implementation can give both flavors to XYZ Corporation. Option 2 is desirable only from a risk mitigation perspective. Option 1 is a more standard and industry-adopted option than option 2.

Many implementations choose to use an option other than the standard option 1. The reasons for this are:

• Companies want to implement higher employee volume countries first
• Burning platform (in which an organization’s IT platform or systems are old or are running out of support and maintenance), or some regions or countries that are under pressure to retire a legacy platform

• Emerging countries or countries that are more strategic for companies due to their growth

Data Conversion Challenges 

The data conversion challenges are very similar to a single country go-live except that they can be compounded depending on the legacy system environment as well as the go-live calendar for each country. Both the master data and year-to-date data conversions need to be handled for each country in scope. If the legacy systems have too many variations across countries, you are not able to leverage the data conversion development (such as the Legacy System Migration Workbench [LSMW]) across countries. (For more information about LSMW, read Manuel Gallardo’s article, “Best Practices to Increase the Effectiveness of Your LSMW Objects.”)

Support Packages and Country Legal Changes (CLC) Challenges 

Typically SAP releases 12 normal and one year-end Support Packages. Most global multi-country implementations try to minimize any disturbances to the testing and normal work calendars. If any legal or compliance changes come up for a country, then SAP releases a CLC. There are usually one or two CLCs released per country each year. During December and June, SAP also releases human resource synchronization Support Packages that normally go across countries.

Year-End Challenges

In a multi-country payroll environment, the end of the tax year could be different depending on the country. For example, in the US the tax year ends on December 31, while in India the tax year ends on March 31.

At the end of year, organizations have to manage multiple activities and projects. These consist of:

• Tax processing. This includes tax filing as well as issuance of tax documents to employees.
• Annual compensation cycles. In some companies these are aligned with the company’s financial year, while in others it could be in December (at the end of the year). Typically these cycles create data uploads in the SAP system infotypes 0008, 0014, and 0015 as well as retroactive data changes to compensation.
• Annual leave balance processing. This is where the annual leave balances are updated and new balances are created
• Constant and custom table maintenance. Constants may need to be changed in constant tables (T511K or T511P) or in custom tables. For example, a payroll has a rule that uses a constant from table T511K and it needs to be maintained on an annual basis.

Satish Badgi

Satish Badgi has been helping clients implement SAP ERP HCM and payroll for more than 15 years. He has been involved with large full-scale SAP ERP HCM and payroll implementations using the breadth and depth of SAP modules. Satish works for a large management and systems integration consulting firm and handles global payroll for clients. He has published two books on SAP payroll, Configuring US Benefits with SAP and Practical SAP US Payroll.

You may contact the author at sbadgi@comcast.net.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.