0% found this document useful (0 votes)
219 views44 pages

Real Time Information User Guide

This document provides guidance on implementing real time information (RTI) reporting in the UK. It discusses new business processes and payroll configurations to support RTI reporting to HMRC including employer payment summaries and employer alignment submissions. Key aspects covered include activating RTI reporting functionality, defining wage types and processing classes, using the GBRTI payroll function to derive RTI fields, handling multiple employment scenarios, and managing full payment submissions and communication with HMRC.

Uploaded by

Dinkan Tales
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
219 views44 pages

Real Time Information User Guide

This document provides guidance on implementing real time information (RTI) reporting in the UK. It discusses new business processes and payroll configurations to support RTI reporting to HMRC including employer payment summaries and employer alignment submissions. Key aspects covered include activating RTI reporting functionality, defining wage types and processing classes, using the GBRTI payroll function to derive RTI fields, handling multiple employment scenarios, and managing full payment submissions and communication with HMRC.

Uploaded by

Dinkan Tales
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Real Time Information

User Guide
Table of Contents
Real Time Information ............................................................................................................................. 5
RTI reporting - Interim Solution ............................................................................................................... 5
RTI reporting in detail .............................................................................................................................. 6
New Business Practices to support the FPS submissions .......................................................................... 8
Employer Payment Summary................................................................................................................... 8
Employer Alignment Submissions ............................................................................................................ 8
Activating the solution............................................................................................................................. 9
1. Feature: GBCHG ............................................................................................................................... 9
2. Rule G048 ........................................................................................................................................ 9
Features ................................................................................................................................................ 10
GBIT9 ................................................................................................................................................ 10
GBPEN ............................................................................................................................................... 10
GP46E................................................................................................................................................ 11
GBIEI ................................................................................................................................................. 11
Processing Class .................................................................................................................................... 13
48 ...................................................................................................................................................... 13
49 ...................................................................................................................................................... 13
Wagetypes ............................................................................................................................................ 14
A080 .................................................................................................................................................. 14
A081 .................................................................................................................................................. 14
A082 .................................................................................................................................................. 14
LOP.................................................................................................................................................... 14
NHWK ............................................................................................................................................... 14
PYNI .................................................................................................................................................. 14
UNPA................................................................................................................................................. 14
171 - Net Additions ............................................................................................................................ 15
A71 - Net Additions ........................................................................................................................... 15
Z71 - Net Additions ............................................................................................................................ 15
172 – Ben Payroll ............................................................................................................................... 15
A72 - Net Additions ........................................................................................................................... 15
Z72 - Net Additions ............................................................................................................................ 15

2|P ag e
175 – RTI NI only................................................................................................................................ 15
A75 - Net Additions ........................................................................................................................... 15
Z76 - Net Additions ............................................................................................................................ 15
176 - EE Net pension deduction ......................................................................................................... 16
A76 - Net Additions ........................................................................................................................... 16
Z76 - Net Additions ............................................................................................................................ 16
178 – Pre tax deductions ................................................................................................................... 16
A78 - Net Additions ........................................................................................................................... 16
Z78 - Net Additions ............................................................................................................................ 16
PCRs ...................................................................................................................................................... 17
G048 ................................................................................................................................................. 17
GG41 ................................................................................................................................................. 17
Payroll Function: GBRTI ......................................................................................................................... 18
GBRTI (parameter 1) .............................................................................................................................. 18
GBRTI (parameter 2) .............................................................................................................................. 20
Deriving fields for RTI ............................................................................................................................ 24
40A-Irr Pymt Ind ................................................................................................................................ 24
49-NI aggregation .............................................................................................................................. 25
59-RTI Net Pay ................................................................................................................................... 25
61- This Period Pension Contributions – Pre-tax pensions .................................................................. 25
RTI indicator ...................................................................................................................................... 25
XML ID/Global ID ............................................................................................................................... 25
Deriving fields for Multiple Employment................................................................................................ 26
Non – Primary ................................................................................................................................... 26
Primary.............................................................................................................................................. 26
BADI in payroll function GBRTI (parameter 2) ........................................................................................ 27
Tax Calculation after RTI ........................................................................................................................ 27
The new IT0065 ..................................................................................................................................... 28
The new IT0088 ..................................................................................................................................... 30
Pre DME Program .................................................................................................................................. 32
Full Payment Submission ....................................................................................................................... 34
Communication Channels ...................................................................................................................... 36

3|P ag e
ZIP ......................................................................................................................................................... 36
Employer Payment Submission.............................................................................................................. 37
Communication Channels ...................................................................................................................... 38
ZIP ......................................................................................................................................................... 39
Works Number ...................................................................................................................................... 39
P45 Report ............................................................................................................................................ 40
Display previous submission data .......................................................................................................... 41
Earlier Year Update ............................................................................................................................... 41
Reconciliation report ............................................................................................................................. 43
Transaction Codes for various reports ................................................................................................... 44

4|P ag e
Real Time Information
Real Time Information (RTI) is a government initiative designed to improve the operation of Pay As You
Earn (PAYE). It will make the PAYE system easier for employers and HM Revenue & Customs (HMRC) to
operate, and employees will receive information more quickly. It will also help support the introduction
of Universal Credits which is another government initiative that is due to go-live in October 2013.

The fundamentals of PAYE are unchanged, for example, use of codes, employers deducting tax and
National Insurance. What RTI does change is how and when employers and pension providers report
information to HMRC.

