Getting Started¶

Preparation¶

Any payroll system needs organisational data and per-worker data. For the organisational data, once the needed sources are identified, getting started often needs no tooling or skills beyond the ability to create and edit simple .CSV (or similar) spreadsheet files. For the per-worker data, preparation can bring challenges:

All payroll systems need to keep complex state, for example to maintain year-to-date values for tax reporting purposes.
Every worker has individual settings for some pay items (salary, bonus etc.).

Next, to verify the configuration has succeeded also requires some reference data to be available.

Finally, any steps necessary to configure the “go-forward” position must be identified.

paiyroll® Imports support getting started easily in common cases while Migrations support more complex cases with a powerful step-by-step approach. See the sections below for details, and contact your CSR to discuss possible sources of data, and/or tooling assistance.

GB-specific¶

As well as other data, GB getting started requires state as follows:

GB getting started state¶
Pay Template	State needed	Recommended source
PAYE, NIC, SL, SMP, SPP	FPS YTD values for continuity.	Last submitted FPS file.
AWE Source, AWE Sink	Historic values of AWE for benefits such as SSP and SMP.	Current payroll system. Note: if not provided, paiyroll® will generate a value usable after the first post-migration pay run.
AE	Employment start date, enrollment status, and enrol date, last opt-in or opt-out date (as applicible) are needed to manage current and future AE obligations.	HR and pension systems.

Verification that getting started was successful using reports:

GB getting started verification¶
Report Template	Reference data
FPS	Compare last submitted FPS with paiyroll® generated file.
AE	Establish what, if any, manual corrections were required for the last submitted file. Compare last submitted file with paiyroll® generated file.

In a typical scenario:

You have all the organisational data needed.
- The Pay Definitions (including schemes) are designed to fit your Company.
You have the last submitted FPS file.
Your CSR can convert the FPS file into a partially complete workers.csv.
You can incorporate the employment start date, and other needed state extracted from your HR and pension systems to complete the workers.csv.
You create a set of pay items to replicate each workers current remuneration set up in payitems.csv.

Note how the FPS file, plus files from your HR and pension systems, are sufficient to provide the data (including state) for migration as well as for verification, before any final go-forward changes are applied (e.g. SL and debt-order set up).

Contact your CSR if the FPS file is not available.

Imports¶

Imports provide an easy to get started, typically using a one-click approach to quickly configure paiyroll® to support new workers using existing data files. See Importers for the various supported file types.

See Migrations for more complex situations which are tailored, step-by-step, to a given standard source of data.

Migrations¶

Migration is the process of configuring paiyroll® to support new workers, typically in bulk. Migration is supported at any point in time, even part way through a tax-year. The aim of the migration is to configure the system so that on a given pay date, paiyroll® can smoothly take over the delivery of payroll. Generally the process entails:

Identifying the needed data, and its sources.
Extracting, transforming and loading the data.
Verification the results are as desired.

It is also necessary to design how to represent the way in which the company remunerates its workers. In practice, some iteration may be required to ensure the final go-forward position is satisfactory. (See also Imports for a simplified approach to getting started).

A migration can be broken down into the following steps:

Set up organisation
Set up workers
1. Set up Workers
2. Set up Pay Items

These are discussed in the following sections.

Set up Clients¶

A Client represents an administrative domain in paiyroll®, and associated with a Master Administrator. The Master Administrator will typically have detailed knowledge of the operation of the system, has expansive access to and control of the system, including the ability to create other Administrators with more constrained scope.

This step is expected to be performed manually by a paiyroll® Customer Service Representative (CSR).

Set up Companies¶

A Company represents the legal entity employing workers and known to the tax authority within a given country.

This step is expected to be performed manually by the Master Administrator, using the Company ‣ Upload facility.

Set up Departments¶

This step is expected to be performed manually Master Administrator, using the Department ‣ Upload facility.

It will normally be easier to first add the departments without a hierarchy, and then add hierarchy as needed. Otherwise, it will be necessary to add the departments in a top-down fashion.

