Expand +



Understand Leading Practices for Defining Your Payroll Systems of Record Using a Hybrid Solution

by Stephane Routhier

March 22, 2018

Learn how to define the systems of record for all data components involved in SAP payroll processes, the designation of where they exist, and where they are maintained: SAP payroll on premise, SAP SuccessFactors Employee Central (which is in the cloud), and a similarly named SAP SuccessFactors Employee Central Payroll (which is in a hosted cloud.). See this guide to making the right choice on defining which solution is the source for each data component.

Systems of record are the source systems of all entries involved within your processes and calculations. To be able to audit your data, it is very important that data be created, modified, and deleted in only one source.

Historically, ERP solutions were designed to manage data from all functional areas and to perform all business processes within a single source. Major ERP software companies realized that it is impossible to address business requirements from all industries. From that point, the ERP solutions have opened the integration to specialized solutions requiring integration and clear rules about data maintenance.

I share what to consider before making a final decision on which solution will host each data component: the system of record. The focus is on data components affecting payroll processes.

What Is a System of Record?

The system of record is your source system that owns that data component. The leading practice is always to create, modify, or delete this data within the same system of record and never within a downstream solution. Adopting this practice facilitates data auditing as you know the source system based on the data component. This practice ensures all solutions are in sync, which ensures reporting accuracy. You can imagine the headache that results when you run a report in your HR solution and one in payroll and they do not match because of asynchronous solutions.

Key Considerations for Designing Your Systems of Record 

This section shares the questions and actions you should go through to be ready for designing your systems of record as part of a hybrid solution. When I refer to a hybrid solution, I mean an environment that uses different solutions or vendors, not one strictly limited to SAP SuccessFactors.

Potential Systems of Record 

As part of a hybrid solution, one or more solutions can manage one data component. As an example, SAP SuccessFactors Employee Central Payroll (a hosted cloud functionality) could be the source system for pay codes. It is important to understand the functionalities and fields from each potential system of record. In SAP SuccessFactors Employee Central (a cloud solution), you can enter pay components, but you have more limited functionalities than if you used Employee Central Payroll, where the offering for performing pre-payroll validations is more extensive.

Employee Central Payroll uses SAP HR and Employee Central. You may discover only after the pay components from SuccessFactors Employee Central are passed to Employee Central Payroll or SAP Payroll (the on-premise solution) that an employee is not eligible for a wage type due to a specific attribute. It requires you to go back to Employee Central to correct the pay components and wait for (or manually trigger) the integration between your solutions.

Data Owner 

It is important to understand who is managing each data component as part of your actual business processes. A process drives each data component. This information helps you to define your system of record.  Many companies segregate the solutions by functional area as a design consideration as shown in Table 1. This table provides you some examples of potential solutions that could be used as part of a hybrid solution.


Functional area


Human Resources

SAP Human Resources (on premise)

Employee Central


SAP Payroll (on premise)

Employee Central Payroll

Time Management

Employee Central Time Off

SAP Time Management (on premise)

Workforce Software


SuccessFactors Benefits

SAP Benefits (on premise)



SAP Finance (on premise)


Table 1
Solutions and vendors by functional area

Knowledge Transfer

Most companies try to minimize the learning curve of impacted employees. They try as much as possible to have them focus on one specific solution included in a hybrid solution. Even if solutions are integrated, they have their own data structures and functionalities. It is not intuitive for all employees to learn multiple solutions.

Most companies prefer to leverage reporting and dashboards to have access to other required information that has other solutions as a source. This approach does not enable them to update data, but to have the capacity to review the required data directly from the system of record.

Segregation of Duties (SoD)

Note: The system of record definition is also a common way for companies to perform SoD. I often see companies that have only the compensation pay codes entered in Employee Central. Only bonuses and awards and some other pay codes are entered in Employee Central as they are specific to human resources (allowances).

Items that are payroll specific such as taxes are often managed directly in payroll (on premise or in the hosted cloud). Some companies decide to use the mashed-up infotypes concept to initiate the creation of tax infotypes in Employee Central Payroll. The decision element that can influence this choice is whether you agree that based on Employee Central addresses data, you want the tax infotypes to be initiated and completed by the payroll department, or if you prefer that based on a new hire report, the payroll resources create the entire tax infotypes record. I prefer to have them created entirely in Employee Central Payroll so that nothing is overlooked, but some people could argue with this decision.

Mashed-up infotypes is a term for enabling a user interface (UI) component from another system to be presented within the UI of Employee Central. The mashed-up infotype for residential taxes uses the address information to pre-populate the infotype 207 – Residential Tax Data in Employee Central Payroll.

Because garnishments are purely payroll data, I recommend keeping them in Employee Central Payroll as no real functionality is offered in Employee Central.

The last pay component I cover is worker compensation, which I prefer to manage in Employee Central Payroll or on premise based on the data feed from Employee Central for job, position, or organizational unit.

Solution Functionalities

Companies should never select one solution as the system of record before reviewing the solution functionality. The functionalities offered could potentially not accommodate your business requirements. This approach could influence how you select the system of record for a specific data component.

I have seen companies make the decision to use Employee Central as the source system for a specific pay code. This pay code requires various eligibility controls as far as which employee could be have each pay code entered for them. The issue is that Employee Central does not offer all supporting configuration to have those controls applied. For example, a pay code was assigned to an employee who was not eligible. The code assignment was transferred to Employee Central Payroll, which rejected that pay code assignment. The payroll team had to ask the Employee Central user to remove the pay code and wait for the integration between both solutions to happen. This situation could generate a bigger issue on a payday.

Integration and Timing

You should never overlook the need to integrate among the solutions and the data transfer timing. Consider a scenario in which pay code information is only available shortly before payroll processing. I recommend having this pay code directly entered in Employee Central Payroll to avoid last-minute payroll issues. You need to keep in mind that a pay code should always be entered in the same solution to make the auditing consistent.

My Recommendations

I recommend you manage your data based on the guidelines in Table 2 for your future hybrid solution to align with leading practices.

Functional area


Data component

Human Resources

SAP Human Resources

Employee Central

  1. Personal Data
  2. Demographic Data
  3. Assignment Data
  4. Salary Data
  5. Default Financial Data
  6. Default Work Schedule
  7. Pay Components related to compensation
  • Bonus and Awards


SAP Payroll

Employee Central Payroll

  1. Recurring Deductions and Payments
  2. Additional Deductions and Payments
  3. Garnishments
  4. Tax Information
  5. Financial Data Override
  6. Payroll Calculations

Time Management

EC Time Off

SAP Time Management

WorkForce software

  1. Time Entries
  2. Work Schedules
  3. Holiday Calendar
  4. Substitutions
  5. Time Banks
  6. Time Calculations

Benefits and Saving

SuccessFactors Benefits


  1. Plans
  2. Attributes
  3. Deductions Amount


SAP Finance


  1. Posting Period
  2. Chart of Accounts
  3. Cost Centers
  4. Vendors

Table 2
Guidelines for managing data

As most companies are now choosing a hybrid solution model, I hope these guidelines help you in making better choices for future hybrid solution designs.

An email has been sent to:


Stephane Routhier

Stephane Routhier ( is contributing to EPI-USE America market development and acting as a Solution Architect in the North American HCM Practice focused on the selection, planning, design, and delivery of HR solutions across multiple industries.

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!