All employers will be required to submit their RTI data to HMRC every time they make a payment to an
employee/pensioner. So, employers who operate a weekly payroll will be required to submit the data on
a weekly basis at the same time as they their send the file to BACS to credit the employees’ bank
accounts.

HMRC’s strategic solution is to enhance the BACS payment process which is used by almost all
employers to incorporate the employee legislative data into one file and use BACS as the
communication channel but as an interim measure, current communication channels can be used and at
SAP, we have decided to continue to use Internet Submissions as our channel of communication.

RTI reporting - Interim Solution


The Interim solution for RTI reporting is:

1. Employers send file to BACS via their BASS (BACS Accredited Software Supplier) containing the
payment information and a generated RTI reference for each employee (see Full Payment
Submission for the detail on the RTI reference)

2. An RTI file containing a hash per employee will be sent to HMRC via the government gateway
(see Full Payment Submission for the detail on generating the hash)

3. The Gov Gate will send a success message that the file has been validated and accepted and
update the HMRC systems.

4. BACS will credit the employees bank accounts and create a hash with the same data as the
employer and send this to HMRC

5. HMRC will use the hash for matching the payment and RTI data per employee.

5|P ag e
RTI reporting in detail
All employers will be required to send their Real time Information data to HMRC every time they make a
payment to an employee/pensioner in a Full Payment submission (FPS) but prior to the first RTI FPS
submission, it will be necessary for all employers to synchronize their employee data with HMRC in a
data alignment Submission (EAS).

The National Insurance Number (NINo) will become the primary identifier for all employees and where
one does not exist, it will be possible to request a missing NINo or validate an existing NINo by
submitting the NVR file.

If an employer needs to make amendments to the employer data, for example he needs to adjust the
amount of Tax, NI compensation etc., he can then submit an Employer payment Submission (EPS).

There will be 5 different types of submissions to be sent to HMRC


File Type

FPS Full Payment Submission The main RTI submission type giving a breakdown
of the PAYE calculation for each
employee/pensioner on each pay day

EPS Employer Payment A monthly opportunity for an employer to adjust


Submission the amount of Tax, NI etc. due, to take account of
changes applied at an employer level (NI
Compensation etc.)

EAS Employer Alignment A means of sending details of active employments


Submission to HMRC so that HMRC and Employer data can be
aligned

NVR NINO Verification Service An opportunity to validate NI No for employees

EYU Earlier Year Update An opportunity to correct the values which were
incorrectly submitted in the previous tax year

6|P ag e
NVR, FPS and EPS use the same schema but each has a different message ‘class’ at the Government
Gateway to identify the type of submission. Only one of these file types can be included in a single
submission. They must be submitted via the Government Gateway.

NVR is a request for NINO information and must be sent to the Government Gateway. A successful
NINO Verification Request will generate a generic a ‘success response’ through the Government
Gateway. This will NOT include any NINO information relating to the request.

EAS has a separate xml schema with its own message ’class’ at the Gateway.

The BACS file must also be amended to incorporate the generated RTI reference and included in field 7
of the standard 18 BACS file format.

On receipt of the BACS file, Vocalink will also generate a hash of the same items of data as the employer
and will forward the hash to HMRC who will then have all the information they require to match the
data for a single employee.

Certain data items are only required to be reported for new starts. E.g. Address, Date of Start…

Employers still have to send P45 to Employee and that a new starts will still bring a P45.

Also all new starts have to be reported with a starter declaration based on the P46 statements even if
they provide a P45.

All new starts will be notified to HMRC with form type P46 and depending on the employee’s
circumstances, (example: Statement A - This is my first job since 6 April will attract the current
emergency tax code on a cumulative basis.) unless the starter produces a document from his previous
employer showing the tax code that was used in his previous employment.

In these cases, the previous tax code should be reported to HMRC and used for calculating the tax
liability. Similarly, providing the previous tax code had been operated on a cumulative basis, the
previous earnings and tax should be taken in account when calculating the tax although it is not required
to be reported to HMRC on the RTI file.

7|P ag e
New Business Practices to support the FPS submissions
There will be a requirement for all employers to review their business practices and in preparation of
HMRC’s strategic solution of sending RTI data in the same file as the BACS data, it might be prudent to
consider this requirement when introducing RTI.

1. All payments where possible should be made using BACS as this will enable HMRC to reconcile
the payment made to the employee with the reported values from the FPS report.

2. Where an employee does not provide bank details, some employers hold any payments due as
employers are not supposed to hold on to monies due to employees, Where an employee has
no infotype 0009 maintained, the record will be rejected in the payroll

3. The Pre-DME program MUST be processed prior to the RTI submission being generated as this
generates the RTI random value

4. RTI random value will be stored in the payroll results in table RTI by the Pre-DME program and is
required by the RTI program to create the hash.

5. The new RTI report RPCFPSG0 handles the RTI submission process, but does no complex
processing

Employer Payment Summary


Once a month, employers are required to align the data reported on the FPS files with the amounts paid
over to HMRC by sending to HMRC an Employer Payment Summary file (EPS). The adjustments made to
your PAYE remittance in respect of items such as the reimbursement of Statutory absence payments
need to be reported to enable HMRC to reconcile the amounts returned on your FPS report with the
amounts paid over to the Collector of Taxes.