If the company has no Departments, add one call “All”.
If the company has many Departments, use Department ‣ Upload facility.

Note that department managers must be configured later, after setting up workers.

Set up Pay Definitions¶

This step is expected to be performed manually Master Administrator, using the Pay Definition ‣ Upload facility.

The design of a set of Pay Definitions that accurately replicates an existing set up is the main technical challenge of the migration. The basis of the design is a sound understanding of the available Pay Templates (including the logic of the Pay Ops which underlie them) and how Pay Definitions can be constructed from them. Briefly,

Pay Templates are either Universal or associated with a country. The Universal templates are based on PayOps which typically contain very simple logic (e.g. constant, addition, multiplication by a percentage, generic annual salary, percentage-based pension and so on). The country specific templates are based on PayOps which typically implement tax and social security logic (i.e. statue).
Pay Definitions attach a Pay Template to a Company, and allow it to be customised by setting:
- The name.
- The description, source and reuse policy of the inputs.
  - The names of the inputs can also be changed in some cases, but this is not always possible, and not recommended.
- The Busses to which the outputs are connected.

In practice previously developed sets of Pay Definitions may provide an excellent starting point - especially when the source system is similar - and an iterative approach to the design is encouraged by the tooling described below.

Starting points¶

The effort of designing Pay Definitions can be reduced in by starting with pre-existing definitions based on the country or the source where possible.

Using Busses¶

Pay Definition functionality is exposed via outputs which are selected, or ‘connected’ to Busses. The Busses define how Pay Definitions connect to each other and - in conjunction with statutory Pay Templates - provide for a legally compliant system.

Most Pay Definitions have a single output, but some have multiple outputs. For example, a Pension may calculate a company contribution value as well as a worker deduction value. The Busses for each output are defaulted from the respective Pay Template.

Each Buss is Universal, or associated with a country.

Universal busses are provided for convenience and are very useful to sum values to be used for the relevant pay e.g. pension or bonus. These should be connected to any Pay Definition that will contribute to their values.

Universal Buss	Notes
.Gross pay	.Gross pay and .Net pay are the primary Universal busses, representing the gross pay before taxes and the net pay after taxes. Most Pay Definitions connect to .Gross pay and .Net pay.
.Net pay
Gross pay for OD purposes	Used for on-demand pay.
Gross Benefits In Kind
Pensionable earnings
Bonussable earnings
Commissionable earnings
Attachable earnings
Holidayable earnings	Take care when selecting Holidayable earnings so as not from a ‘loop’.

Country-specific busses¶

There are often a group of country-standard gross pay busses used for a country.

GB-specific Buss	Notes
Gross pay for PAYE purposes	The standard gross pay busses used for GB: most payments will connect all three.
Gross pay for NIC purposes
Qualifying earnings
PAYE.Tax paid
NIC.Employee
NIC.Employer
Average Weekly Earnings	Automatically driven, never used

Payments¶

The Payment Pay Template drives .Gross pay, .Net pay and the country-standard gross pay busses. These are sometimes referred to as before tax.

Examples are bonus, commission.

Deductions¶

The Deduction Pay Template is set up to make net pay deductions. It drives two busses by default:

.Net pay
Deduction from net pay

These are sometimes referred to as after tax.

The Deductions (negative) Pay Template works the same way, but using a negative input.

Examples of after tax deductions are Pension payments (GB relief at source), ent payments.

Expenses¶

Certain types of payments don’t fall into the default category. On example is expenses (reimbursements) which is also an after tax. These can easily be created by deriving a Pay Definition from the Payment Pay Template and modifying it to drive the following busses:

.Net pay
Addition to net pay

Before tax Pension deduction¶

Pension contributions are taken before tax is calculated (GB Net Pay arrangement). Such a Pension Pay template will drive:

PAYE for tax purposes
.Net pay
Pension contribution

Salary Sacrifice¶

