Accounting for employee benefits can be quite difficult. For example, benefit suppliers typically react rather tardily to changes in membership so the (accurate) output of an administration system such as Select Benefits is not reflected in the corresponding monthly supplier invoices! This is an overview of how we overcome such issues and account for benefits within Redbourne. We are not saying that our way of doing it is necessarily the best way but hopefully it will get you thinking and help you if you are about to change your benefits scheme or administration processes.
Our scheme
The Redbourne benefit scheme is a full flex scheme where employees are provided with a flex allowance to spend on benefits. They have to spend the full allowance, unused allowance is not available as cash. If they chose to spend more than their flex allowance the difference is taken from gross pay i.e. as a salary sacrifice/exchange.
Changes to all benefits are allowed once a year, to a more restricted set of benefits due to a lifestyle change (roughly births, marriages and deaths), or to Childcare Vouchers on demand.
We are a relatively small organisation, we use a basic PC based accounts package and we outsource payroll to a bureau.
Monthly timing and master data
We are necessarily pedantic when it comes to running our monthly payroll/benefits processes and strictly enforce the concept of master data.
Monthly cycle
The critical date in a month which cannot be missed under any circumstances is, of course, payroll cut-off. In our case all payroll information needs to be supplied to the bureau by the 20th of the month to give us time to check payslips and set up BACS transfers. Working back from this all benefits information for the month needs to be set in stone by the 15th of the month - this has to be so because of legislation surrounding salary sacrifice as well as practical issues such as checking data.
The 15th of the month is our Effective Date. This is a term used by, and a date set in, Select Benefits to indicate that changes made in any benefit sets created with an Active Date after the Effective Date will not appear until the following month's report (see the Administration Guide for more details).
In practice it means that HR have to ensure employees submit their new benefits selections (due to new employment, a new benefit year, lifestyle change etc.) in the first two weeks of the month. And before that HR have to make sure new employees or changed data are entered onto the system, events have been set and employees communicated to so that they can make their selections!
Master data
Many times we have seen business processes fail due to "short cuts" being taken such as directly changing payroll data due to late benefit changes without the necessary changes being made to other systems. It is vitally important that a disciplined approach is taken to data - what data is stored where, who is responsible for its integrity and where data is duplicated between systems, which is the master database.
In our case Select Benefits acts as master for HR data as well as benefits. Report outputs from Select Benefits are used to update spreadsheets for the payroll bureau and to send to benefit suppliers.
Data provided to payroll bureau
There are many different options for what to display on a payslip when it comes to salary sacrificed benefits (see our Payroll Interfacing document for some ideas). In our case we have adopted the simplest approach in which we keep all benefit information off the payslip with the one exception of Payroll Giving due to its unique tax treatment.
So our payslip has:
- gross salary - this is the employee's reference salary less any salary sacrifice but including payroll giving
- payroll giving deduction
- payroll adjustments - such as bonuses or overtime
- payroll deductions - standard deductions such as tax and NI
No pension information is provided or shown as, due to the salary sacrifice set-up, it is all an employer-side payment. Full benefit information is always available to an employee via the Select Benefits site.
Therefore our interface to the bureau is very simple. Every month on the payroll cut-off we supply a spreadsheet, one row per employee, containing employee details and the data shown above.
Tracking benefits
We probably do not need to but in our accounts we track individual benefit costs by employee. A monthly data dump from Select Benefits provides per-employee benefit and salary cost data that is imported into the accounts system against employees - as this just duplicates payroll bureau data if we get much larger we will probably switch to importing aggregate amounts only.
We have set up payroll liabilities and payroll expense accounts, with individual sub-accounts for each benefit, as shown below.
Expenses and liabilities
When we import data we create a payroll expense and a corresponding payroll liability for both benefits and taxes. Gross salaries create only an expense item (which is balanced against a debit to our bank account for the employee's net pay and the tax liabilities).
Class 1A National Insurance
Based on those benefits that are liable to class 1A National Insurance the monthly data dump spreadsheet calculates a class 1A National Insurance liability which is uploaded at the same time as the other data. This enables us to track the total liability and make an appropriate provision for the month against the end of year payment that will need to be made to HMRC.
Supplier reconciliation
Supplier invoices are entered as the actual expense for the month set against the running liability so if the world were perfect the net liability would be zero at some point during a monthly cycle. However this is not usually the case as
- supplier invoices can be over a month after the liability is incurred
- changes in benefit membership reported to the supplier are not acted upon in the current month (some suppliers invoice in advance for the month before the current month's member is available to them)
Keeping track of these differences is simply a bookkeeping task. In general we check the supplier membership data that they base their invoices on and that any backdated changes are backdated to the correct date! Using our system liabilities can occasionally turn into assets if, say, we have a number of leavers that a supplier takes a couple of months to catch up with. However only if we see a liability continually growing or shrinking do we start to worry!
Summary
The keys points from our experience:
- Be disciplined and rigorous with the operation of your monthly processes
- Always modify the master data and re-create reports from it - do not take short-cuts and simply modify the reports
- Expect supplier invoices to be different to the Select Benefits output - they are always behind!
- Don't bother with monthly adjustments to compensate for the above, just check the membership data and backdating