Employer Alignment Submissions


Prior to the first submission, all employers will be required to align their data with HMRC as per the
example xml below. The employer can use this submission at any time during the year if, for any reason,
he wishes to align his data with HMRC, for example after an acquisition.

8|P ag e
Activating the solution

1. Feature: GBCHG

Node 11 of GBCHG feature will return the go-live date of the RTI solution. RTI must be activated for the
whole of the tax reference.

Points to remember

By default the feature will be delivered with the return value as 31.12.9999 for node 11.

The go-live date must always be the start date of the payroll period for each of the payroll areas
within the tax reference.

This feature allows for activation at the payroll area level. Therefore caution must be exercised in
ensuring that all the payroll areas within in a particular tax reference are activated with the RTI
Go-Live date individually.

Note:
Transfer of employees from Tax reference A where RTI is active to another tax reference where RTI is
inactive is not supported. The pernr will be rejected in payroll with the Error message stating “Transfer
to non-RTI tax reference, Hire afresh with different pernr to process without errors”.

2. Rule G048
Rule G048 has been delivered and needs to be uncommented as soon as RTI is activated. The details of
the same can be found in the PCRs section of this document.

9|P ag e
Features

GBIT9
This feature is used to configure the letter that is used for Payment Method BACS. In standard the
payment method BACS is represented by “E”. However this is customizable, the return value of this
feature will determine the letter corresponding to the payment method BACS.

The purpose of this is to ensure that RTI indicator is only filled for those employees with payment BACS.

Configuration of the payment method is at the payroll area level only.

GBPEN
This feature is used to configure pensioners. PME02 is the structure for decision making. This is used by
the payroll function to set the Number of Hours worked for Pensioners as ‘Other’.

10 | P a g e
GP46E

This is an existing feature, and is used to configure which employees have the EPM6 indicator set.

The decision can be made only the payroll area level.

GBIEI

This feature is used to configure which employees have an Irregular payment pattern.
Examples:

Those employees who are on a term-time contract and are not paid for every period in the tax year are
employees with Irregular payment pattern.

Staff with a regular Employee Group who take extended period of unpaid leave or on long term sick
without payment should also be returned as ‘Irregular’ during this period.The feature uses the following
fields as decision parameters – Structure PME02

11 | P a g e
The return value is used to set the Irregular payment pattern indicator in the RTI file. In the following
snapshot, all the employees who belong to the Employee Subgroup GO are all irregularly paid.

12 | P a g e
Processing Class

48

This processing class has been introduced to distribute pension contributions. Following are the various
specifications available.

0 Pass on unchanged

2 Pension contributions not under net pay arrangements

Those pension contribution wagetypes to be classified not under net pay arrangements are to have the
specification set to 2.

49

This processing class has been introduced to configure the trivial commutation payment. Following are
the various specifications available. Based on the type of the commutation type, one of the following
specifications needs to be assigned.

A - Trivial commutation lump sum

B – Small pot lump sum payment from personal pension scheme

C – Small pot lump sum payment from occupational pension scheme

Wagetype that holds the trivial commutation payment should have the processing class 49 configured
with the corresponding specification that defines the type.
GBRTI payroll function picks these wagetypes and reports the amount and type in the fields, trivial
commutation payment and trivial commutation payment type respectively.

13 | P a g e
Wagetypes

A080

This wagetype is to be used as a model wagetype for Expenses that are paid through the payroll that are
not subject to tax or national insurance.

This wagetype flows into /105, /113, /171

A081

This wagetype is to be used as a model wagetype for Expense that are paid through the payroll and are
subject to National Insurance but NOT to Tax.

This wagetype flows into /105, /131, /133, /175

A082
This wagetype is to be used as a model wagetype for Benefits that are taxed through the payroll.

This wagetype flows into /121, /172.

/LOP
Wagetype /LOP has cumulation class 71 set from 01.04.2012 onwards for the purpose of RTI

NHWK

This wagetype is used to override the value of Number of Hours worked determined by the payroll
function GBRTI.

RTI file requires the number of hours worked by the employee to be reported. By default the value if
read from IT0007-WOSTD. However if the value thus read from IT0007 is not the desired one to be
reported, then this wagetype could be used to override the same.

Points to remember
This wagetype can be entered via either IT0014 or IT0015

PYNI
This wagetype is used to indicate that a payment is made to a non individual. This wagetype can be
entered via IT0014 or IT0015. If this wagetype is present in RT, then the indicator is set in RTI table by
GBRTI payroll function.

UNPA
This wagetype is used to indicate an unpaid absence for more than one period. This wagetype is a flag
similar to PYNI and can be maintained in IT0014 or IT0015. This wagetype should be maintained only
when the unpaid absence spans for more than one period and from second period of absence onwards.

14 | P a g e
/171 - Net Additions

This wagetype is a cumulation of all payments which are not subject to Tax and NICs. All such payment
wagetypes should have cumulation class 71 set.

/A71 - Net Additions


This is the outflow wagetype for /171. This is generated in the ”for period” whenever there is a retro
across tax year. This is generated in the payroll function GBRTI called with parameter 1 in the subschema
GRT0.

/Z71 - Net Additions


This is the inflow wagetype for /171. This is generated in the ”for period” whenever there is a retro
across tax year. This is generated in the payroll function GBRTI called with parameter 1 in the subschema
GRT0. This is in turn added to the DT in the “for period”. In the “in period” the rule GG41 processes the
DT, and adds this wagetype (/Z71) to the RT of the “in period”.

