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:

1. Set up organisation

   1. Set up Clients

   2. Set up Companies

   3. Set up Departments

   4. Set up Pay Definitions

   5. Set up Administrators

   6. Set up Workflow Definitions

   7. Set up Report Definitions

   8. Set up Pay Schedules

2. 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 outputs are selected, or ‘connected’ to Busses. These Busses can then be used as the inputs to other Pay Definitions. In this way, the Busses define how Pay Definitions feed 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.

All the outputs which drive a buss are added together. The result can then be used as the input to another Pay Definition.

The Busses for each output are defaulted from the respective Pay Template.

Example

You have Pay Definitions for Salary, Bonus and Expenses. Each of them contributes to Net Pay, but only the first two should be taxed. This is how the busses should be set up:

Output Buss connections

Pay Definition	Net pay buss	Taxable pay buss
Salary	✔	✔
Bonus	✔	✔
Expenses	✔	✖

Now ensure that the Taxable pay buss is used as the input to the statutory Income Tax Pay Definition. Note that the Net pay buss is automatically connected to Payslips and similar report functionality.

Each Buss is Universal, or associated with a country, or for custom use within a Company.

Universal busses

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 Busses

Buss name	Notes
Absence taken	Number of absence days e.g. sickness Pay Definition may generate 1 day which is used by Salary to subtract 1 day of salary
Addition to net pay	Pay that is added to net pay and not taxed e.g. expenses (use with Net pay)
Attachable earnings	Pay used as the basis for earnings orders
Bonussable earnings	Pay that is used as the basis for another Pay Definition to calculate a bonus e.g. 10% of all pay
Commissionable earnings	Pay that is used as the basis for another Pay Definition to calculate commission
Deduction from net pay	e.g. Uniform charge (use with Net pay)
Gross Benefits In Kind (BIK)	The cash equivalent of a non-cash benefit e.g. Medical insurance
.Gross pay	Generally, any pay that will be totalled and shown on a payslip or journal
Gross pay for Income tax purposes	All pay that is subject to income tax e.g. Salary, Bonus, Commission (not used in GB)
Gross pay for OD purposes	Pay used as the basis for Employee On-demand requests
Gross pay for social tax purposes	All pay that is subject to social tax e.g. Salary, Bonus, Commission (not used in GB)
Holidayable earnings	Pay that is used as the basis for holiday pay (take care when selecting Holidayable earnings so as not from a ‘loop’)
.Net pay	Pay that directly adds to an employee’s net pay e.g. expenses
Pensionable earnings	Pay that is used as the basis for pension calculation e.g. Salary.
Arbitrated garnishes	RESERVED for system use - DO NOT USE
Income tax	RESERVED for system use - DO NOT USE
.Pension contributions (worker)	RESERVED for system use - DO NOT USE
.Pension contributions (company)	RESERVED for system use - DO NOT USE
Recoverable	RESERVED for system use - DO NOT USE

Country-specific busses

There are often a group of country-standard gross pay busses used for a country. These and other country-specific busses are listed here.

DE busses:

DE-specific busses

Buss name	Notes
Church wage tax	RESERVED for system use - DO NOT USE
Social security	RESERVED for system use - DO NOT USE
Solidarity surcharge	RESERVED for system use - DO NOT USE

GB busses:

GB-specific busses

Buss name	Notes
Gross pay for NIC purposes	All pay that is subject to National Insurance (NI) e.g. Salary, Bonus, Commission
Gross pay for PAYE purposes	All pay that is subject to income tax e.g. Salary, Bonus, Commission
Qualifying earnings	Pay that is used as the basis for Auto Enrolment (AE) Qualifying Earnings (QE)
Average Weekly Earnings	RESERVED for system use - DO NOT USE
Gross pay for Class 1A NIC purposes	RESERVED for system use - DO NOT USE
NIC.Employee	RESERVED for system use - DO NOT USE
NIC.Employer	RESERVED for system use - DO NOT USE
PAYE.Tax paid	RESERVED for system use - DO NOT USE

US busses:

US-specific busses

Buss name	Notes
FICA Company	RESERVED for system use - DO NOT USE
FICA Employee	RESERVED for system use - DO NOT USE

Custom Use busses

There are 10 further busses that maybe used to connect or sum pay for very complex pay calculations. These are labelled Custom use 0 to Custom use 9

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)
Loan (percent)
% Bonus
Holiday %
Per unit
Salary Overtime
Payment with offset
Payment
Deduction (negative)
Deduction
Net to Gross
Minimum Wage
Message
Holiday		✓
Sickness		✓
Pension contribution
PAYE
NIC
AWE Source
AWE Sink
Termination
CIS
SSP		✓
SMP		✓
SPP		✓
SPBP		✓
AE		✓
SL
CTAEO
Arrestment
AEO
DWP DEA
CSA DEO
GB Liability
GB Car and Fuel

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 ‣ Update 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).