Certain benefits, for example pensions may be eligible for salary sacrifice. This is where an an employee agrees to a reduction in earnings in return for a non-cash benefit. To set up Pay Items in this way, it is necessary for the given Pay Defintion negative outputs to drive all the busses in use:

.Net pay
Gross Pay for PAYE purposes
Gross Pay for NIC purposes
Pension contributions (worker)
Attachable earnings

In this way the total value of gross, net pay as well as attachable eaernings will be reduced by the negative value of the benefit.

More information

Pay Definitions which need scheme Pay Definitions or Workflow Definitions¶

Some Pay Definitions need supporting scheme Pay Definitions or Workflow Definitions to be created first. These are as follows:

Pay Templates and dependencies¶
Name	Needs Workflow Definition	Needs Scheme
Holiday scheme	✓
OnDemand scheme
OnDemand pay		✓
Pension scheme
Sickness scheme	✓
Timesheet scheme	✓
Daily piece pay		✓
Weekly piece pay		✓
Hourly pay		✓
Daily pay		✓
Weekly pay		✓
Salary scheme
Salary		✓
Loan (amount)
% Bonus
Holiday %
Per unit
Payment with offset
Payment
Deduction (negative)
Deduction
Holiday		✓
Pension contribution
PAYE
NIC
SL
AWE Source
AWE Sink
Termination
SSP		✓
SMP		✓
SPP		✓
SPBP		✓
AE
CTAEO
Arrestment
AEO
DWP DEA
CSA DEO
GB Liability

See the individual Pay Template descriptions for details.

Pay Definitions for multiple Pay Schedules¶

Many Pay Items need to store state to operate correctly from Pay Run to Pay Run, or through a tax year. To ensure that state is not incorrectly shared, the same Pay Definition cannot (in most cases) be used for more than one Pay Schedule or frquency.

Pay Definitions which are mandatory for a given country are the exception to this rule.

It is recommened that Pay Definitions are named to avoid this, for example using “Salary m1” rather than just “Salary” for a monthly salary.

Set up Administrators¶

This step is expected to be performed manually Master Administrator, using the Administrator ‣ Upload facility.

Administrators who are also workers¶

Where one individual has both an administrative role and is also a worker, paiyroll® requires them to have separate identities (i.e. “logins”) to ensure the separation of private personal data from potentially-shared administrative data as well as separate user interfaces for the two roles.

Set up Workflow Definitions¶

This step is expected to be performed manually Master Administrator, using the Workflow Definition ‣ Upload facility.

Set up Report Definitions¶

This step is expected to be performed manually Master Administrator, using the Report Definition ‣ Upload facility.

Set up Pay Schedules¶

This step is expected to be performed manually Master Administrator, using the Pay Schedule ‣ Upload facility.

Set up Workers¶

This step is expected to be performed Master Administrator using the Employee ‣ Upload facility.

Department managers¶

The managers of departments can now be set up, using the Department ‣ Upload facility with the manager set as needed.

Use Test workers for convenience¶

Dummy workers can be created with the Test flag set. Employee ‣ Update ‣ Manage Pay Items alows Pay Items from such test workers to be copied to the current worker. This can be used to used to simplify the set up of individual new workers.

Set up Pay Items¶

This step is expected to be performed Master Administrator using the Pay Item ‣ Upload facility.

Typically, this step is performed iteratively with the design of the Pay Definitions and the execution of Pay Runs until the fidelity of the migration at a point in time is established.

Managers need Workflow access.¶

Some Pay Definitions, such as those for timesheets and absence approvals, need supporting Workflow Definitions for approvals.

Managers responsible for Departments of workers with Pay Items based on these Pay Definitions must also be given similar Pay Items to allow access for approval purposes. This also ensures that they can, when needed, act on behalf of the worker (e.g. to file a sickness claim for an hospitalised worker).

Verification¶

To verify the migration has succeeded, use the reports and reference data identified during Preparation.

Go-forward changes¶

Any steps necessary to configure the “go-forward” position identified during Preparation must be taken (e.g. pending salary changes).