Then GBRTI called with the parameter 2 in the subschema GEND adds it to Net additions field of table
RTI.

/172 – Ben Payroll

This wagetype is a cumulation of all benefits which are taxed via payroll in a particular pay period. All
such benefit wagtypes should have the cumulation class 72 set.
This is the outflow wagetype for /171. This is generated in the ”for period” whenever there is a retro
across tax year. This is generated in the payroll function GBRTI called with parameter 1 in the subschema
GRT0.

/A72 - Net Additions


Generated in the same manner as that of /A71 described above.

/Z72 - Net Additions


Generated in the same manner as that of /Z71 described above.

/175 – RTI NI only

This wagetype is a cumulation of all benefits which are subject to class 1 NIC but are not subject to tax.
All such benefit wagetypes should have the cumulation class 75 set.

/A75 - Net Additions


Generated in the same manner as that of /A71 described above.

/Z76 - Net Additions


Generated in the same manner as that of /Z71 described above.

15 | P a g e
/176 - EE Net pension deduction

This wagetype unlike the other cumulation wagetypes is generated by the rule G048. Pension
contributions which are not paid under net pay arrangements are added to this wagetype. These
pension contribution wagetypes will have processing class 48 and specification 2 set for them

/A76 - Net Additions


Generated in the same manner as that of /A71 described above.

/Z76 - Net Additions


Generated in the same manner as that of /Z71 described above.

/178 – Pre tax deductions


A new cumulation class 78 has been delivered which accumulates are pre-tax deductions, The value of
this wagetype irrespective of whether it is positive or negative is added to Net deductions and added to
RTI NI only(/175) if it is negative within GBRTI payroll function.

/A78 - Net Additions


Generated in the same manner as that of /A71 described above.

/Z78 - Net Additions


Generated in the same manner as that of /Z71 described above.

16 | P a g e
PCRs

G048

This rule is used to distribute the pension contributions. Those contributions which have processing class
48 specification 2 will be added to /176.

The snapshots below show the position of this rule in the subschema GNT0 and GRT0.

GG41
This rule processes DT and adds the following wagetypes to RT.

/Z71

/Z72

/Z75

/Z76

/Z78

/Z10

17 | P a g e
Payroll Function: GBRTI

GBRTI (parameter 1)
This is called from within the sub-schema GRT0. This is used to generate the following sets of wagetypes
in the “for period” in case of retro across tax year. The /A wagetypes are formed in the “for-period” in
the IT and /Z wagetypes are formed in the DT in the “for period”.

The wagetypes are

/Z71, /A71

/Z72, /A72

/Z75, /A75

/Z76, /A76

/Z78, /A78

/Z10, /A10

18 | P a g e
19 | P a g e
GBRTI (parameter 2)
The payroll function GBRTI Populates two new cluster tables, RTI and RTINI with structures PC2N5 and
PC2N6 respectively. Most of the data required for the Full Payment Submission are filled in this payroll
function. The processing of this payroll function happens only during the ‘in-periods’ and not in ‘for
periods’

The snap shot below shows the position of the GBRTI function in the schema. It has been placed in the
very end of the schema after all the processing has been completed but before the export function.

20 | P a g e
The GB payroll cluster has been significantly extended to hold data that could be derived.

RTI (table) 592 character

RTINI (table) 195 characters (Per NI Category)

To reduce impact on the database even further the new tables will not be filled during retro.
The new tables will only exist during the “original” period (i.e. the IN period).

The payroll function uses common algorithms one to derive all the “This Period” values (of
Tax, NI, etc) and the other to derive all the “Year to date” values (of Tax, NI, etc) and they
are as follows.

All this period values are derived as CRT – OCRT. Values of OCRT are nothing but the CRT
values of the previous original results. Consider the example below.

21 | P a g e
Payroll Runs

01 in 01

02 in 02

01 in 03

02 in 03

03 in 03

In the example above to derive the “This period values” of period 03, the algorithm used is
CRT (03 in 03) – OCRT (CRT of 02 in 02)

To derive the Year To Date values of period 03, the algorithm used is CRT (03 in 03) – PCRT,
where PCRT is the last CRT of the previous employment spell in case of re-hires. All the Year
to Date figures are current employment values.
In case of normal employees, going by the above algorithm the values of CRT are always
taken as PCRT will always be 0 as they have not been rehired.

In SAP system for a re-hire, the CRT continues to cumulate even if there is a break of
employment in case of re-hires within the same tax year. It is for this reason that the CRT of
the last period of previous employment spells needs to be negated from the current CRT
values to derive the Year to Date values in the current employment. Consider the following
example.

Employment Spell 1: April 2012 – July 2012

Employment Spell 2: Jan 2013 – Feb 2013

To derive the Year to Date values for February 2013 i.e. period 11 2012, the algorithm used
is CRT (11 in 11) – PCRT (CRT of 04 in 04)

Following are the fields filled by the payroll function and the source of data for each of these
fields. The field numbers refer to the item numbers on the Initial guidance document provided
by HMRC.

Some of the following fields have been highlighted and a detailed explanation follows as to
how these fields are derived.
Fields of Table RTI
New Start: Field 24 Hire Dt (IT0000-BEGDA)
Field 24A P46 Class (IT0065-P46CLS)
Field 27 SL Ind (Table COURT)
Expat: Field 28, 29, 30 ExPat P46 (IT0065-P46CLS)

