From "face off" to an "interface"

One of the issues keeping HR managers and payroll specialists alert is that of developing an interface from the organizational HR system to the payroll system. Apprehensions are further heightened when an interface needs to be developed from a global HR system to the local payroll system; over and above the fact that development of such an interface requires the involvement of many parties from a large number of countries, knowledge and understanding of the technical world of interfaces is also required; add to this the need to formulate and define what information will be transferred trough the interface file and how to manage a project that requires the participation and cooperation of the local payroll system provider as a key player in the process and in the project team, a team that is often a distributed and global one.

The need to create an interface between the organizational HR system and the payroll system is one of the hottest topics in HR today, given the burgeoning transition of global organizations to a global payroll management configuration. Global cloud-based HR systems, such as Workday, Oracle HCM, Success Factors and similar products, enable organizations to manage organizational employee data worldwide more effectively than ever, while creating standardization, scalability and the flexibility needed. Global HR systems also equip global companies with tools for formulating a "normalized" snapshot of the employees in the organization and with a powerful tool for making decisions about the organization's human capital.
But while HR systems currently lend themselves to global implementation (the same system can be used to manage employee data worldwide), the conditions have not yet been created (and probably never will) to implement payroll systems that enable calculation of employee pay in different countries on one central platform (for the obvious reasons of differences in regulations and differences in the professional aspects required of payroll systems from one country to the next).
An interface between the HR system and the payroll system is therefore vital for a successful implementation of global HR system; and in effect, a global HR system implementation project is not complete without development of the interfaces required to the local payroll systems in each country.

Reading between the lines, it is evident that development and implementation of an interface from a global HR system into a local payroll system is, for the most part, no simple task, and it is also clear why this issue is not widely familiarized, but nonetheless of great concern to HR and payroll personnel, who need to manage and be part of such a project, which is largely a technical/ technological project. Accordingly, understanding the need for an interface, the technical principles for developing interfaces, and how to manage such a project, can make things much easier for HR and payroll personnel, and help them successfully navigate and manage a project of this kind. By the same token, it is vital that the technical/ technological teams involved, understand the soft and professional aspects of the payroll in order for the project to succeed and execute effectively.

This article addresses the need for and the essence of an interface, explains the operational aspects of the interface and try to answer most of the questions that trouble managers when they take on responsibility for developing an interface between an HR system and a payroll system, or when they are one of the parties involved in the process. Among others, we will try to answer frequently asked questions about issues pertaining to development of an interface, including: what is an interface and why is it necessary, which data are generally transferred from an HR system to a payroll system, what is the "interface file format", how often must the interface file be transferred, which parties are responsible for it, how is data integrity ensured between the systems, plus other important issues.

The idea to write an article about interfaces between HR and payroll systems crystalized when I came to realize that there was a need for a detailed and comprehensive guide on the topic as more and more organizations transitioning to global HR systems find themselves confused, and in particular, lacking a satisfactory toolbox to tackle a project of this nature. This article is based on extensive knowhow gained in supporting and managing a great many interfaces between local and global HR systems, as a professional working with dozens of local and global teams to develop and implement interfaces to the Hilan payroll module.

