Integrated vs. Separate HR and Payroll

rganisations often agonise over the best approach to running their HR and Payroll systems, with a common question being whether to have a fully integrated HR and Payroll system or to operate entirely separate systems. The arguments for and against each option are set out below: 

1.       Arguments for Integration 

In an integrated system, the core HR Management System and payroll modules sit on top of a common database, so all data about an employee such as their pay, conditions, cost centre, organisation, position and personal information are simultaneously available in every module. This has several advantages in terms of processes and workflow. For example, a newly hired employee can be set up in the system by an HR administrator, the employee can add personal data through self-service and pay details can be added by a payroll administrator using the same core data. There is no need for cross-referencing or waiting for data to flow through the system.

The biggest risk with separate (non-integrated) HR and Payroll systems is that the same core data is frequently needed by both, relying on either an electronic interface or even manual re-keying, requiring additional work to manage and validate the transfer. Both these methods almost always cause delays and potentially problems in reconciliation. From a business process perspective, it’s usually much easier to design a process based on a smooth flow of data between HR and payroll within the same system. Retaining all data within the same system also reinforces the idea that the HR module is the master source of data about people. If the two systems are not synchronised, it could lead to problems in performing certain calculations, for example, where pay calculations are based on position-related data that needs to refer to Terms & Conditions (held at the HR level) in order to work out overtime pay or calculate a pay increase. 

2.       Arguments for Separation 

In some cases, separate HR and Payroll systems may make good sense on cost grounds. For example, when implementing the payroll module of a large ERP module, it may not be economically viable to implement the payroll module to pay only a small part of the organisation, which may have its own pay rules. Paying a relatively small number of people (for example a country where only a few people are employed) involves many of the same set-up costs as those for a large population and it’s not uncommon for global implementations to feed separate, stand-alone payrolls or to outsource to a local provider. The ‘tipping point’ for these calculations will vary according to several factors such as payroll complexity, the availability of local providers and scale. In some organisations, the payroll system seems to be working well enough – people are paid the right amount every week or month and the view is that there is no point throwing something away that is fit for purpose - ‘If it’s not broken, don’t fix it’. When the same payroll system has been running for some time, it will probably have reached a point of maturity where the team responsible for it feels comfortable, knows it thoroughly and is reluctant to change. Staying with the same system means there is no need to set up new software and its operation will not require staff to be retrained. The current license period may not have expired, in which case the team may wish to let the contractual period naturally expire, saving cost. However, it’s important to recognise that introducing an HR system will inevitably have an impact on payroll process (as outlined in the pro-integration argument) because of the fundamental need to reconcile the systems. This may actually introduce more cost as the data will need to be passed to payroll by some means, either through re-keying or via an interface.