Payroll System Specification

of 53
Tyler R Us
Payroll System Specification
A report to the Directors and the project team
Prepared by Michael A Hather, 14th June, 2014.

of 53
Introduction
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.

of 53
Index of Contents
1:01 Employee Pay Master File ........................................................ 4
1:02 Payments and Deductions Master File ........................................ 5
1:03 Pensions............................................................................... 7
1:04 Data Input Screen................................................................ 11
1:05 Statutory Sick Pay................................................................ 12
1:06 Statutory Maternity / Paternity / Adoption Pay .......................... 16
1:07 PAYE.................................................................................. 24
1:08 National Insurance ............................................................... 31
1:09 Student Loans ..................................................................... 38
1:10 Court Orders ....................................................................... 44
1:11 Voluntary Deductions............................................................ 45
1:12 Net Pay Calculation .............................................................. 46
1:13 Report Writer ...................................................................... 47
1:14 Validation Checks................................................................. 49
1:15 Security and Access.............................................................. 50
1:16 Data Storage....................................................................... 52

of 53
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
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)

of 53
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
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.

of 53
 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.
 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.

of 53
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.
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)

of 53
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:
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)

of 53
 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:
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)

of 53
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:
 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.

of 53
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.
 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)

of 53
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:
 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)

of 53
 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
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)

of 53
 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:
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

of 53
Examples:
Employee works
QDs in
a week
Period 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.02
Tuesday, Thursday,
Friday
3 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.
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 2012
2. 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.98
5. £99.98 multiplied by 12 = £11999.76
6. £11999.76 divided by 52 = £230.76461
GL Coding
SSP should be coded to the same departmental GL code as gross pay

of 53
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)
 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)

of 53
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)
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).

of 53
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 Saturday
06/04/14 12/04/14 22/12/13 28/12/13 06/07/13 19/01/14 09/03/14
13/04/14 19/04/14 29/12/13 04/01/14 13/07/13 26/01/14 16/03/14
20/04/14 26/04/14 05/01/13 11/01/14 20/07/13 02/02/14 23/03/14
On entering the EWC into the input screen, they system would then
reference these date tables and perform the correct entitlement
calculation.

of 53
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 QW
8 Dec 2013 to
14 Dec 2013
Friday 18 Oct 2013 13 Dec 2013
In this example the relevant period is 19 October 2013 to 13 December
2013.

of 53
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.

of 53
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)

of 53
 Have input for the start and end dates of the leave (1)
 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)

of 53
SAP input screen:
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.

of 53
1:07 PAYE
Overview
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:

of 53
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:

of 53
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

of 53
Tax coding letters – definitions
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.

of 53
Calculation – freepay (Personal Allowance)
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 500
1 Where the code is in the range 501 to 1000 inclusive:
a. Subtract 500 from the code and use the balance
of the code to obtain a pay adjustment figure from
the table above.
b. Add this pay adjustment figure to the figure given
in the box alongside to obtain the
figure of total pay adjustment to date * 96.16
And an excerpt from the table:
441 84.99
442 85.18
443 85.37
444 85.56
445 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:

of 53
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) –
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

of 53
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
 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

of 53
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
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

of 53
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.

of 53
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
Limit
Nil -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 Point
Nil -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

of 53
apply NI to that period. For advance payments, such as holiday pay, it
needs to treat these as separate weeks for calculation purposes.
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.

of 53
Example (from HMRC): To work out a director’s standard rate NICs:
 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.
 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.

of 53
GL Coding
Employee’s contributions should be coded to a balance sheet account for
National Insurance Contributions. Employer’s contributions should be
coded to a P&L departmental account for Employer’s National Insurance.
The system needs to show correctly all rebates as a credit figure

of 53
1:09 Student Loans
Overview
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
 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)

of 53
1:10 Court Orders
Overview
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)

of 53
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
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 Yes Yes

of 53
as a seaman
Guaranteed minimum
pension
Yes No
Defines residue as attachable after the following deductions:
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 A
DEDUCTIONS FROM WEEKLY EARNINGS
Net earnings Deduction rate %
Not exceeding £55 0
Exceeding £55 but not exceeding £100 3
Exceeding £370 17 in respect of the first £370 and 50 in
respect of the remainder

of 53
TABLE B
DEDUCTIONS FROM MONTHLY EARNINGS
Not exceeding £220 0
Exceeding £660 but not exceeding £1,040 12
Exceeding £1,040 but not exceeding
£1,480
17
Exceeding £1,480 17 in respect of the first £1,480 and 50 in
TABLE C
DEDUCTIONS BASED ON DAILY EARNINGS
Not exceeding £8 0
Exceeding £53 17 in respect of the first £53 and 50 in
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
• 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)

of 53
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:
• 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
Calculation
• 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)

of 53
 start and end dates (1)
 balance deducted (1)
 balance brought forward (1)
 balance remaining (1)

of 53
1:11 Voluntary Deductions
Overview
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.

of 53
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
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)

of 53
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
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

of 53
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)
 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)

of 53
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
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)

of 53
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.
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

of 53
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.

of 53
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
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 earnings
o 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 payable
o 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

of 53
 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

Payroll System Specification

Recommended

More Related Content

What's hot (20)

Similar to Payroll System Specification (20)

Payroll System Specification