HR systems are very different in essence from payroll systems. While the purpose of an HR system is to maintain basic, more "fixed" personal data of an employee (personal details, spouse's details, education, welfare, training, etc.), the payroll system is concerned with calculation of employee pay, impacted by variable monthly changing data (attendance, employment percentages, grants, etc.) and by laws and regulations. Allegedly , given the different goals of the two systems, transfer of data from one system to the other would appear to be unnecessary. In practice, however, an important portion of the data required to calculate pay in the payroll system maintained and managed in the HR system, and is used by HR personnel to manage the organization's human resources.
This being the case, there is no point in managing and maintaining the same data in each of the systems separately. Not only would that be inefficient and complex, but more importantly, a source of errors and data integrity problems.

With global organizations, the issue is even more complex. Many organizations prefer to manage their employee fixed personal data in a global HR system. There are many reasons for this preference, but in principle, managing the details of the organization's employees in a single system has numerous benefits; first and foremost, the ability to standardize and manage infrastructure that facilitates a uniform and broad-based picture of the organization's workforce, plus the ability to drill down to the level of a country and employee, not to mention the ability to serve as a pivotal global business decision-making tool. Thus, for example, an organization that manages its employee data in a single global system can make a relatively quick decisions regarding its next development center or the team/ country in which development of a particular product will be more profitable or a better move for it. This capability gained significant momentum in recent years with the introduction of cloud-based global HR systems, such as Workday, Oracle HCM, Success Factors and others, which, in one stroke, eliminated the technological barriers to effective management of employee details in a single distributed system, anywhere, anytime.

With the removal of the technological barriers (as described above), organizations began to shape the operational configuration of their human resources accordingly: HR systems began to take the shape of generic configurations; employee data were stored uniformly, regardless of the country the employee was in, while employee self-service tools began to crop up as part of the solutions (the ability to update changes to personal details, manage absence data, pension data, etc.). Furthermore, HR centers are also evolving as more and more global organizations establish shared services centers providing HR services to the organization's business units distributed in different countries, including updating of employee details in the global HR system, establishment of a help desk for employee queries on policy issues, etc.
Now that employee HR data are managed in a singular global HR system, frequent automated data transfer to the payroll system without human intervention is critical for efficient organizational dataset management, for data integrity, and to meet organizational compliance requirements (segregation of duties between the parties that create the employee details in the HR system and the parties responsible for completing the data in the payroll system, permissions and information security aspects, fraud prevention aspects, etc.).

For these and other reasons, the need to transfer the relevant information for payroll purposes from the global HR system to the local payroll system is clearly evident, and this is where the interface comes in.

To understand what an interface is in the simplest terms, let's look at the widespread need for interfaces between the HR and payroll systems; the HR system includes employee data such as: employee number, first name and last name, address, bank account number, etc. When these data need to be reflected in the payroll system as well, a way must be found to transfer the data at a defined and regular frequency, so that the data ultimately managed in both systems are identical at given points in time. The obsolete way of doing this (surprising as it may sound, this still happens in many organizations), is to manually type the data that appear in the HR system into the payroll system. The difficulty with this method, apart from inefficiency, is that in addition to time-consuming manual typing, it runs the risk of discrepant data entry and of missing data. In particular, it becomes difficult to track changes in the HR system data over time, and to execute the updates in the payroll system close to the time they were changed in the HR system.
By the way, there is another manual way of transferring data from the HR system to the payroll system, and that is by exporting the data from the HR system to an Excel file or other format (such as TXT), and then importing the data in the payroll system using an import function. However, despite the disadvantages of manual typing of the data into the payroll system, this method of importing an excel file also has many disadvantages; not all HR systems are capable of successfully exporting data to an Excel format, and not every payroll system is capable of successfully importing the data. In many cases, even when the export and import functions are available, the file layout arriving from the HR system (as described below) does not match the data layout acceptable by the payroll system, and considerable manual manipulation is required to facilitate valid receipt of the data in the payroll system. (In addition, the possible frequency of this function is low, resulting in the payroll system lagging behind the HR system)

Hence, the most efficient way of transferring data from the HR system to the payroll system is via an automated data interface. Using the interface, the data is transferred from the HR system to the payroll system seamlessly in four main stages at a predefined frequency:

• Stage 1: the HR system generates a file containing the data that need to be transferred to the payroll system and saves it in a defined folder on the server.
• Stage 2: the file containing the data generated by the HR system is pulled from the folder on the server and transferred via a secure medium (generally an electronic vault) to the file server in the environment in which the payroll system is managed.
• Stage 3: the file is pulled by the payroll system, subjected to receiving controls, and the data in it inserted in the relevant events and fields in the payroll system.
• Stage 4: a discrepancies feedback report containing the fields and data that failed the controls (as defined in advance) is created, and in some cases, automatically transferred back to the HR party responsible for feeding in the data (see more later below).

In order for the process to execute automatically without any manual intervention whatsoever, several conditions must be met in the file creation process in the HR system, and in the data transfer to and data receipt in the payroll system:receipt in the payroll system:
• A reliable mechanism is required for transferring the file created by the HR system from the server on which the interface file is stored, at a scheduled frequency, to the electronic vault, from where the payroll system pulls the file. As simple as it may sound, this mechanism can be one of the most difficult to define, especially when the two servers are physically located in different countries, and on different data networks, operating under different information security policies and mechanisms. The mechanism itself must be one that can be scheduled to transfer the data, and must also include monitoring features capable of alerting the sender and the recipient in the event that the file scheduled to be transmitted or received is not located on one of the servers at the set times. As a result, the definition often requires the intervention of IT and information security personnel in order to approve and define the communications configuration, data transfer protocol and monitoring mechanisms.
• The file layout created by the HR system must be based on the input layout of the payroll system accepting the data; thus, for example: the new hire process may differ from one payroll system to another: how the data are grouped, defining of the mandatory fields, the number of positions required for each data element, the data transfer sequence, etc. In cases where the global HR system is not capable of creating a file with the data format required by the payroll system, the payroll system must be able to read the file and covert the data in it into the format required in the payroll system. This is possibly one of the most complex aspects of the interface development process, if the HR system is not able to transfer the data in the format required by the payroll system.
• The data in the interface file must also include the specific unique data required by the payroll system (for example: in Israel, the children and spouse's details are required for tax calculation purposes, while playing a lesser role in the payroll system of other countries in the calculation of the employee's monthly pay)
• The interface must support the special system characteristics of the recipient payroll system. For example: if the payroll system supports retroactive reporting or manages valid dates for employee records, the HR system must transfer the data in a manner in which the payroll system can identify a report as a retroactive report and save valid dates for every employee record, so that retroactive calculations are executed accurately. Another example is the matter of language: in Israel, data such as first name, last name, address and other details must be transferred in the Hebrew language; however, some global HR systems do not support this, a major limitation in creating an effective interface.
• The data configuration transferred in each iteration (run/ activation) of an interface file must be defined: will all the data records be transferred in each iteration, or only the changes made to the records since the last iteration (all data versus data changes only).
• The frequency of the interface file transfer must be adapted to the work process defined between the HR Department and the Payroll Department, or between the HR Department and the payroll services provider in that country. Automated transfer of interface files is generally executed daily, and the frequency mechanism effectively defines the work process between HR and the Payroll Department. How and when transfer of the interface file is suspended in the monthly payroll cycle must also be defined in the interface frequency mechanism. Thus, for example, it is vital that transfer of the interface file be suspended on the payroll "cut-off date" and resumed immediately upon the close of the monthly payroll cycle.
• The payroll system must be capable of generating output (generally in a report configuration) presenting the results of the receipt of the interface file: which data were successfully received, which data require validation checks (received, but the system issued an alert about their validity), and which data failed acceptance in the payroll system. Definition of the alerts and discrepancies is part of the interface mechanism developed in the payroll system. The report of the receipt and the discrepancies listed in it must be created after every interface file receipt cycle, and the discrepancies in it must be transferred to the officer responsible for the HR system in order to correct the data in the HR system and their receipt again in the payroll system in the next scheduled run of the interface file (more about the discrepancies feedback report later below)

Many HR managers, payroll specialists and project managers entrusted with developing an HR interface to the payroll system deliberate this question extensively; so this is the place to make sense of this issue too.
From my experience in defining dozens of interfaces between local and global HR systems and the Israeli "Hilan" payroll system, ultimately, most of the data recommended for management in the HR system (primarily global) are the "fixed"-"qualitative" data about the employee, that is, employee details that do not change frequently, and that are not the product of a pre-calculation (in contrast to monetary and calculated data whose natural place is in the payroll system). While some organizations also manage wage-monetary data in the HR system, these are raw data, and usually boil down to data about the employee's base pay/ base salary.

Below is a list of the data groups recommended for management in the HR system and transfer in the interface file to a payroll system:

Below is a list of the data groups recommended for management in the HR system and transfer in the interface file to a payroll system:
• Employee number
• ID card number
• First and last name, gender, address, email, contact phone numbers, etc.
• Personal status
• Date of commencement of employment
• Status (active, maternity leave, unpaid leave, termination of employment, etc.)
• Spouse's details
• Children's details
• Bank account details
• Employee's organizational cost center (division, department, down to the level of the direct manager)
• Employment contract for the purposes of attendance pay (workers paid by the hour/ month/ global hours, etc.)
• Job description
• Employment (FTE) percentage

In organizations with a more complex pay structure, additional data may managed in the HR systen, such as:
Ranking, base salary, military service details, etc.
Any additional qualitative information impacting pay must also be transferred. For example: worksite, type of medical insurance, overtime permission, clothing entitlement, etc.

At this juncture, the question obviously arises: why can't more raw data be managed in the HR system and transferred to the payroll system in the interface file? This question is frequently asked by parties of global project who don't fully understand the complexities of payroll in Israel. Thus, for example, one can point to the problem of managing and maintaining data in the Hebrew language (see below), managing and maintaining the pension schema ("Layers" form), car and leasing details, severance pay balances, etc. Managing these data types in the payroll system is a complex task in itself, requiring special development and maintenance of tools and sophisticated local regulations management in the payroll system, not to mention that dedicated development and maintenance of these types of data is not possible in HR systems generally, and in global HR systems, specifically.

As is clearly evident, most of the data conventionally transferred in the interface file from the HR system to the payroll system can be defined as "qualitative data". Needless to say, in Israel, qualitative data, such as first and last name, address, spouse and children's details, bank's name and address, must be transferred in the Hebrew language because they are necessary in Hebrew in the payroll system as part of the information required by the authorities (in income tax returns, national insurance, and various regulatory reports). In global companies, some of the data might be received in English, but even in these instances, the data in the English language does not preclude the need to transfer and maintain the data in the Hebrew language as well.

So what do we do when the global HR system is not capable of managing and transferring the data in the Hebrew language?
In such cases, it is standard practice to transfer only the most basic data in the interface file from the HR system to the payroll system; at the very minimum, the employee number and other identifying details (even if in English, such as first and last name in English), and simultaneously, to transfer the 101 Form [an employee declaration of personal details] and the employment contract to the payroll managed services team, so that they can manually supplement the information required in the payroll system, in the Hebrew language. This is not the ideal interface configuration, but at the very least, it affords global headquarters some degree of control in "top-level management" of the personnel data.

As aforesaid, one of the first things that needs to be defined in an HR to a payroll system interface is the data configuration transferred in each iteration (run/ activation) of an interface file: will all the data records be transferred in each iteration, or only the changes made in the records since the last iteration (interface file of data changes only).
This has a direct and material impact on the management of the project's resources, in terms of timetables, costs, design resources, and development and testing; if the HR system is incapable of exporting data in the data changes configuration described above, additional dedicated development will be necessary on the payroll system side to decode the data received in each interface run and to identify the data changes by means of a dedicated program that runs each time an interface file is received. Additional complexities exist, such as: the interface's behavior in the event of canceled records, retroactive reporting, etc.
That is why an interface file of the data changes will always be preferable over interfaces that transfer all the data anew in each iteration.

Naturally, whenever you have two systems with an interface between them, errors and glitches are always liable to occur.

Generally speaking, interface glitches can be divided into three types:
• Glitches in file creation and transfer: instances in which the interface file did not reach the payroll system for whatever reason (was not created in the HR system, or was created but not transferred)
• Glitches in the acceptance of the file in the payroll system: the file was created and transferred, but was not accepted at all by the payroll system due to a problem with the file layout or any other technical fault
• Data errors in the interface file: these are the most common types of glitches in the interface files between the HR and payroll systems, and effectively relate to the quality of the data itself transferred from the HR system to the payroll system.

To validate transfer of the interface file and the data in interface file on an ongoing basis, two main tools are used:
• Technical monitoring of the file transfer from the HR system to the payroll system: activation of a mechanism that issues an alert in the event that the interface file was not transferred (on the sender side) or not received (on the recipient side), based on the scheduled frequency of the file's dispatch (as described above).
• Information about the validity of the data in the interface file is transferred in a discrepancies feedback report. The discrepancies feedback report is produced by the payroll system receiving the file, and includes information about three dimensions of the data quality: data completeness (all the required information arrived), data integrity (concerns about discrepant data fed into the HR system) and data accuracy (the data item is reliable, but not necessarily accurate).

The report issues two main "flags" about discrepancies and errors in the data upon their receipt in the payroll system:
• "Alert": the data item was received in the payroll system, but upon receipt, the system issued an alert for the attention of the payroll specialist (for example: "the effective date of the event predates commencement of employment")
• "Error": the data item transferred from the HR system is discrepant and was not accepted by the payroll system (for example: "monthly salary reported for an hourly worker").

In such instances, the payroll specialist must transfer the discrepancies feedback report to the HR representative to correct the data item in the HR system, and the data item need to be transferred to the payroll system correctly in the next run of the interface file.

It is important, at this point, to draw attention to an incorrect practice of the payroll center correcting the data defined as discrepant directly in the payroll system. By doing so, payroll specialists create three main potential problems:
1. Removal of the responsibility of the HR teams to feed the data into the HR system correctly from a process and quality management perspective
2. The data integrity in the HR system is impaired, as information gaps are created between the data in the payroll system (valid data) and the data in the HR system.
3. The principle of the segregation of duties is compromised, a material part of global compliance and of SOC requirements.

To prevent instances of the above type, and to maintain optimal data integrity between the payroll system and HR system, it is common practice, and in many cases even binding, to close the updating of those events/ fields in the payroll system that originated from data transferred in the interface file from the HR system. This eliminates any possibility of deliberate or unintentional updating of HR source data in the payroll system.

Maintaining data identical between the HR system and the payroll system can be challenging even in the event of an automatic interface between the systems and compliance with all the segregation of duties rules described above. This could happen for a whole raft of reasons, primarily technical ones.

In order to validate data integrity and that the data are identical, many organizations have monthly controls in place, including comparison of the payroll system database with the HR system database. This is generally performed using Excel, BI or a data warehouse to which two files are transferred at the month's end: a file from the payroll system and a file from the HR system, each including the data fields transferred from the HR system to the payroll system. In the DW, the data fields of the two files are compared, and any data flagged as discrepant are indicative of unreliable data in one of the systems. After investigating and checking the discrepancy, the valid data item must be updated in the HR system, so that it will be correctly reflected in the payroll system in the next interface file run.

This control is required at least once a month, and is generally implemented immediately after the close of the payroll as part of the monthly closing.

The article provides a detailed description and explanation about the nature of the interface between an HR system (local and global) and a local payroll system, with a special focus on the Israeli payroll, known for the complexity of its regulations and processes compared to the rest of the world. We reviewed the need for a data interface from an HR system to a payroll system, defined what an interface is and the basic process for transferring the interface file, the conditions required for reliable and valid transfer of an interface file every time, the data recommended for transfer in the interface file from the HR system to the payroll system (with some emphasis on the regulatory restrictions in Israel), and finally, we delved into the importance and ways of implementing interface controls on an ongoing basis.

**Special thanks to Shiri Bassan, Manager, Hilan Payroll Software Department and Guy Sefer, Manager, Hilan Payroll Implementation Department and Nir Epstien, Hilan BPO PM & Compliance officer, for their assistance in the professional proofing of the article.