CAPITAL CORP. SYDNEY

73 Ocean Street, New South Wales 2000, SYDNEY

Contact Person: Callum S Ansell
E: callum.aus@capital.com
P: (02) 8252 5319

WILD KEY CAPITAL

22 Guild Street, NW8 2UP,
LONDON

Contact Person: Matilda O Dunn
E: matilda.uk@capital.com
P: 070 8652 7276

LECHMERE CAPITAL

Genslerstraße 9, Berlin Schöneberg 10829, BERLIN

Contact Person: Thorsten S Kohl
E: thorsten.bl@capital.com
P: 030 62 91 92

NUQ BACKPAY

NUQ BACKPAY

One of the biggest problems in many payrolls is the way in which backpay is managed.  It is difficult to get the correct amounts calculated by the payroll system, and people often resort to manual calculations.

In nuQ, backpay is a simple operation requiring little effort.  All transactions in the system have a start and end date associated with them, and data is kept for as long as required.  Perhaps the best way to illustrate the facilities is to use a simple example.

NUQ BACKPAY EXAMPLE

Assume that the current pay period is September.  An employee who has been with the employer for a number of years was due to receive a pay increase in July, but was granted an incorrect increase, which now needs to be corrected.  The increase put through changed his rate of pay to K140,000 a month instead of K150,000 a month.

In September, all that is required is to put through a “temporary” rate of pay change to K150,000 with an effective date of 1 July, and an end date of 31 August (because a “permanent” change cannot be made to “history”). At the same time, a “permanent” rate of pay change to K150,000 per month must be input, with an effective date of 1 September. Nothing else is required.

This will cause nuQ to recalculate the employee’s pay for each month from July to the current period (September). That is, a complete recalculation will take place of all earnings and all deductions for July and August, as the change in the rate of pay could affect other calculations in the month following the date of the change as well. The difference (if any) between the original calculations for each item of pay (such as basic pay, tax, pension contribution etc) and the new calculation will be determined and paid to the employee with his normal September pay.

Each such backpay amount will be stored in the system as logically affecting July or August, but physically paid in September.  Thus, if a further backpay calculation is ever required for July and August at some future date, the system will take into account the additional amounts paid/deducted in September.

The September payslip will start with a section headed backpay for the period 1 July to 31 July.  Immediately following that will appear all differences for July calculated as explained, followed by an amount of net pay.

This will be immediately followed by another section headed backpay for the period 1 August to 31 August.  Immediately following that will be all the differences for August, with that net pay.

There will be a final section headed Pay for the period 1 September to 30 September, containing the details of the current month’s pay, with its net pay.  All three net pays will then be totalled and shown as the amount paid into the employee’s bank account (or whatever the method of payment is).

This payslip will be easily understood by the employee, and there will be no argument as to how the amount of the backpay is arrived at.

SECURITY

To guard against unauthorised personnel entering backdated transactions, a facility is available when setting up a user to specify whether or not that user can backdate input transactions.  (See “Security”).  On the user profile, if a tick is entered in the box “Special user?”, that user will be permitted to enter backdated input.  Only responsible (senior) employees should be so designated.