3 key principles to consider when systems for processing employee transactions are being developed or reviewed
By Alan McEwen
HR and payroll are linked together by the transactions that mark an employee's history with the employer.
Some of these transactions relate to changes in employees status, while others affect the earnings and deductions required in payroll. If HR and payroll are to work together smoothly, these transactions must be processed in the most efficient and accurate manner possible.
Over my professional career, a number of principles have become apparent for the design of HR and payroll transactions systems. By systems, I don't just mean computerized software, but all of the decisions around who does what, where it is done and under what form of control.
While some of these principles apply to all employers, others are greatly affected by the employer's size. It's obvious, for example, that payroll controls in a small business rely more on the owner's direct knowledge than would be possible in a larger organization. By contrast, I am not sure how this design is affected by payroll being an organizational unit either under accounting or under HR.
Based on my experience, the following are the general principles that need to be considered when systems for processing employee transactions are being developed or reviewed. These principles deal with the entry, storage and use of employee related data.
3 key principles
Enter data once: The first principle is any such data should only be entered once, whether this is tombstone data from a new hire or timesheets. For this purpose, manually writing down employee contact information and transcribing this into an HR system both count as separate entries. Manual entry of employee tombstone data into isolated HR and payroll systems is a similar example of duplicate data entry.
Store data in only one location: The second principle is any one piece of employee data should be stored in only a single physical location. The most obvious problem here is with employee files, especially where the responsibility for employee hires is distributed, but payroll is centralized. In this situation, there is an almost irresistible urge for each of the different people involved to keep their own set of paper-based files.
Access to data: The last principle deals with access to employee data. Employers will not be able to design systems with single entry and storage, unless the resulting employee data is available to all people who need access. The primary reason multiple copies of employee data are made and kept is to accommodate demands for multiple access.
This set of principles does not prevent employers from dividing employee transactions related responsibilities among several different people, as a fraud prevention technique. However, any such division of labour should not violate the principles described above.
Let's apply the above to a common piece of employee data — the social insurance number (SIN). Current EI and CPP legislation require the employer to ask for and the employee to produce the SIN card, within three days of hire. Among other things, this is so employers can report earnings on the T4 under the precise legal name shown on the card. The best evidence of having seen this card is for the employer to keep a copy in the employee's file. The employee name and SIN on the card must be then entered into payroll.
There are obvious potential inefficiencies in this situation. If the card is photocopied, it might end up in multiple paper-based files, one at the business unit responsible and another in a centralized payroll function. If a photocopy is passed on through the employer's internal mail system to payroll at headquarters, there are the overhead costs involved with this paper handling.
If payroll doesn't have access to the card itself, or a photocopy, there is the potential for transcription errors when communicating to payroll. For example, a line HR person could see the SIN card and copy its number in an e-mail to payroll. Payroll could then read the e-mailed number and manually enter it into payroll.
Each of these duplicate entries is a point at which a transcription error could occur. Most payroll systems now come with functions for validating these numbers. Having these numbers entered centrally, without having seen the card, increases the possibility an error will be made, which can only be resolved through a query back to the business unit responsible.
On the other hand, relying on the business unit to enter the number into HR or payroll is a poor practice in terms of fraud prevention. It's an important division of labour that someone other than the person responsible for a new hire should independently verify that person's identity. This division of labour is an important control, to prevent “dead horses” on the payroll, particularly if a copy of the actual SIN card is not accessible to payroll.
How should employers design systems to process the SIN card, with the least administrative cost and the highest reliability?
Such a system should be based on scanning the SIN card. There are now very inexpensive desktop printers that are also scanners. From such a device, it should be possible to scan the SIN card directly into a networked file system, also accessible to payroll.
The ideal would be an HR application that could scan the card into an electronic database, at the same time as extracting the employee name and SIN, so these don't require separate manual entry. With a scanned SIN card accessible to payroll, less control is required over who actually inputs the employee name or SIN into payroll. These entries can even be done by job applicants themselves, if the name and number entered can later be cross checked against the scanned SIN card.
Alan McEwen is a payroll consultant and freelance writer with 20 years' experience in all aspects of the industry. He can be reached at firstname.lastname@example.org, (905) 401-4052 or visit www.alanrmcewen.com for more information.