22 | P a g e
Field 23 EPM6 Ind (GP46E feature)
Pensioner: Field 33 Pen Brvd Ind (IT0065-PENWIDI)
Field 34 Annual Pens Amt (IT0065-PENAMT)
Casual: Field 40A Irr Pymt Ind (Feature GBIEI)
Leaver: Field 41 Leaving Dt (IT0000-ENDDA)
Field 51 Late pymt Ind (derived in GBRTI)
NI: Field 48 No. of earn. per (NIPAY)
Field 49 NI Aggregation (NIPAY)
Hours: Field 54 No. Hrs wkd (IT0007-WOSTD)
Amounts: Field 41A Taxable Pay YTD (CRT – PCRT*: /121)
Field 41B Tax YTD (CRT – PCRT: /501)
Field 41C SL YTD (CRT – PCRT: /CSL)
Field 58 Taxable Pay TP(CRT – OCRT**: /121)
Field 58A Net Additions (CRT – OCRT: /171)
Field 58B Net dedns/ben (CRT – OCRT: /110)
Field 59 RTI Net pay
Field 60 All Payrolled Ben(CRT – OCRT: /172)
Field 61 This Period Pension Conts.(No Tax)(CRT –
OCRT: /P20 and /P21)
Field 62 Ben NI only(CRT – OCRT: /175)
Field 65 This Period Pension Conts. (Other)(CRT – OCRT:
/176)
Field 67 SL TP (CRT – OCRT: /CSL)
Field 68 Tax TP (CRT – OCRT: /501)
Field 69 SSP YTD (CRT – PCRT: SSPO + SSPP)
Field 70 SMP YTD (CRT – PCRT: SMPR + SMPN)
Field 71 OSPP YTD (CRT – PCRT: SPPR + SPRN)
Field 72 SAP YTD (CRT – PCRT: SAPR + SAPN)
Field 73 ASPP YTD (CRT – PCRT: STPR + STPN)

Field 84A Dir’s NI calc method (derived based on the NI


flag on It0069)

Field 84B Director’s Appointment Tax Wk/Mth (TBD)

The following snapshot shows the RTI table (Structure PC2N5)

23 | P a g e
In case of early payment run, or incase multiple payments happen in a particular period, then
there will be multiple RTI submissions. In all those scenarios, the RTI table will have multiple
rows and if there are multiple RTI submissions corresponding to these payments, then each of
those entries will have different Global IDs (Please see the section below – Deriving fields of RTI
for details on Global ID).

Fields of Table RTINI

NI: Field 79 NI Category (CNIC – LCNIC)


Field 79B NI’able Gross (CNIC – LCNIC)
Field 82 YTD Amount To LEL (CNIC – PCNIC)
Field 82A YTD Amount LEL – ERT (CNIC – PCNIC)
Field 83 YTD Amount ERT – UAP (CNIC – PCNIC)
Field 84 YTD Amount above UAP (CNIC – PCNIC)
Field 86A This Period ER NICs (CNIC – LCNIC)
Field 86Aa YTD ER NICs (CNIC – PCNIC)
Field 86B This Period EE NICs (CNIC – LCNIC)
Field 86Ba YTD EE NICs (CNIC – PCNIC)

Deriving fields for RTI

40A-Irr Pymt Ind


This flag is set in table RTI based on the return value of the feature GBIEI. However there are other
scenarios when the employee needs to be flagged as is irregular such as when the employee goes on an
unpaid absence.

24 | P a g e
This flag is automatically set in the payroll in the payroll function GBRTI. The logic used for this flag is a
check on presence of wagetypes /101 – Total Gross and /560 – Net pay.

First a check is made on the return value of the feature GBIEI, if employee is not configured as Irregular
via the feature then following check is made.

If both /560 and /101 are not found in the RT, then the employee is classified as irregularly earning
employee and the indicator is set.

49-NI aggregation
This flag is set in case the employee was a multiple at any time in the tax year. The flag is set by the FPS
report.

59-RTI Net Pay


This field is derived in the payroll function GBRTI. The formula used is as follows.

RTI Net pay = Taxable Pay TP(RTI) - Tax Paid TP(RTI) – Employee NIC (NIC) – Student Loans (RTI). Tax
refunds if any are added to the RTI Net pay.

61- This Period Pension Contributions – Pre-tax pensions


Pre-tax pensions = CRT – OCRT (/P20) + CRT – OCRT (/P21)

Therefore all Pre-tax pensions should be configured to flow into the standard /P20 and /P21 wagtypes.

RTI indicator
This is a 4 character code with always “/” as the first character. This is generated by the Pre-DME
program for all the employees who have the payment method as BACS. After payroll has been exited,
and Pre-DME is executed, this RTI indicator is generated and updated in the payroll cluster (Table RTI)
for each employee.

XML ID/Global ID
This is a unique identifier for each submission. This is generated for all employees who have the RTI
Indicator generated. This is generated in the FPS report and updated in the payroll cluster (table RTI)
after submission at the gateway.

Unique scenarios for RT Net Pay

In cases where there is a claim and net pay of the employee is zero, as per the above formula the RTI net
pay will not be zero but will hold the values of tax refunds if any.

