Embed Size (px)
Citation preview
Tyler R Us
Payroll System Specification
A report to the Directors and the project team
Prepared by Michael A Hather, 14th June, 2014.
Introduction
Page 1 of 51
Tyler R Us is undergoing a period of growth. The current payroll system, while functional, will be inadequate for future use. It doesn’t have the capacity or flexibility for expansion, has labour intensive input and has high maintenance costs. It is therefore the intention to design and new payroll system in house. The new system should meet the Company’s current payment requirements, be flexible enough to incorporate future changes, and should also comply with all legislative requirements.
The current system has both monthly and weekly pay. Both of these could have overtime premiums paid as well as other ad-hoc payments. It also has statutory pay functions such as Statutory Sick Pay and Statutory Maternity Pay. Statutory deductions: such as Income tax (Pay As You Earn), National Insurance, Student Loans and Court Orders. There are also voluntary deductions.
The new system will be designed as a modular system. Each module will have a specific task and will be easy to link to other modules. A modular design will also allow for future expansion should that be required. It will also keep costs down with modules for other non-basic functions only added when required rather than specifying a complete system, part of which may not be used.
The system should also provide ease of data input and administration. This will help to reduce staff costs; a simple input system also provides a safeguard against potential input error.
It should be able to provide reports in standard formats and have a report writer which can access any data as required.
It should be able to store historical data for a minimum of seven years for accounting data, and three years plus the current year for HMRC data.
They system should also have robust security to prevent unauthorised access.
Each individual item will have a priority attached. They are:
(1) Not optional – payroll cannot function without it. (2) Optional – payroll can function without it, but the information or
function could be of great benefit. (3) Additional – payroll can function without it, but the information
or function may be a convenient or future requirement.
Index of Contents
Page 2 of 51
1:01 Employee Pay Master File...................................................................41:02 Payments and Deductions Master File................................................51:03 Pensions..............................................................................................71:04 Data Input Screen.............................................................................111:05 Statutory Sick Pay.............................................................................121:06 Statutory Maternity / Paternity / Adoption Pay..................................161:07 PAYE..................................................................................................241:08 National Insurance............................................................................311:09 Student Loans...................................................................................381:10 Court Orders......................................................................................441:11 Voluntary Deductions........................................................................451:12 Net Pay Calculation...........................................................................461:13 Report Writer.....................................................................................471:14 Validation Checks..............................................................................491:15 Security and Access..........................................................................501:16 Data Storage.....................................................................................52
1:01 Employee Pay Master File
Overview:
The salary and annual hours need to be kept on each employee’s individual record. From this data the system can produce both a monthly
Page 3 of 51
salary figure and an hourly rate. Those rates can then be used by other modules for calculation purposes.
Data Input Requirements:
Annual salary (1)
Annual hours (1)
Pay type indicator – selectable between ‘monthly’ and ‘weekly’. (1)
Pay method – selectable between cash, cheque and BACS. (1)
These need to be kept on a single screen within the employee’s master file.
Calculations to apply:
Monthly salary – divide the annual salary by 12. (1)
Hourly rate – divide the annual salary by the annual hours. (1)
Both these figures should be accessible by any other module. (1)
Additional features:
Global update – there may be a requirement to update salaries in accordance with a company-wide pay rise. A data input screen could be added to the Payroll Processing menu for this with the following:
Data input – percentage of increase to be applied to the annual salary. (2)
Calculation – increase each employee’s annual salary by the above specified percentage. (2)
Date of increase – date from which the increase applies. (2)
Pay type indicator – may need other pay frequencies in the future so could be made flexible enough for this by adding pay periods for ‘two weekly’, ‘four weekly’ and ‘irregular’. (3)
1:02 Payments and Deductions Master File
Overview:
For ease of use and reduction of costs, a single, adaptable module is to be used for both payments and deductions. The module will have selectable
Page 4 of 51
parameters dependent upon its intended purpose. The module should be accessible to the data input screen detailed in section 1:05 both as a selectable item, and as a default item. A selectable item would be required for single payments or deductions, a default item would automatically appear on the data input screen to facilitate ease of data entry. The screen should have individual naming and a ‘save as’ function.
Note: all requirements in the payments and deductions master file are mandatory in order for the pay calculations to work correctly. Everything therefore is priority (1)
Master file input screen:
The payment and deduction master file should have the following selectable items:
1. Payment or deduction – a selectable item to choose: ‘Payment’, a value added to pay; ‘Deduction’, a value taken from pay.
2. Description – a data field to describe the payment/deduction. E.g. ‘Basic Pay’, or, ‘Overtime – 1¼’
3. Payroll type – selectable between ‘monthly’, ‘weekly’ and ‘all’. ‘Monthly’ would only appear on the data input screen for a monthly paid employee, ‘weekly’ for a weekly paid employee, and ‘all’ would appear on all employee’s input screens.
4. Default Display – a Y/N option. Default ‘Y’ displays the payment/deduction on the employee data input screen, ‘N’ does not. An ‘N’ file would still be selectable on the data entry screen.
5. PAYE – a Y/N option. ‘Y’ indicates the payment/deduction is to be subject to PAYE. ‘N’ indicates it is not.
6. NI – a Y/N option. ‘Y’ indicates the payment/ deduction is to be subject to National Insurance. ‘N’ indicates it is not.
7. Pension - a Y/N option. ‘Y’ indicates the payment/deduction is to be subject to pension deductions. ‘N’ indicates it is not.
8. Payment/Deduction Type – selectable from:
Fixed – a fixed amount to be displayed on the data input screen. E.g. union deductions will have set weekly or monthly value.
Value – a numeric value to be input on the data entry. E.g. a bonus will have a single, individual, one-off value.
Rate – uses the hourly rate figure to allow hours to be input via the data input screen. E.g. an employee works 32 hours, a value of 32 is entered in the ‘hours’ field of the data entry screen and the system multiplies the hours by the hourly rate to give gross pay.
Page 5 of 51
Multiplier – a percentage value associated with ‘Rate’ only. Increases the ‘rate’ value by the multiplier percentage. Allows the hourly rate to accommodate variations such as overtime premiums. E.g. payment code ‘Overtime – 1¼’ would have a ‘rate’ to allow hours to be input, and a ‘multiplier’ of 125%. The hourly rate would then by multiplied by 1.25 – that new rate would then be multiplied by the hours input to the data entry screen to give overtime pay.
Note: This multiplier is flexible enough to incorporate all variations of overtime. In addition to the above, basic plus ½ would have a multiplier of 150% and double time would be 200%. It isn’t needed now, but it could also incorporate a night shift premium of basic pay, plus a ⅓ night shift premium of 33% for example.
Additional requirements:
GL code – a general ledger code selectable via a drop down box. The code should be selectable from a list made available by the Accounts Module. There should be the ability to directly type the code if it is known. The payroll system can then correctly post any payment or deduction to the correct expense/balance sheet code as required.
Add – the payment/deduction screen needs an add function in the main payroll parameters menu to create a new blank record.
Name – a full name and a short code to identify the record.
Save – the screen needs a save function to save the record.
Edit – the screen needs an edit function to change data.
1:03 Pensions
Overview:
The payroll system needs to effectively manage the Company’s pension scheme. It needs to be flexible enough incorporate variable percentages for both employee and employer deductions. It needs to have percentage bands dependent upon annual salary. Each of these items should have ease of change to comply with any pension scheme changes.
Page 6 of 51
Note: whether or not an element of pay is pensionable can be selected in the Payments and Deductions module. This is referred to as ‘pensionable pay’ and is not necessarily the same value as ‘gross pay’.
Pension Master File:
This file is part of payroll parameters and stores data about pension scheme percentages and salary bands. There should either be a single screen, or a screen with tabs to accommodate the data - it should have the following:
An ‘add’ function to create a new band and a ‘save’ function to save changes. (1)
Have a data field for the name of the pension scheme. (1) Have a data field for the ECON number (employer’s contacted out
number). (1) Have a data field for the SCON number (scheme contracted out
number). (1) Have a data field for the Employer Pension Scheme Reference
(EPSR). (1) Have a data field for the Pension Scheme Registry number (PSR). (1) Be able to have a start and end annual salary figure applied to each
band. E.g. Band 1: salary 0-9999, 2.50% employee, 7.00% employer; Band 2: salary 10000 to 14999, 2.75% employee, 7.50% employer; Band 3: salary 15000-19999, 3.00% employee, 8.00% employer, etc. (1)
Have an input percentage value for employee and employer values (as above). (1)
Calculations to be performed:
Apply the percentage values for employees to that employee’s pensionable pay for the pay period being calculated, and to deduct that value from the employee’s gross pensionable pay. (1)
Apply the percentage values for employers to that employee’s gross pensionable pay and to also attribute that value to the pension cost code for that employee’s department. (1)
Additional features:
Page 7 of 51
The system may be required to:
Be able to have more than one pension master file. If the Company has more than one pension scheme, these will need to be recorded separately. (1)
Have a global update feature to change employee and employer percentage values and apply it to the employee’s pension record by default in the event of a change to the pension scheme. (2)
Employee Pension File:
This is displayed on an individual employee’s record. It should have the following:
An ‘add’ record function, with ‘scheme name’, ‘edit’ and ‘save’ functions. (1)
Have a data field for the employee’s pension reference number. (1) Scheme entry date and scheme end date. (1) Have selectable status – ‘contractual enrolment’ to show the
member was enrolled as a condition of their contract of employment; ‘auto enrolment’ to show the member was enrolled under auto enrolment regulations. (1)
Have selectable status – ‘active’ to apply the record to the employee’s pensionable pay; ‘inactive’ to retain the information but not apply it to pay; ‘closed’ to indicate the employee’s membership of the scheme has ended; ‘inactive – opted out’ the retain the information but not apply it to pay and to show the employee has chosen to opt out of the scheme. (1)
Have a link to the scheme record created in the pension master file. (1)
Be able to store more than one record in case there is more than one pension scheme. (1)
Have an ‘apply defaults’ option to create employee and employer percentages from the employee’s annual salary – that salary figure applied to the pension bands in the Pension Master File. (1)
Have the option to select between calculating pension based on annual salary or based on this period’s pensionable pay. (1)
GL code – employee. The balance sheet code for employee’s pension should be selectable from the Accounting module. This will apply the employee’s pension value to that code. (1)
GL Code – employer. The department cost code for employer’s pension should be selectable from the Accounting module. This will apply the employer’s pension value to that code. (1)
Employee pensions input screen:
Page 8 of 51
An input screen is required to enter the following temporary adjustments for a pay period:
Manual overrides – both the employee’s and employer’s pension should have an input field to override percentages, and an input field to override values. It should also have an override for pensionable pay – note: this is for pension recording only and is not applied to the employee’s pay. All these should also be selectable as ‘permanent’, to apply the override each pay period, or ‘this period’ for a single period override. (1)
Refunds: the override feature above should allow negative input values for all the above value fields to enable employee refunds due to opt-outs, and to correctly record cumulatives for employee’s pension, employer’s pension and pensionable pay. (1)
NI adjustments due to opt-outs – the NI module should be able to adjust NI for previous periods due to a change in NI table letter. There will be a detailed explanation of this in the NI Module later in this document. (2)
Note: Some of the above priority (1) features throughout the pensions module may not be required for calculating payroll, but are records which need to be kept to comply with regulations from The Pensions Regulator.
Cumulatives:
The pension record for each employee needs to store year to date figures for employee’s pension, employer’s pension and pensionable pay. (1)
Calculation:
Based on annual salary:
The system applies the annual salary to the correct annual salary band in the Pension Master File to determine the percentages for employee’s and employer’s pension. (1)
These percentages are then applied to the pensionable pay for the current period to obtain the values for employee’s and employer’s pension. (1)
E.g. Monthly Salary: £1250.00, annual salary £15000, employee’s pension £37.50, employer’s pension £100.00 (using the example percentages from the Pension Master File section for a salary of £15000).
Based on ‘this period’ pay:
Page 9 of 51
The system uses the pensionable pay for the current pay period to determine the employee and employer pension percentages. (1)
For a monthly pay period, the correct percentage band is determined my multiplying the monthly pensionable pay by 12. (1)
For a weekly pay period, the correct percentage band is determined my multiplying the weekly pensionable pay by 52.143. (1)
E.g. Weekly pay: £300.00. Therefore £300.00 x 52.143 = £15642.90; using the examples in the Pension Master File section the pension salary band percentages are 3.00% employee and 8.00% employer.
1:04 Data Input Screen
Basic Requirement
Data need to be input to the system by a quick and easy method. A single input screen is required to facilitate data input. This screen should be available from both the main menu and the employee file. The screen should show default payment and deduction codes as defined in the Payments and Deductions Master File. Other payment and deduction codes should be selectable via an ‘add’ function.The screen should be selectable by employee, monthly paid, weekly paid or all employees.The screen should also have ‘next employee’ and ‘previous employee’ selection buttons for ease of data input.
Page 10 of 51
Default displays: the screen should show items selected as default in the Payment and Deductions Master file and have an input field for hours or values as defined in there. (1)E.g. A weekly employee’s input screen might show as default: Basic Pay, Overtime 1¼, Overtime 1½, Overtime 2, Bonus Pay, Holiday Pay, Union Deduction, and Health Scheme Deduction. Each would have an input field for hours, pay, or display a fixed amount - each as defined in the Payment and Deductions Master File.
It should have a ‘save’ function to save all data. (1) It should have and ‘edit’ function to change temporary or fixed data.
(1) It should have a ‘delete’ function to remove an unwanted item. (1) If any data is entered or changed, a warning should be issued if an
attempt to close the screen is made without saving (1) The ‘save’ function should also do a net pay calculation (2)
1:05 Statutory Sick Pay
Overview:
By law the Company has to pay employees for sickness absence, referred to as Statutory Sick Pay. Employees entitled to receive payments of Statutory Sick Pay can do so for up to for up to 28 weeks. Even if the Company has a contractual sick pay scheme which exceeds the amount of SSP, SSP still has to be recorded as being paid. The system needs to calculate average pay for the correct period to determine entitlement. It needs to record SSP start dates and end dates, and also calculated linking periods between absences. It needs to apply a three day waiting period of no SSP payment to the start of each absence, but not if that absence is linked to a previous SSP absence by 56 days or less. The system therefore needs to:
Page 11 of 51
Calculate average weekly earnings (AWE) for an employee based on a period of eight weeks (the Relevant Period) ending in the last pay date prior to the first day of absence and store that average on their record (1)
Calculate the AWE correctly for monthly paid employees – see AWE – monthly paid working example below (1)
Use the employee’s gross pay figure for National Insurance contributions for the AWE (1)
Calculate a correct AWE if the employee has been employed for less than eight weeks by using the average of the weeks actually employed (1)
Do not pay SSP if the AWE is below the Lower Earnings Limit (LEL) for National Insurance as shown in the National Insurance module (1)
Issue a warning if the AWE is below the LEL (1) Issue a prompt to complete for SSP1 if the AWE is below the LEL (2) Only calculate SSP is the absence is a qualifying period (called a
Period of Incapacity for Work, or PIW) of four days or more (1) SSP is not applied to the first three days (called Waiting Days, or
WDs) of a PIW (1) Calculate if the period of absence is linked to a previous qualifying
absence of four days or more by a period of 56 days or less (1) Identify Qualifying Days (QDs), that is, normal working days for
which SSP is payable by individual employee (same as the ‘defaults’ shown on the table below) (1)
Be able to store the current SSP rate, and be able to divide that rate by the number of qualifying days to achieve an unrounded daily rate (1)
Multiply that daily rate by the number of Qualifying Days in the pay period (1)
For linked periods of absence, use the AWE’s which apply to the first date of absence (1)
Correctly calculate when the 28 weeks maximum entitlement is reached (1) and,
Issue a prompt from week 21 of that entitlement to complete form SSP1 (2)
Keep start and end dates as a record (1) and, Show that record as a yearly calendar with an indication of absent
days, waiting days and SSP days (3) Apply ‘offsetting’. That is, also apply the SSP as a deduction in
addition to being applied as a payment – this is used, for example, for staff with a fixed monthly salary or staff whose pay does not alter due to receiving occupational sick pay which exceeds the value
Page 12 of 51
of SSP. In this way the employee’s pay remains the same, but SSP is still recorded as a payment to comply with statutory and audit requirements (1)
Pay the SSP for both weekly and monthly paid staff; this will be determined by the ‘from’ and ‘to’ dates entered for the period of absence (1)
SSP input screen:
There is a requirement to have an input screen for SSP, selectable by employee. It should have:
a start date and end date for the period of absence being processed, input either directly as dates (1) or selectable from a calendar (2)
A selectable box on the input screen to apply the SSP as a deduction (offsetting) (1)
Have a manual input override on the input screen for (AWE) in case the employee has not been paid during the relevant period for any pay they are contractually entitled to (1)
Have a tick box to indicate a link to a previous period of absence (the system should do links automatically but a manual tick box should be available anyway) (1)
Have a warning to prevent advance payments of SSP – a weekly paid employee going sick this week for example, who had a doctor’s note for four weeks, should only receive one week’s SSP in this pay period (2)
Add, save and edit functions (1)
Additional note:
SSP is treated as pay for PAYE and NI purposes (1)
SSP Master File:
The SSP data defaults could be stored on the system as a table, an example of which is shown below:
Page 13 of 51
Calculation examples:
An example of daily rates and a calculation are shown below:
Daily rates table for days of sickness from 6 April 2014 to 5 April 2015
Unrounded daily rates
Number of QDs in week
1 day to pay
2 days to pay
3 days to pay
4 days to pay
5 days to pay
6 days to pay
7 days to pay
£12.5071 7 £12.51 £25.02 £37.53 £50.03 £62.54 £75.05 £87.55£14.5916 6 £14.60 £29.19 £43.78 £58.37 £72.96 £87.55£17.5100 5 £17.51 £35.02 £52.53 £70.04 £87.55£21.8875 4 £21.89 £43.78 £65.67 £87.55£29.1833 3 £29.19 £58.37 £87.55£43.7750 2 £43.78 £87.55£87.5500 1 £87.55
Examples:
Employee worksQDs in a
weekPeriod of sickness PIW
Number of WDs
Number of days SSP is payable
for
Total due for that week
Monday to Friday 5 5 5 3 2 £35.02Tuesday, Thursday,
Friday3 3 0 0 0 £0.00
Tuesday, Wednesday, Thursday, Friday
4 4 4 3 1 £21.89
Monthly Paid – AWE working example from HMRC
To work out the AWE for employee's paid calendar monthly.
1. Find the date of the last normal pay day before the first day your employee was sick. This is the last day of the relevant period.
2. Count back to the payday at least eight weeks from date 1 and come forward one day.
Page 14 of 51
3. Add together all the earnings paid between the dates in 2 and 1 (inclusive).
4. Work out how many whole months there are between 1 and 2 5. Divide the figure in 3 by the number of whole months in 4 6. Multiply the figure in 5 by 12.7. Divide the figure in 6 by 52 (Do not round up or down to whole
pence, use the unrounded figure to decide if the employee’s AWE are high enough).
An example of above
First day of PIW is 08.05.2012
1. The last day of the month - Monday 30 April 20122. Payday at least eight weeks back is 29 February 2012, forward
one day is 1 March 2012 3. £1999.96 (this covers the period 29 February to 30 April 201209 - 2
payments)4. Divide £1999.96 by 2 = £999.985. £99.98 multiplied by 12 = £11999.766. £11999.76 divided by 52 = £230.76461
GL Coding
SSP should be coded to the same departmental GL code as gross pay
1:06 Statutory Maternity / Paternity / Adoption Pay
Overview:
By law employees are entitled to receive payments for Statutory Maternity Pay, Statutory Paternity Pay and Statutory Adoption Pay, should they qualify. The system needs to be able to identify which employees are entitled, for what period they are entitled, how much pay they should receive and for how long they should receive it. As these payments are weekly, it also needs to know how to make payments to monthly paid employees. There is also a requirement to ‘reclaim’ 92% of this pay back from HMRC and to correctly allocate the 92%/8% to the correct GL codes.
For SMP, the system therefore needs to:
Identify if the employee has been employed continuously for 26 weeks up to the Qualifying Week (1)
Identify the Qualifying Week (QW), that is, the 15th week (Sunday to Saturday) before the week the baby is due (EWC – Expected Week of Childbirth) (1)
Have a start date and end date for the Maternity Pay Period (1)
Page 15 of 51
Calculate Average Weekly Earnings (AWE) for the ‘relevant period’ (see example below) (1)
Use pay on which national insurance contributions are payable (NI’able pay) for the AWE (1)
Identify the relevant period as the eight weeks up to and including the last pay date before the QW (1)
Issue a warning that SMP is not due if the AWE is below the lower earnings limit for National Insurance (LEL - see section 1:08) (1)
Recognise SMP is payable for a maximum of 39 weeks (1) Use the start and end dates to pay 6 week’s pay at 90% of average
earnings (1) and, pay the remaining 33 weeks at either the statutory rate (£138.18 for
2014/15) or 90% of the AWE if that is lower (1) stop paying SMP if the employee returns to work (1) identify if the SMP is to be paid on its own, as part of a salary
payment or in addition to salary (1) calculate part weeks to align SMP payments to normal pay days (1) identify the latest start date for employment with us (1) treat SMP as normal pay for PAYE and NIC purposes (1) Do not start SMP payments before the start of the 11th week before
the week the baby is due (1)
SMP Input Screen:
The following data needs to be input into the payroll system for it to calculate SMP:
Date the baby is due (EWC – Expected Week of Childbirth) (1) Date the baby was born if birth was early (1) Start date for the Maternity Pay Period (1) Date of expected return to work (1) Payment method identifier: single payments; to be deducted from
salary (offset); to be paid in addition to salary (e.g. half pay plus SMP) (1)
SMP / Childcare parameter data storage
The system needs to store:
payment values (1) average weekly pay thresholds (same value as LEL in NI module)
(1) weeks payable (1) and weeks at percentage rates (1) value of percentage rates (1)
Page 16 of 51
As all these figures can change, they are best stored as a table in the main payroll master file. An example of a child care table is shown below.
Note: the same table can be used for Statutory Maternity Pay (SMP), Statutory Paternity Pay (SPP), Additional Statutory Paternity Pay (ASPP) and Statutory Adoption Pay (SAP).
Example: SMP critical dates
Table of dates the system could store to make entitlement calculations easier (limited to three rows for clarity):
Week baby Due Qualifying Week Latest date for start of employment
Start of 11th week before the week the baby is due
Start of the 4th
week before the baby is due
Sunday Saturday Sunday Saturday Saturday06/04/14 12/04/14 22/12/13 28/12/13 06/07/13 19/01/14 09/03/1413/04/14 19/04/14 29/12/13 04/01/14 13/07/13 26/01/14 16/03/1420/04/14 26/04/14 05/01/13 11/01/14 20/07/13 02/02/14 23/03/14
Page 17 of 51
On entering the EWC into the input screen, they system would then reference these date tables and perform the correct entitlement calculation.
Example: Calculate Average Weekly Earnings (AWE)
AWE must include all earnings on which Class 1 NICs are due (NI’able pay), or would be due if they were high enough. SMP entitlement depends on the employee’s Average Weekly Earnings (AWE) in the ‘relevant period’. Therefore the AWE must be:
£109 or more for tax year 2013 to 2014 £111 or more for tax year 2014 to 2015
Requirement:
The system will have access to the above figures as they are the Lower Earnings Limit as defined in the National Insurance section detailed in section 1:08. It will also store the NI-able pay for each pay period. It will then need to divide all NI’able earnings paid in that relevant period by the number of days, weeks or months in that period.
Example: The relevant period
This is usually the 8 week period before the QW.
The end of the relevant period is the last normal payday on, or before the Saturday of the QW (or the date the baby is born where this is before or during the QW). The system will need to identify this date from the baby’s due date as entered into the SMP input module.
The start of the relevant period is the day after the last normal payday falling at least 8 weeks before the end of the relevant period.
Example for an employee who is weekly paid where the baby is due on 25 March 2014:
Qualifying week
Payday
Last payday at least 8 weeks before the end of the
relevant period
Last payday on or before the Saturday of
the QW8 Dec 2013 to 14 Dec 2013
Friday 18 Oct 2013 13 Dec 2013
Page 18 of 51
In this example the relevant period is 19 October 2013 to 13 December 2013.
The system needs to add up all the earnings paid between 19 October 2013 and 13 December 2013 and divide by 8 (the number of weeks in the relevant period).
These figures should not be rounded up or down to whole pence.
Example for an employee who is monthly paid and the baby is due on 11 February 2014:
Qualifying week
Payday Last payday at least 8 weeks before the end of
the relevant period
Last payday on or before the Saturday
of the QW
27 Oct 2013 to 2 Nov 2013
Last working day of the
month
31 Aug 2013 31 Oct 2013
The relevant period is 1 September 2013 to 31 October 2013. The system needs to add up all the earnings paid between 1 September 2013 and 31 October 2013 and then:
divide by 2 (number of months in the relevant period) multiply by 12 (number of months in the year) divide by 52 (number of weeks in the year)
These figures should not be rounded up or down to whole pence.
Monthly paid employees without a whole number of months in the relevant period
The system should work out the number of rounded months as follows:
count the number of whole months in the Relevant Period count the numbers of odd days in the Relevant Period
Round the days up or down as follows:
February - 14 days or less round down, 15 days or more round up any month except February – 15 days or less round down, 16 days
or more round up
It should then divide the earnings by this number of rounded months.
Page 19 of 51
Calculation: Statutory Maternity Pay payments
When the AWE has been calculated, the amount of SMP due can be worked out. This should be paid to the employee over their normal pay period and on their normal pay day.
SMP is a weekly payment and SMP pay weeks start with the first day of the SMP pay period, e.g. an SMP pay period that starts on a Wednesday will have pay weeks within the pay period which runs from Wednesday to Tuesday the following week.
SMP is payable:
90% of the employee’s AWE for the first 6 weeks £138.18 from 6 April 2014 or 90% of their AWE (whichever is lower)
for the remaining weeks
Calculation: SMP paid part weekly
SMP can be paid in part weeks if it helps to align the payments to the employees normal pay period. The system will need to be capable of doing this. Divide the weekly rate by 7 and multiply by the number of days for which SMP is due in the week or month. For example, if the pay period covers the end of 1 month and the beginning of the next (2 days in April and 5 days at the beginning of May) then pay two-sevenths in 1 month and five-sevenths at the beginning of the next month (1)
Statutory Paternity Pay
An employee can take paid time off work if their partner is having a baby or adopting a child. They could be eligible for:
1 or 2 weeks paid Ordinary Paternity Leave paid as Statutory Paternity Pay (SPP)
up to 26 weeks’ paid Additional Paternity Leave - but only if the mother / co-adopter returns to work – payable as Additional Statutory Paternity Pay (ASPP)
Ordinary Paternity Leave must be taken in one go and could be either one or two weeks.
The system needs to:
Identify if the employee has been employed continuously for 26 weeks up to the Qualifying Week (1)
Have input for the date of childbirth / EWC (1) Have input for the start and end dates of the leave (1)
Page 20 of 51
Determine if the employee earns above the LEL and (1) Calculate the AWE as per SMP (1) Issue a warning if the AWE is below the LEL (1) Make sure the leave starts after the date of birth (1) Make sure the leave ends within 56 days of the birth (1) Have one or two weeks leave selectable on input (1) Have start and end dates for Additional Paternity Pay (1) Ordinary Paternity Pay (OPP) and Additional Paternity Pay (APP) are
treated as normal pay for PAYE and NIC purposes (1)
Rates of SPP/ASPP
The statutory weekly rate of Ordinary Paternity Pay and Additional Paternity Pay is £138.18, or 90% of the employee’s average weekly earnings (whichever is lower).
SPP/ASPP input screen:
The input screen for SPP/ASPP should have:
Entry for the date of EWC (1) Select whether the payments is for SPP or ASPP (1) The number of weeks to be paid for SPP (one or two) (1) The start date and end date of leave SPP is to be paid for (1) The start date and end date of leave ASPP is to be paid for (1) Have add, save and edit functions (more than one input can be on
the employee’s record - to separate SPP and ASPP) (1)
Statutory Adoption Pay
An employee is entitled to 52 weeks Statutory Adoption Leave on the adoption of a child. The 52 weeks is made up of 26 weeks Ordinary Adoption Leave and 26 weeks Adoption Leave. The employee taking leave is entitled to 39 weeks Statutory Adoption Pay. Statutory Adoption Pay starts when the employee starts their leave period. The system needs to:
Be able to input a start and end date for the leave (1) Be able to input a ‘matching date’ – the date the adopter is matched
to the child (1) Use the same qualifications i.e. AWE, length of employment, as SMP
(1) Calculate SAP as £138.18 or 90% of the average weekly earnings
before tax (whichever is lower) (1) Apply the SAP from the start of the leave period Automatically calculate the end date of the adoption leave period
(2)
SAP input screen:
Page 21 of 51
The input screen for SAP should have:
Entry for the matching date (1) Start date of the adoption leave period (1) End date of the adoption leave period (1) Have add, save and edit functions (1)
Calculation:
SAP is calculated as £138.18 or 90% of the average weekly earnings before tax (whichever is lower)
It needs to start from the date of the leave period Part pay period payments need to calculated the same as for SMP
above
Note: SAP is pay for PAYE and NI purposes
SAP data parameter storage:
The data required for calculation will be stored in the same table as for SMP above.
GL Coding
The 92% reclaim should be coded to balance sheet control accounts for SMP, SPP (and ASPP), and SAP. The 8% remainder should go to the same departmental GL code as gross pay.
1:07 PAYE
Overview
Page 22 of 51
The ‘Pay As You Earn’ scheme is the method by which HM Revenue & Customs collects tax from employees. A system operating PAYE has to perform a number of complex calculations. It has to: understand how different tax code letters operate, calculate an employee’s freepay (personal allowance), use bands to calculate tax percentages and be able to calculate these on a cumulative (year to date) and non-cumulative basis (a single period).
Note: PAYE is mandatory so all items listed here are priority (1)
Tax code letters, values and bands
Each employee is issued with a tax code individual to them. It is from that the system will determine how much tax to deduct from the employee each pay period. For example, in the tax year 2013-14, an employee’s tax code might be 944L which means they can earn £9440 for the year before paying tax. Below will described each type of data required to operate PAYE, a details of how these operate will be shown in the ‘calculation’ section below.
The codes should be entered onto each employee’s master file in the form of selectable letters and code values. Also required is a tick box to indicate whether the tax is cumulative, or non-cumulative (operated on a period 1 basis). An example of this type of master file is shown below:
Page 23 of 51
The data for PAYE is entered in the ‘PAYE – TAX Details’ area and input consists of:
Prefix – this will be either K or D Code – a number in the range 0-99999 Suffix - will be L, P, V, Y or T Period 1 flag – a tick box to operate the code on a non-cumulative
basis
Tax percentages are applied to the employee’s taxable pay. For purposes of PAYE, the definition of taxable pay is the amount of pay after the personal allowance (freepay) has been deducted. This can be a little confusing as gross pay on which tax is paid can also be called taxable pay. Taxable pay (as defined for PAYE purposes) is applied to a series of bands to determine the percentage of tax to be deducted. These band and values can change and so need to be stored on a table in the Payroll Parameters Master File. An example is shown below:
Page 24 of 51
The table here has the input requirement of:
Rebate maximum – the amount of tax refund the system can allow Suppress if 0 pay – to prevent tax being calculated in a period of no
pay which could produce a payslip with a negative value in some circumstances
Regulatory Limit – for use with a K code and defines the maximum amount pay to be taken as tax
Band – any number of bands as required Width – the amount of taxable pay to which the band applies Percentage – the percentage of tax applied to the band
Tax coding letters – definitions
Page 25 of 51
From above we can see tax code letter can be made from a prefix and a number, a number and a suffix, or just letters. The explanation of how these apply is as follows:
Tax code NT: the ‘N’ is for no tax and the ‘T’ is the suffix. On this code no tax is deducted from pay. A record of the payment must still be kept. Although technically an NT code is operated on a non-cumulative basis, the period 1 marker (or flag) should never be used as this will invalidate the RTI (Real Time Information) submission to HMRC
Tax code 0T: ‘0’ is no free pay and the ‘T’ is the suffix. 0T does not have any freepay (personal allowance) and therefore all the pay is taxable by the relevant band percentage
Tax code BR: Code BR also has no freepay (personal allowance) deducted. All the pay is taxed at the lower rate, currently 20%. It is usually cumulative but HMRC can indicate use on a non-cumulative basis
Tax code D0: D is a prefix and 0 the code number. Code D0 also has no freepay (personal allowance) deducted. All the pay is taxed at the higher rate, currently 40%. It can be cumulative or non-cumulative
Tax code D1: D is a prefix and 1 the code number. Code D1 also has no freepay (personal allowance) deducted. All the pay is taxed at the additional rate of, currently 45%. It can be cumulative or non-cumulative
Tax code K: K is a prefix followed by a number. With a K code, freepay (personal allowance) is added to gross pay not deducted.
Calculation - Regulatory Limit
Because the K code adds ‘freepay’ to gross pay to obtain the taxable pay figure, liability for tax can be very high. In the case of someone receiving a reduced salary in a pay period, the tax liability could even exceed pay. For this reason K codes have a ‘Regulatory Limit’; currently set at 50% the Regulatory Limit prevents more than 50% of gross pay being taken as tax. Any excess is carried forward to the next pay period.
Calculation – freepay (Personal Allowance)
Page 26 of 51
Freepay is the amount of pay each employee is allowed to earn before paying tax. The system needs to be able to correctly calculate the amount of freepay from the employee’s tax code. However, this calculation is not as simple as it may first appear. If we use the tax code 944L as an example, the personal allowance for the year is £9440. For calculating freepay, we need to add a 9 to the code so 944L becomes 9449. This figure should then be divided by the number of pay periods over which the employee is paid (12 for monthly, 52 for weekly). That figure is then rounded up to the nearest whole pence.
For example: a weekly paid employee is paid on week 1 and their tax code is 944L. Therefore 944L = 9449 and 9449 / 52 = 181.7115 which is then rounded up to 181.72. If we look at HMRC’s pay adjustments tables, table A and follow the instructions shown below:
Code more than 5001 Where the code is in the range 501 to 1000 inclusive:a. Subtract 500 from the code and use the balanceof the code to obtain a pay adjustment figure fromthe table above.b. Add this pay adjustment figure to the figure givenin the box alongside to obtain thefigure of total pay adjustment to date * 96.16
And an excerpt from the table:
441 84.99442 85.18443 85.37444 85.56445 85.75
By adding 96.16 to 85.56 we get 181.72, which show the calculation works.
Calculation – cumulative and non-cumulative
What is now done with the freepay and which period’s freepay is to be used, depends on whether the tax code is to be applied cumulatively or non-cumulatively (period 1 basis).
Cumulative has figures for gross taxable pay and tax paid calculated on a year to date basis. For example:
A monthly paid employee receives £2000 per month gross pay. In month 1 the tax paid in 2014-15 for tax code 1000L will be £233.00. In month 2, the system will need to calculate tax by applying freepay as at month 2, the total gross pay for the year, and the tax already paid. So for month two, the tax for £4000 gross year to date will be £466.20 (year to date) –
Page 27 of 51
less £233.00 already paid means £233.20 tax is to be paid in month 2. This allows the tax to adjust up or down depending of the employee’s pay year to date.
Non-cumulative uses the freepay figures for period 1 for each separate pay period and does not use year to date figures. In the example above, the pay for period 2 will be calculated using period 1 figures regardless of what was earned in period 1.
Calculation – tax bands and taxable pay
Once we have established the ‘freepay’ above and whether or not the tax is cumulative or non-cumulative, we can apply the employee’s taxable pay to the tax band percentages.
Taxable pay is obtained by taking the freepay off gross pay (taxable gross pay). The figure for taxable pay is then rounded down to the nearest whole pound.
This is a simpler calculation which divides the tax band by the number of periods to determine which percentage is applied. The percentage is then applied to the taxable pay.
Using the example above, 1000L in period 1 gives us freepay of £834.09 and taxable pay of £1165.91, rounded to £1165. £1165 is less than £31865 / 12 so, £1165 x 20% = £233.00.
For period 2, freepay is £1668.19. Year to date pay is now £4000, so £4000 less £1668.19 is £2331.81. £2331.81 rounded down to £2331 at 20% gives us £466.20 tax year to date. £466.20 tax year to date less £233.00 paid in period 1 leaves us with £233.20 to be paid in period 2.
Calculation – holiday pay advances (weekly paid)
The number of weeks to be advanced should be selectable when inputting holiday pay. For example: a weekly employee is taking two weeks holiday and they are to receive an advance of two weeks holiday pay on the pay date in week 7. On input, ‘advance tax weeks by 2’ will be selected. The system will the calculate tax cumulatively as if it were week 9. For employees on a period 1 coding, the system should work out each week separately.
PAYE Data to be held on employee records
Employee records must contain:
Gross pay, this period and year to date
Page 28 of 51
Taxable pay, this period and year to date Tax paid, this period and year to date
GL Coding
PAYE should be coded to a balance sheet account for PAYE
1:08 National Insurance
The National Insurance (NI) scheme is run by HMRC to collect contributions from employees and employers. It is a legal requirement to operate the National Insurance scheme and so it’s inclusion in payroll is mandatory. The system consists of a table of letters, called categories, each of which has a purpose and associated percentages. The
Page 29 of 51
percentages are also reference to a series of pay bands to determine how much National Insurance is deducted.
Note: as National Insurance is mandatory, all items listed are priority (1)
NI Tables
Below is an example of how tables of National Insurance are presented on a payroll system. Abbreviations used for National Insurance in these tables and the text below, are:
LEL – Lower Earnings Limit ET – Earnings Threshold PT – Primary Earnings Threshold (employee) ST – Secondary Earnings Threshold (employer) UEL – Upper Earnings Limit UAP – Upper Accrual Point
Page 30 of 51
Note: categories F, G and S are not used from 6th April 2012 and are not required for the new system. For system design it isn’t necessary to understand what each letter represents.
Rebates
What isn’t clear from the table is the contracted out contributions (D to S on the table) have a rebate system of calculation compared to non-contracted out contributions (A, B, C and J). Currently this rebate is 1.4% for employees and 3.4% for employers. The rebate also operates from the Lower Earnings Limit whereas the NI deductions start from the Earnings Threshold. This means a negative amount of National Insurance Contributions (NICs) are due between the Lower Earnings Limit and the Earnings Thresholds.
Page 31 of 51
For example:
Primary (employee) contracted-out NICs
Up to Lower Earnings
Limit
Up to Primary
Threshold
Up to Upper Accrual Point
Up to Upper Earnings
Limit
Earnings in excess of
Upper Earnings
LimitNil -1.4% 10.6% 12% 2%
Secondary (employer) contracted-out NICs
Up to Lower Earnings Limit
Up to Secondary Threshold
Up to Upper Accrual Point
Earnings in excess of Upper
Accrual PointNil -3.4% 10.4% 13.8%
Calculation
For purposes of National Insurance calculation, rounding is important. All National Insurance contributions should be calculated to three decimal places and where the third decimal place is 6 or more it should be rounded up.
The system will need to:
Store a table letter for each employee Have a tick box to identify if the employee is a director Identify on which earnings National Insurance is payable (NI’able
pay) Correctly apportion that NI’able pay to the correct bands and Apply the correct percentage for that band Deduct the NICs calculated from the employee’s NI’able pay For advanced holiday pay (weekly paid) calculate each week
independently
Important Note:
National Insurance is calculated on a per period basis and is not cumulative. The system needs to correctly identify the pay period and apply NI to that period. For advance payments, such as holiday pay, it needs to treat these as separate weeks for calculation purposes.
Page 32 of 51
Data Input
Data input will require:
Input on the employee master file for that employee’s table category letter
Input to the example tables shown above for percentages and bands. These tables to be kept in the payroll system parameters master file
Data to be held
For National Insurance purposes, the system needs to store against each table letter for each employee:
the date of payment of each payment of earnings the gross amount of earnings earnings up to the Lower earnings limit (LEL) earnings from the LEL to the Primary Threshold (PT) earnings from the PT to the Upper Accruals Point (UAP) earnings from the UAP to the Upper Earnings Limit employee's NICs payable employer's NICs payable
Note: if the employee changes table letter, say from A to D when joining the pension scheme, the system needs to store the above data individually against each letter.
Director’s NICs
Directors’ NICs are worked out on a cumulative basis unlike other employees whose NICs are worked out pay period.
NICs must therefore be worked out each time a payment of earnings is made to a director.
The system must therefore:
work out the NICs on the total earnings paid to date in the tax year or pro rata period
deduct the NICs already paid, if any.
This gives the NICs now due.
Example (from HMRC): To work out a director’s standard rate NICs:
Page 33 of 51
multiply those earnings which exceed the annual (or pro rata annual) PT, up to and including the annual (or pro rata annual) UAP by the appropriate not contracted-out or contracted-out percentage rate.
Round to the nearest penny, rounding down exact amounts of 0.5p. Multiply those earnings which exceed the annual (or pro rata
annual) UAP, up to and including the annual (or pro rata annual) UEL by the appropriate not contracted-out percentage rate.
Round to the nearest penny, rounding down exact amounts of 0.5p. Deduct any employee’s contracted-out NIC rebate to which the director is entitled. Multiply those earnings which exceed the annual (or pro rata annual) UEL by 2%. Round to the nearest penny, rounding down exact amounts of 0.5p. Add the totals together.
This gives the NICs now due.
To work out the company’s NICs, multiply those earnings which exceed the annual (or pro rata annual) ST, up to and including the annual (or pro rata annual) PT and from the annual (or pro rata annual) PT up to and including the annual (or pro rata annual) UAP by the appropriate not contracted-out or contracted-out percentage rate.
Round at each stage to the nearest penny, rounding down exact amounts of 0.5p. Multiply those earnings which exceed the annual (or pro rata annual) UAP, up to and including the annual (or pro rata annual) UEL by the appropriate not contracted-out percentage rate. Round to the nearest penny, rounding down exact amounts of 0.5p.
Deduct any employer’s and, if appropriate, any employee’s contracted-out NICs rebate to which the company is entitled. Multiply those earnings which exceed the annual (or pro rata annual) UEL by the appropriate not contracted-out percentage rate. Round to the nearest penny, rounding down exact amounts of 0.5p. Add the totals together.
This gives the NICs now due.
GL Coding
Employee’s contributions should be coded to a balance sheet account for National Insurance Contributions. Employer’s contributions should be
Page 34 of 51
coded to a P&L departmental account for Employer’s National Insurance. The system needs to show correctly all rebates as a credit figure
1:09 Student Loans
Overview
Page 35 of 51
The collection of student loans is a statutory requirement and therefore must be included as part of the payroll. The deduction is based on the employee’s NI’able gross pay. It is currently 9% of pay which exceeds an annual threshold (£16190 for 2014-15). The Student Loans Company can issue start and stop notices for specific dates and, a student loan can be indicated on an employee’s P45 or Starter Declaration.
System Requirements
The system needs to:
Have a student loan deduction indicator on the employee master file (1)
Have start date and end date kept on the employee master file (1) Store a threshold value on the payroll parameters master file (1) Store a percentage value on the payroll parameters master file (1)
Calculation
Student Loans are not cumulative, so each calculation is on a period basis. The calculation needs to:
Ensure the pay date on which the deduction is to be taken is within the start and end dates stored for the employee (1)
Use the annual threshold divided by the number of pay periods in the tax year to determine the threshold for that period (1) and
Round those figures down to the nearest whole pound (1) Use the employee’s NI’able pay for the pay period, less the
threshold for the pay period (1) and Calculate the loan as a percentage of the remainder (1) Calculate separate weeks for advanced holiday pay (1)
1:10 Court Orders
Overview
Page 36 of 51
Court Orders, also known as Attachment of Earnings Orders (AEO), are a legal requirement. To not operate an AEO could lead to fines or imprisonment. The company may receive an order from the Centralised Attachment of Earnings Payments System (CAPS), a court, a local authority, or the Child Support Agency (CSA) to make deductions from the earnings of an employee. The company could also receive a schedule of arrestment by an officer of the Scottish courts. The order will have been made because the employee:
• has incurred a debt or fine which a court has ordered them to pay
• is in arrears with a Council Tax bill or• has been ordered to pay maintenance to support a spouse or
child.
AOEs also have a priority system whereby some orders take priority over others. They may operate by percentages, bands or a fixed amount. They might have a protected earnings limit to ensure the employee is left with enough money to live on. The system also needs to adjust any student loan deduction to comply with the protected earnings limit.
The system therefore needs to:
• separate each AOE according to its type (1) and• by reference number (1)• operate a priority system (1)• use bands, percentages or fixed amounts (1)• set aside any protected earnings (1)• identify and calculate attachable earnings for the AOE
deduction (1)• adjust student loans to not exceed protected earnings (1)• correctly apply AOEs to advanced holiday pay periods (1)• store a total value for an AEO and apply a reducing balance
each pay period, ending the deduction when the balance owed is nil (1)
• Store attachment values (1), and• Have a balance outstanding, amount deducted, balance
brought forward and balance carried forward (1)
Earnings for purposes of AOEs
The table below is a guide to which pay is to be used for AOEs. AOEs are a deduction from a specific type of net pay which must be correctly identified. Only some of the earnings shown in the table apply to the
Page 37 of 51
company but the whole is shown for completeness. Each of the items of pay needs to be identified as to whether or not they are to be used for AEOs. This should then lead to the correct net pay figure, described as ‘residue’ in the table below, is used to apply the AOE deduction.
We are also permitted to deduct a £1 administration fee for each order in operation. This could be included as part of the AOE process (2) or as a separate deduction code as defined in ‘Payments and Deductions’ above (1). Note: the admin deduction can be deducted from the net pay after a protected earnings limit has been applied.
The legislation governing:
Defines earnings as: Attachment of Earnings Orders (maintenance, fines and civil debts)
Earnings Arrestments
Deduction from Earnings Orders
Council Tax AEOs
Wages and salary Yes Yes
Pension Yes No
Statutory sick pay Yes Yes
Excludes:
Disability pension Yes Yes
Statutory maternity, paternity and adoption pay
Yes Yes
Sums payable by any public department of the Government of Northern Ireland or of a territory outside the UK
Yes Yes
Armed forces’ pay* Yes Yes
a Tax Credit Yes Yes
Wages payable to a person as a seaman
Yes Yes
Guaranteed minimum pension
Yes No
Defines residue as attachable after the following deductions:
Page 38 of 51
Income tax Yes Yes
Pension, allowances or benefit payable under any enactment relating to social security
Yes Yes
National Insurance contributions
Yes Yes
Superannuation or pension contributions
Yes Yes
Priority of Orders
It isn’t necessary for the system to calculate the priority of AOEs itself, but it does need to be able to operate the AOEs in order of priority. On inputting an AOE to the system, the operator should be able to select the priority of the order e.g. 1, 2 or 3 etc. (1)
Deduction Tables for Council Tax Attachments of Earnings Orders
The deduction tables below are to be used for the purposes of calculating the percentage of net pay to be deducted. The table letter should be selectable on input (1) or be automatically detected for employees on weekly or monthly pay (2)
TABLE ADEDUCTIONS FROM WEEKLY EARNINGS
Net earnings Deduction rate %Not exceeding £55 0Exceeding £55 but not exceeding £100 3Exceeding £100 but not exceeding £135 5Exceeding £135 but not exceeding £165 7Exceeding £165 but not exceeding £260 12Exceeding £260 but not exceeding £370 17Exceeding £370 17 in respect of the first £370 and 50 in
respect of the remainder
TABLE BDEDUCTIONS FROM MONTHLY EARNINGS
Net earnings Deduction rate %Not exceeding £220 0Exceeding £220 but not exceeding £400 3
Page 39 of 51
Exceeding £400 but not exceeding £540 5Exceeding £540 but not exceeding £660 7Exceeding £660 but not exceeding £1,040 12Exceeding £1,040 but not exceeding£1,480
17
Exceeding £1,480 17 in respect of the first £1,480 and 50 inrespect of the remainder
TABLE CDEDUCTIONS BASED ON DAILY EARNINGS
Net earnings Deduction rate %Not exceeding £8 0Exceeding £8 but not exceeding £15 3Exceeding £15 but not exceeding £20 5Exceeding £20 but not exceeding £24 7Exceeding £24 but not exceeding £38 12Exceeding £38 but not exceeding £53 17Exceeding £53 17 in respect of the first £53 and 50 in
respect of the remainder
Child Maintenance Service (formerly CSA) deductions
Another type of order comes from either the Child Maintenance Service or CSA. This has two value on it: an amount to be deducted, called the Normal Deduction Rate (NDR); and a Protected Earnings Rate or Proportion (PER or PEP). Child maintenance orders, are priority orders, this means if there is any shortfall in the deduction in one period, the balance not deducted is carried forward to the next pay period.
Calculation
The system needs to:• calculate the attachable earnings (1) and• deducted the NDR (1)• ensure the net pay does not fall below the PER or PEP when
the NDR is taken (1)• and shortfall in NDR is carried forward to the following pay
period and a record is kept of the shortfall (1)• for advanced holiday pay the system needs to multiply the
NDR and PER by the number of weeks being paid e.g. one week’s pay plus two weeks holiday pay means three weeks deductions need to be calculated (1)
Court Orders - Centralised Attachment of Earnings Payment System (CAPS)
Court orders have a deduction amount and protected earnings value the same as childcare - Normal Deduction Rate (NDR); and a Protected Earnings Rate or Proportion (PER or PEP). However, court orders can also be priority and non-priority. This means:
Page 40 of 51
• Priority orders have a carried forward balance in case of a deduction shortfall, that balance to be added to the next period’s deduction
• Non-priority orders do not carry forward any shortfall
CalculationThe system needs to:
• have input and calculations selectable by priority and non-priority orders (1)
• calculate the attachable earnings (1) and• deducted the NDR (1)• ensure the net pay does not fall below the PER or PEP when
the NDR is taken (1)• and shortfall in NDR for priority orders is carried forward to the
following pay period and a record is kept of the shortfall (1)• for advanced holiday pay the system needs to multiply the
NDR and PER by the number of weeks being paid e.g. one week’s pay plus two weeks holiday pay means three weeks deductions need to be calculated (1)
• store a total value for an AEO and apply a reducing balance each pay period, ending the deduction when the balance owed is nil (1)
Input
An example of an input screen is shown below. Input should feature:
the order reference number (1) a description of the order (1) the date of the order (1) whether or not it is an arrestment type order (1) the total value of the order (1) payment or deduction (2) protected type – none, value or rate (1) protected value (1) or protected rate (1) priority - a number system such as 1,2,3, etc. (1) general ledger code to be assigned to attachments (1) start and end dates (1) balance deducted (1) balance brought forward (1) balance remaining (1)
Page 41 of 51
1:11 Voluntary Deductions
Overview
Page 42 of 51
There is a requirement for voluntary deductions to be taken from employee’s net pay. This is to accommodate the Company’s health scheme, and any other deductions which may be required.
Within the Payments and Deductions Master File in section 1:02, there is the facility to set up as many deduction codes as required.
1:12 Net Pay Calculation
The system need to be able to do a gross pay to net pay calculation. It needs to be able to do this for all employees (global), or a single employee as required. It needs to accurately apply PAYE, National
Page 43 of 51
Insurance, Pensions and other deductions to gross pay, as well as apply voluntary deductions to net pay.
Gross pay is to include all payments to the employee, with each element included in taxable pay, NI’able pay, pensionable pay as defined for each in the Payment and Deduction Master File (1)
PAYE (as detailed in section 1:XX) should be applied to taxable pay (1)
National Insurance (as detailed in section 1:XX) should be applied to pay for National Insurance purposes (1)
Pension (as detailed in section 1:03) should be deducted from pensionable pay (1)
Student Loans (as detailed in section 1:XX) should be applied to pay for National Insurance purposes (1)
Court Orders (as detailed in section 1:XX) should be applied to net pay as defined in that section (1)
Voluntary deductions should be applied to net pay (1) The calculation should update Year To Date (YTD) cumulative
figures for all pay and deduction elements (1) If a global calculation has not been performed, a warning should be
issued if the system is asked to produce payment information, payslips and any other process dependent upon the calculation process, and stop those functions from being performed (1)
1:13 Report Writer
Basic Requirement
There is a requirement for printing and exporting payroll data. This could be lists of employees, net pay reports, deductions, BACS listings, payslips
Page 44 of 51
etc. It would also have to feature positioning data so prints can be made to pre-printed forms or in-house designs. The reports need to be easily accessible from a menu, listed by report name and in categories. It is proposed a single report writer could cover all these requirements. It would have to:
Have create, name, save and edit functions for both the report title and report category (1)
Select whether positional data is required or not (see positional data below) (1)
Selectable font size and type (2) Have selectable page size (default A4) (2) Have a list of selectable data header types. E.g. Payroll Number,
Name, Date of Birth, Gross Pay, PAYE, etc. (1) Display values below each header (1) Selectable number of decimal places for figures (default should be
2) (2) For payroll payments and deduction, both voluntary and statutory,
such as Gross Pay, Pension, PAYE, NI, Net pay etc., have the value selectable by period or year to date (1)
Have an exclusion list, for example, to create a list without anyone who has a leaver date (1)
Use operands for data matching, such as ‘=’ ‘<’ ‘>’ ‘=<’ ‘=>’ (equal to, smaller than, greater than, equal to or smaller than, equal to or greater than). E.g., there may be a need to produce a list of all current employees aged 22 or over, aged 65 or under, with annual earnings of £10,000 or more (2)
Have printing with ‘print to paper’, ‘export to PDF’, and ‘print to view’ – the ‘print to view’ should display the data on screen, and have drag and drop directly into Microsoft products (1)
Be able to display lists of prints in the payroll menu and to sort those lists by category (1)
Templates – Positional Data
The report writer needs to be able to produce printed documents, such as payslips and P45s. Both payslips and P45s have legal requirements to comply with and need to be created by qualified payroll staff. The function should be easy to use by staff that may not have expert computer skills. It should have in addition to the above:
Selectable X and Y (horizontal and vertical) positioning data, using a simple ‘nnn,nnn’ format (1)
Show the data on a positioning grid display (2)
Page 45 of 51
Change font size, type and colour for each data item (1) Be able to create tables and outlines by position and size (1) and, Have selectable line weight, type and colour (2) Be able to import pictures, such as company logos etc. (1)
1:14 Validation Checks
Overview
The system should provide a number of basic checks on the validity of data to prevent common errors. That list should include:
Check taxable pay, tax YTD, and period on P45 pt. 3 and P6s. Also that any previous pay/tax is entered correctly to the payroll. The
Page 46 of 51
system can do a tax calculation on the data entered using the tax year and period provided on the P46/P6 to check if the pay and tax tear to date figures provided/entered are correct (2)
Check pension members are on contracted out of national Insurance and use NI category letters D, E or L. Check other NI letters are not members of the pension scheme (1)
Check cats B & E are female (2) Check recipients of SMP are female (1) Check dates of birth for National Insurance category C – issue a
warning if a birth date is passed before the pay date and the employee is not on category C on that pay date (1)
Check validity of NI numbers, the format should be two letters, six numbers and one letter (1)
Check salary figure to spot input errors e.g. salary 1,000,000 p.a. (1) Check annual hours. Normally for a 37 hour week, annual hours
should be 1929.29 for 52.143 weeks, so a limit of 2,000 hours could prevent error (1)
Check and prevent negative pay (1) Check and report on large net pay values (1) Produce an audit report showing each change made, by whom and
when (1) Issue warnings for tax refunds – a large number of refunds could
indicate an error inputting PAYE bands for example, or an employee’s tax code could be mistyped (1)
1:15 Security and Access
Overview:
A payroll contains sensitive and confidential information. It is also covered by legislation: HMRC, The Pensions Regulator and the Data Protection Act all have legislation covering the storage of information used for payroll purposes. It is essential therefore only authorised personnel have access to the payroll system.
Page 47 of 51
In addition, information affecting an employee’s pay can be changed to drastically alter their pay, or the pay of all employees with dire consequences. It is therefore imperative that certain aspects of the system are only accessible by qualified staff. The system needs to have access limited by type.
Programmer:
A programmer will have access to all aspects of the payroll system, including all the ‘nuts and bolts’ calculations. However, access to the live payroll system will need additional authorisation from the Payroll Manager due to the wide sweeping consequences change may cause. Any changes at this level should be fully tested in a quarantined test environment first before going live.
Manager:
The ‘manager’ level is intended for use by the Payroll Manager. This will have access to all data parameters as well as being able to create new users and set access controls for those users.
Administrator:
This level is intended for those personnel who are qualified to make parameter changes, such as tax bands and percentages, NI bands, pension parameters etc. They will also be able to create, edit and delete pay and deduction codes.
User:
This level is intended for payroll staff only involved in data entry. Their access should be limited to data entry screens.
Unauthorised Access
Attempts to access the system, username and password failures should be reportable. The system should record date, time, and location, type of access/error and I.P. address of the PC used.
Page 48 of 51
1:16 Data Storage
Overview
The system needs to store information for each employee for both statutory and non-statutory payments and deductions. It should reference those to the tax year, pay period and employee. It should store period payments and deductions as well as year to date amounts. Although HMRC recommend keeping records for a minimum of three years plus the current year, the system should keep historical records for an unlimited period.
Data to be stored
Page 49 of 51
Data storage, all priority (1), should consist of:
name and address gross earnings net pay taxable pay PAYE coding and dates of any changes NI category letters and dates of any changes deductions for tax, NICs and student loans employer's NICs for National Insurance purposes for each National Insurance
category letter used for each amount of earnings paid: o the date of payment of each payment of earnings o the gross amount of earningso earnings up to the Lower earnings limit (LEL)o earnings from the LEL to the Primary Threshold (PT)o earnings from the PT to the Upper Accruals Point (UAP)o earnings from the UAP to the Upper Earnings Limit o employee's NICs payableo employer's NICs payable
pension payments: pensionable pay, deductions, percentages applied and dates of change, for employee’s and employer’s pensions
SSP payments: average weekly earnings and for what period; SSP paid, start and end dates of absences, for how many days and the value of each, details of linking periods and the total number of days paid in the current linked qualification period (up to 28 weeks)
SMP, SAP, ASPP payments: dates, including EWC, start and end dates of leave and pay
Employee payments and deductions: gross pay, hours worked, overtime payments and hours, voluntary deductions for each type
Security data: who accessed the system, when and for how long; changes made to data, who made them and when (audit trail); any unauthorised or attempted system access
Page 50 of 51
Page 51 of 51