Therefore special check is made on /101, /121 and /560 to see if the values are zero. If yes, the RTI net
pay is reported as 0.

Leavers on Last date of pay period: Leaving date input after payroll has been exited for that period

25 | P a g e
In this case, payroll would not process this employee. However the leaving date needs to be reported to
HMRC, hence FPS report would process such employees, and report the leaving date with the YTD
figures as of the previous period (leaving period)

Deriving fields for Multiple Employment


In case of MEs, irrespective of whether Net Pay solution has been activated or not, all the payments
made on Non Primary contracts will be treated as advance payments.

The advance payments for MEs need not be always followed by an RTI submission. Therefore the Non
Primary contracts will have the payments made to them without a corresponding RTI submission.

The following is what happens when payroll is run for primary and non primary

Non – Primary
When payroll is executed for the non primary contract, the processing of GBRTI is the same as that of a
single employment, except that NI calculation doesn’t happen at this contract.

The table RTI gets populated with the values specific to this contract. Non Primary contract always holds
the TP and YTD values specific for that contract.

Primary
When the payroll is executed for the primary contract, the processing of GBRTI is same as that of single
employment, except that after generating the values for this contract, it loops through the payroll result
of all the related – secondary contracts for this period. Then it reads the corresponding RTI tables and
cumulates them with that of the Primary contract to derive the YTD values.

RTI of Primary

For example: In the scenario below, 20126021 is the primary for July i.e. period 04 2012. The FPS will
report the aggregated values from both these contracts (see the row in blue) and the same will be
visible in the RTI table of Primary

RTINI of Primary

In case of RTINI since the NI calculation happens only on Primary, the CNIC and NIC values are used to
derive the YTD and TP values respectively.

26 | P a g e
The way these tables are populated are different in case of first period of Go-live and subsequent
periods.

For the first period of Go-live, the fields in both tables RTI and RTI are derive as above.

In case of subsequent periods,

YTD (RTI) = YTD (ORTI) + TP (RTI)

YTD (RTINI) = YTD (ORTINI) + NIC (EENIC) / NIC (ERNIC)

BADI in payroll function GBRTI (parameter 2)


BADI - HR_GB_PY_RTI_BADI has been provided from within the payroll function GBRTI. This can be used
to change any value of RTI and RTINI for the current period.

Tax Calculation after RTI


Tax calculation for leavers – no longer using GLTXC – which tax codes are used in which scenarios:

For Employers who has RTI activated, following will be the tax calculation for an employee who leaves
the Organisation and has Late payments that needs to be processed after he has been made a leaver.

Scenario 1: Late Payment with No P45 Issued

Employee hired on 01.04.2012


Employee has a tax code on infotype 0065 of 810L and Tax Basis is Cumulative.
Payroll run for April, May 2012
He leaves company on 15th June 2012 and this date is updated in R/3 prior to the June payroll
being processed.
The employee is taxed using the tax code on their infotype 0065 (810L) which is the tax code at
leaving date.
Any further payments made to this employee after the leaving date should be taxed with tax
details at leaving date.

Scenario 2: Late Payment with P45 Issued

Employee hired on 01.04.2012


Employee has a tax code on infotype 0065 of 810L and Tax Basis is Cumulative.
Payroll run for April, May 2012
He leaves company on 16th June 2012 and this date is updated in R/3 prior to the June payroll
being processed.
The employee is taxed using the tax code on their infotype 0065 (810L) which is the tax code at
leaving date.

27 | P a g e
The P45 should be produced showing the taxable pay and tax paid to date as at June and the tax
code 810L
Any further payments made to this employee after the leaving date has been reported to HMRC
should be taxed at 0T Mth 1.

Scenario 3: Late Leaver

Employee hired on 01.04.2012


Employee has a tax code on infotype 0065 of 810L and Tax Basis is Cumulative.
Payroll run for April, May 2012 and June 2012.
Employee has a tax code on infotype 0065 of 810L.
He leaves company on 16th June 2012 but R/3 is not updated until after the payroll has been
exited for June.
The employee is then processed in July using schema GRET.
The tax for the employee must be reassessed using the tax code on their infotype 0065 (810L) as
at June (month 3) and the free pay as at June (i.e. leaving period) for the tax calculation.
If additional payments are made to this employee in July, these should also be taxed using 810L
as at the leaving period, i.e. June (Month 3).
Once P45 is issued, Any further payments made to this employee after P45 is issued and the
leaving date has been reported to HMRC and the P45 Issue date has been update, should be
taxed at 0T Mth 1.

The new IT0065

28 | P a g e
A brand new tab called ‘Tax Details’. The tax code source options on F4 are as follows:

Starter – Employee

Starter - Ex Pat

Starter – Pensioner

HMRC – P6

HMRC – P9

HMRC – Uplift

The Tax code source will be the first field displayed followed by the other fields as detailed below:

When the tax code source is Starter – Employee, the only the following fields will be available for
update:

Tax Code

Tax Basis

Previous Earnings

Previous Tax

Starter Declaration

When the tax code source is Starter – Ex Pat, the only the following fields will be available for update:

Tax Code

Tax Basis

Starter Declaration

When the tax code source is Starter – Pensioner, the only following fields will be available for update:

Tax Code

Tax Basis

Previous Earnings

Previous Tax

Annual Pension

29 | P a g e
Recently Bereaved

Starter Declaration

When the tax code source is HMRC – P6,only the following fields will be available for update:

Tax Code

Tax Basis

Previous Earnings

Previous Tax

Incoming XML Process ID

When the tax code source is HMRC – P9 only the following fields will be available for update:

Tax Code

Tax Basis

Incoming XML Process ID

When the tax code source is HMRC – Uplift only the following fields are available for update:

Tax Code

Tax Basis

Previous Earnings

Previous Tax

The new IT0088


Employees with ASPP will have the following fields added to IT0088. The screenshot shown below
depicts the new layout of IT0088.

30 | P a g e
31 | P a g e
Pre DME Program
The Pre DME Program – RPCDTAG0 has been modified for the purpose of RTI. It performs the following
in addition to stamping BT.

Generates the RTI Indicator – a random 4 character code. The first character of this code is always a “/”

The report then stamps the RTI table of the payroll cluster with this Indicator

The RTI Indicator thus stamped on the RTI table ensures that the FPS submission only succeeds the
payment run

The FPS report then makes use of this RTI indicator to generate the 64 character Hash code for all
employees who have BACS as the method of payment

The following snapshot shows RTI table without the RTI Indicator filled. In other words, the following
indicates that after the payroll run, the RTI Indicator of the RTI table is empty.

32 | P a g e
Now, after the Pre-DME has been executed, the RTI indicator is filled as shown below.

33 | P a g e
Note:

Please ensure that for RTI purposes, wagetypes /559 and /558 need input before running the Pre-DME
program.

Pre-DME, when run for the first time for a period, /559 needs to be input. For any subsequent run for
the same period, /558 also needs to be added.

Full Payment Submission


The Full payment submission or the FPS report as it will referred to going forward in this document will
fill the rest of the fields which have not been filled by the payroll function GBRTI. All the validations on
Personal Data such as name, addresses, business validations etc will be performed in this report for the
data that is being fetched by the report.
The FPS report also generates the 64 character HASH code using the RTI indicator for those employees
who have BACS as the method of payment. The process flow within the report is as follows.

1. Can be executed at employee level / at a payroll area level. But restricted to only one payroll
area at a time
2. Reads tables RTI, RTINI for the data from payroll for the pay period being reported
3. Fills the following information by reading data from the respective sources
4. Reads the BADI to check if there is an active implementation available, and processes the data
from BADI implementation if required
5. Generates the 64 character Hash code
6. Generates a Global ID which is unique for each of the submission. This is a unique id and the
report updates the payroll cluster table RTI for that period with this ID.
7. Performs all validations
8. Output options available are ALV, XML, and submission to the Government gateway using BC/XI
based on the release.

The selection screen of the report looks as below.

34 | P a g e
The report can be executed at only one payroll are level at a time. Please not that the second payroll
area field in the tab selection is display only.

The XML submission section has the following options.

Test in Live: Before making a live submission, it is always recommended to test the data by submitting
to the Live URL. This option validates both the data and XML. SAP recommends that Test in Live
submission be made before exiting the payroll.

New Submission: This needs to be flagged when making the fresh/first submission for a pay period. This
creates a Global ID which is unique to this submission.

Re Submission: This option is used in case of errors at the gateway and to re-process the same batch of
employees processed again. Upon choosing this option the Global ID box appears. Using the F4, the
batch (identified by the Global ID) which needs re-submission after correcting the errors is chosen and
the report can be processed again. The report generates a new Global ID which overrides the older
Global ID in the payroll cluster table RTI.

35 | P a g e
Clean Sweep: This option can be used to run for each payroll area to ensure that none of the employees
are left out. This run picks all the pernrs who do not have Global ID in the RTI table filled.

The ALV output of the report looks as follows.

Communication Channels
The communication channels with the respective releases are as follows.

Release 4.6C – Release 5.00 – SAP Business Connector 4.8

Release 6.00 and above – SAP XI

ZIP
The files that are sent are by default compressed. Unlike the EOY submission there is no explicit
checkbox on the selection screen of the FPS/EAS reports to zip the files. ZIP functionality is available
only for XI customers i.e. customers on release 6.00 and above.

36 | P a g e
Employer Payment Submission
Employer Payment submission is an interface for the employer to submit the Year to date declaration
data such as the following.

The snapshot below shows the selection screen of the EPS report – RPCEPSG0. Since the frequency of
this report is monthly, tax month is one of the selection criteria.

The first section Year to date declaration would need to be sent every period. The declaration details
comprising of 6 questions (in the last section) need to be submitted only in case the entire tax reference
has ceased or when it is the last submission for that tax year as shown below.

The report does not do any processing of its own, but just an interface to submit the declaration data to
HMRC. In the absence of any declaration data for HMRC for a particular month, this report still needs to
be executed with just No declaration data flagged as shown below.

37 | P a g e
The report has same output options as that of the FPS report i.e. ALV, XML, and submission to HMRC
through the B2A Manager.

Communication Channels
The communication channels with the respective releases are as follows.

Release 4.6C – Release 5.00 – SAP Business Connector 4.8

Release 6.00 and above – SAP XI

38 | P a g e
ZIP
The files that are sent are by default compressed. Unlike the EOY submission there is no explicit
checkbox on the selection screen of the FPS/EAS reports to zip the files. ZIP functionality is available
only for XI customers i.e. customers on release 6.00 and above.

Works Number
When the EAS or FPS updates the IT0065 with the WORKS number, the IT0065 should constantly
copy this value ever till made a leaver and rehired. The IT0065 would get updated by

a. Incoming P6/P9: Automatically taken care by polling program/update manager

b. Manual creation of IT0065 record: Please use “COPY” menu while creating a new record.

c. RTI leaver report in case the employee changes the tax reference: The RTI leaver report
takes care of updating the IT0065 record.

When Employees are rehired in the same tax year the Original works number cannot be used for
reporting in FPS. The FPS will append a number to the original/previous works number and
update the IT0065 and the same will be used for reporting. The below solution will be provided
in the FPS report to cater the requirement.

------------------------------------------------------------------------------------------
Employee 10000 Hired on 01.04.2012
IT0065 works number 10000
Reported works number 10000
Employee 10000 made a leaver on 31.05.2012
------------------------------------------------------------------------------------------
Employee 10000 re hired on 01.06.2012
IT0065 works number 100001
Reported works number 100001
Employee 10000 made a leaver on 30.06.2012
-------------------------------------------------------------------------------------------
Employee 10000 re hired on 01.08.2012
IT0065 works number 100002
Reported works number 100002
Employee 10000 made a leaver on 30.08.2012

-------------------------------------------------------------------------------------------

39 | P a g e
P45 Report
RPCP45GNRTI: Single employment solution

RPCP45GNRTI_PBS: Multiple employment solution

The new leaver report does produce P45 output similar to the existing report RPCP45GN but with
differences in processing for leaver and report output.

The Produces only SAP SCRIPT and ALV output


The Report program can be executed from any date before the start date of the tax year.

Selection Screen

1.Personnel selection

2. Processing Criteria

3. Output options

Personnel selection: The block contains various options to choose or filter the employees for whom the
report should be executed.

Processing Criteria: This block contains 3 input fields described below

Tax year ending April 5th: This is a mandatory field. It is for the given tax year here the report is
executed.

Process earlier leaver: This is the newly introduced options wherein, is the user checks this option then
the start date in the selection screen becomes editable. The user can choose to give any date in the past
less than the start of the tax year. If this option is chosen then the leaver report will get all the leavers
from the specified date entered in the selection screen.

Test run: This option when checked will execute the report in test mode by only producing sap script or
ALV output. If the option is unchecked then the report is executed in live mode then the IT0065 is
updated with the issued date.

Output options: The user can choose any of the sap script or ALV as the output options with variant.

40 | P a g e
Display previous submission data
The report RPCRTI_DISP can be used to display the previous submission data, one period at a time,
based on the Global ID.

Following is the snapshot of the report’s selection screen.

The report can also be used to display the employees in error i.e. In case of business errors, HMRC
would return the employee index numbers (numbers in the XML file). This is called as XML Error
reference numbers. Previously customers had no choice but traverse through the XML to find the right
pernr in error. Now all that needs to be done is to just put the index number from the business error on
the selection screen and the report will pull out this pernr data from the xml that was previously
submitted.

In addition the option to view and download the previously submitted xml data has also been made
available.

Earlier Year Update


A new report – RPCEYUG0 has been delivered to modify previous year’s YTD figures that have been
incorrectly submitted in the previous tax year.

This report reads an excel spreadsheet in a specific format, generates the XML file with the data that is
thus read from the spreadsheet.

41 | P a g e
The selection screen of the report looks as below.

The report can be executed at a tax reference level and output options available are as follows with an
option to make a test in live submission.

1. ALV
2. XML and ALV

It has to be noted that the report neither updates nor reads data from the cluster. The spreadsheet
template is attached to the SAP note: 1818825.

Example

Employee "ABCD" with PERNR 1234, currently has Tax code BR NI Category A with the following values

EE NICS YTD £360

ER NICS YTD £384

Taxable Pay £3000

Tax paid £600

However the figures should have been

EE NICs YTD £372

ER NICS YTD £396.80

Taxable pay £3100

Tax paid £620

Therefore the spread sheet should contain the following values

42 | P a g e
Cell D2 (Employee Last Name) = ABCD

Cell M2 (Employee Date of Birth) = 1979-01-02

Cell N2 (Employee Gender) =M

Cell AE2 (HMRC WORKS Number) = 1234

Cell AG2 (Tax Code) = BR

Cell AI2 (Taxable Pay) = 100

Cell AK2 (TAX Paid) = 20

Cell AQ2 (NI Category) =A

Cell AU2 (UAPtoUEL) = 100

Cell AV2 (EMPLOYERS NICs) = 12.80

Cell AW2 (EMPLOYEES NICs) = 12.00

Reconciliation report
A new report RPURCNG0TRA has been delivered. These can be used to compare the YTDs on the P14 to
that of the YTDs on the RTI and RTINI tables.

Upon executing these reports, they display the records where there are differences between the P14
and the corresponding RTI/RTINI YTD values.

Following snapshot provides the selection screen for the reconciliation reports.

43 | P a g e
Transaction Codes for various reports

PC00_M08_RTI_EAS RPCEASG0

PC00_M08_RTI_EPS RPCEPSG0

PC00_M08_RTI_FPS RPCFPSG0

PC00_M08_P45_RTI_PBS RPCP45GNRTI_PBS

PC00_M08_P45_RTI RPCP45GNRTI

PC00_M08_RTI_DISP RPCRTI_DISP

44 | P a g e

You might also like