Oracle HRMS enables employers to meet the real time information (RTI) reporting every time a payment is made to the employee as required by HMRC. As the RTI reporting replaces End of Year reporting and In-Year filing, Oracle HRMS enables you to align employee data with HMRC data. Along with RTI, Oracle HRMS continues supporting P45, P60, and P11D reporting as they are in use.
RTI reporting collects information about tax and other deductions automatically each time you run the payroll. This could be monthly, weekly, or fortnightly. HMRC receives this automatically at the same time as the employees are paid. This reporting process gets information on those joining and leaving employment to HMRC more quickly. For example, RTI enables the date of leaving to be submitted before the final earnings information. A more accurate HRC database reduces queries and the need for recalculations of employee's tax. Additionally, HMRC receives the full amount payment due from the employer each pay period. RTI reporting means that the following procedures will be simplified or discontinued:
Issuing a P45 to all employees who leave employment.
Notifying HMRC of those employees who join.
Determining a tax code by requiring new employees to complete a P45.
Submitting end of year P14, P35 and P38A returns to HMRC.
To meet RTI reporting requirements, you can submit the following outgoing and receive the incoming XML messages:
Outgoing
Full Payment Submission
Employer Payment Summary
NINO Verification Request
Incoming
NINO Verification Reply
Full Payment Submission (FPS) – to be submitted to HMRC each time the employer makes a payment to an employee. It picks up data relating to the payments processed for the relevant period for the PAYE scheme. A number of scenarios have been published by HMRC to demonstrate what values need to be reported under different circumstances. The data relates to 'employment' within the PAYE and as such all payments and deductions are reported as this period and year to date figures. You can submit this after submitting the EAS. HMRC uses this to update their records with the YTD values for your employees. You must submit this on or before the date of payment to your employees. You can send it per Payroll within the PAYE Scheme if required. Additionally, this submission includes any company declaration details if PAYE Scheme has ceased and End of Tax year FPS. The first FPS that you submit includes:
All employees reported on the Employer Alignment Submission (EAS).
Plus any new starters since you submitted the EAS.
Plus all employees who have been paid this tax year (includes all those leavers in the last tax year if they had a payment after leaving).
The subsequent FPS includes all employees that have been paid in the period being reported.
Employer Payment Summary (EPS) – can be submitted where the employer needs to notify HMRC of adjustments to their overall liability. If the EPS is not submitted, then the values determined from the regular FPS submission are expected to be paid over by HMRC. Employers can make adjustments to the overall employer-level amounts due (the total PAYE / NI, which should have been paid to HMRC to cover all individual employee-level amounts). Amounts which the employer is entitled to recover for payments of SMP / ASPP and also for NIC compensation relating to statutory payments, can also be submitted via the EPS. In addition, a final declaration to be made relating to values to be reported at the end of year is covered by this XML message. This is an optional XML file to be submitted for the tax period. Additionally, this file includes any company declaration details.
NINO Verification Request (NVREQ) – an ad-hoc process which allows employers to request either a validation of existing NI numbers for employees or obtain a valid NINO for new employees. HMRC sends an acknowledgement file with a correlation ID (in case employers want to stamp the employee record for audit purposes) and then follows up by sending the verified or new NI number via the (incoming) NINO Verification Reply message.
NINO Verification Reply (NVREP) – this is a message from HMRC notifying the NI number to be used for the employee. The NVREQ message can be either a response to a NI number Verification Request (NVREQ) from the employer, or as a result of an incorrect / missing NI number on the FPS or EAS submission. Contains the NINO to be used and indicates the action to be taken by the employer. Employers must update their employee records and report this notified NI number for future submissions.
If you pay your employees via BACS, then the RTI data forms part of the BACS submission. The data is submitted at the same time as the employees' salary payment details. The BACS payment file record 'Standard 18 Record Format' includes a four digit random 'reference' number as stipulated by the RTI requirements from HMRC. As a result, the BACS file creation process in Oracle HRMS includes the random number which in turn is referenced in the FPS employee/assignment record to generate the 'HASH' field for the relevant record.
The BACS record is in the following format: 1108010057846309940012171367706//9V00000138028ACME LTD 705365 MISS E EMPLOYEE
Where '//9V' is the random reference number generated for the payment record. Oracle HRMS generates the random number only for the BACS record with highest amount being paid where an employee has multiple payment lines. This field is blank for the other payment records for the employee. This is as per the requirements of FPS Hash as dictated by HMRC.
Note: The HASH itself is on the FPS record for the relevant employment record and not the BACS record as explained above.
Oracle HRMS enables you to use the pre or post RTI BACS file creation process to ensure that if you are not on RTI as yet, then you are not impacted by the changes introduced for RTI within the BACS file. You can continue to use the existing BACS file creation functionality that does not generate the random number which is required to accommodate the HASHing requirement within RTI. Additionally, if you are migrating your PAYE schemes in batches, then you have the option for the non-RTI PAYE schemes. You can use the RTI Uptake profile option for this purpose along with the RTI Uptake configuration type that enables you to migrate your PAYE Schemes all at once or in batches.
See: User Profiles topic in Oracle HRMS Configuring, Reporting, and System Administration Guide and Mapping Existing Data for RTI
For further details about RTI Reporting, see My Oracle Support Note 1324671.1
Where ever possible, RTI reporting uses the current application payroll balances. However, as the RTI information goes beyond the End Of Year reporting (currently P14), the following secondary classifications and classification balances are available. You can attach elements that are already in use to the classifications to establish the feeds to these balances so that the relevant figures needed for RTI reporting are picked up.
The following tables show the secondary classifications, elements, and their balances available for RTI:
Secondary Classification | Balance Required | Description |
---|---|---|
Secondary Classification: Post Tax Pension For Existing Classification: Voluntary Deduction Description: Post Tax Pension deductions |
Classification Balance: Post Tax Pension Contributions Description: Post Tax Pension Contributions Balance Category: RTI Reporting |
Predefined secondary classification and balance to add the Pension Contribution element where it is taken as deduction from Net pay. Attach if required |
Secondary Classification: Pre-Tax Pension For Existing Classification: Pre-Tax Deductions Description: Pre Tax Pension deductions |
Classification Balance: Pre-Tax Pension Contributions Description: Pre Tax Pension Contributions Balance Category: RTI Reporting |
Predefined secondary classification and balance to add the Pension Contribution element where it is 'Pre-Tax' deduction. Attach if required |
Secondary Classification: NI'able Free of Tax For Existing Classification: Pre-Tax Deductions Description: NI'able Deductions Free of Tax |
Classification Balance: NI'able Deductions Free of Tax Description: NI'able deductions Free of Tax |
Predefined secondary classification and balance to add the pre-tax deduction elements (if these deductions affect taxable pay). Attach if required |
Secondary Classification: Free of Tax For Existing Classification: Earnings Description: Earnings Free of Tax |
Classification Balance: Earnings Free of Tax Description: Earnings Free of NI |
Predefined secondary classification to feed the existing balance to report all pay that is not subject to tax. Attach if required |
Secondary Classification: Free of NI For Existing Classification: Earnings Description: Earnings Free of NI |
Classification Balance: Earnings Free of NIC Description: Earnings Free of Tax |
Predefined secondary classification and balance to report all pay that is not subject to NIC Attach if required. |
Secondary Classification: Free of Tax and NI For Existing Classification: Earnings Description: Earnings Free of Tax and NI |
Classification Balance: Earnings Free of Tax and NI Description: Earnings Free of Tax and NI |
Predefined secondary classification and balance to report all pay that are not subject to tax nor NIC. Attach if required. |
Existing Classification: Direct Payment | Classification Balance: Total Direct Payments Description: Total Direct Payments |
Predefined balance to be fed by existing classification 'Direct Payments' to collect all payments classified under the Direct Payments classification. Attach if required |
Secondary Classification: Taxable Benefit Earnings Subject to NIC For Existing Classification: Earnings Description: Taxable Benefit Earnings Subject to NIC |
Classification Balance: Benefits Taxed Thru Payroll Subject to NIC Earnings Description: Benefits Taxed Through Payroll Subject to NIC as Earnings |
Predefined secondary classification and balance to add the Earnings elements for benefits that are taxed through payroll but not actually paid. Attach if required. |
Secondary Classification: Taxable Benefit Earnings NOT Subject to NIC For Existing Classification: Earnings |
Classification Balance: Benefits Taxed Thru Payroll NOT Subject to NIC Earnings Description: Benefits Taxed Through Payroll NOT Subject to NIC as Earnings |
Predefined secondary classification and balance to add the earnings elements for benefits that processed through payroll but not actually paid. Attach if required. |
Secondary Classification: Taxable Benefit Subject to NIC Information For Existing Classification Information Description: Taxable Benefit Subject to NIC Information Elements |
Classification Balance: Benefits Taxed Thru Payroll Subject to NIC Information Description: Benefits not earnings Taxed Through Payroll Subject to NIC Information |
Predefined secondary classification and balance to add the Information elements for benefits that are taxed through payroll but not actually paid and are subject to NI deductions. Attach if required. |
New Secondary Classification: Taxable Benefit NOT Subject to NIC Information For Existing Classification: Information Description: Taxable Benefit NOT Subject to NIC Information Elements |
Classification Balance: Benefits Taxed Thru Payroll NOT Subject to NIC Information Description: Benefits not earnings Taxed Through Payroll NOT Subject to NIC Information |
Predefined secondary classification and balance to add the Information elements for benefits that are processed through payroll but not actually paid and are not subject to NI deductions. Attach if required. |
Name of Classification | Associated Indirect Element | Classification Balance feed |
---|---|---|
SMP Non Payment Recovery | SMP Recovery | SMP Recovery |
SMP Non Payment NIC Compensation | SMP NIC Compensation | SMP NIC Compensation |
SAP Non Payment Recovery | SAP Recovery | SAP Recovery |
SAP Non Payment NIC Compensation | SAP NIC Compensation | SAP NIC Compensation |
SPP Birth Non Payment Recovery | OSPP Recovery Birth | OSPP Recovery Birth |
SPP Birth Non Payment NIC Compensation | OSPP Birth NIC Compensation | OSPP Birth NIC Compensation |
SPP Adoption Non Payment Recovery | OSPP Recovery Adoption | OSPP Recovery Adoption |
SPP Adoption Non Payment NIC Compensation | OSPP NIC Compensation Adoption | OSPP NIC Compensation Adoption |
ASPP Birth Non Payment Recovery | ASPP Recovery Birth | ASPP Recovery Birth |
ASPP Birth Non Payment NIC Compensation | ASPP NIC Compensation Birth | ASPP NIC Compensation Birth |
ASPP Adoption Non Payment Recovery | ASPP Recovery Adoption | ASPP Recovery Adoption |
ASPP Adoption Non Payment NIC Compensation | ASPP NIC Compensation Adoption | ASPP NIC Compensation Adoption |
Element | Balance |
---|---|
Setup SMP Recovery Balance | SMP Recovery Amount, SMP NIC Compensation |
Setup SAP Recovery Balance | SAP Recovery Amount, SAP NIC Compensation |
Setup SPP Recovery Balance | SPP Adoption Recovery Amount, SPP Adoption NIC Compensation, SPP Birth Recovery Amount, SPP Birth NIC Compensation |
Setup ASPP Birth Recovery Balance | ASPP Adoption Recovery Amount, ASPP Adoption NIC Compensation, ASPP Birth Recovery Amount, ASPP Birth NIC Compensation |
For RTI users, HMRC refers to the Payroll ID instead of Works Number in any incoming files to employers and therefore sends that in place of the Works Number. Hence, the P6/P9 update process checks if it is being run for RTI PAYE as it needs to match on the RTI Payroll ID instead of Works Number. There is no separate process for RTI users as the checks are made internally within the existing process to determine what to use for matching the assignments. The following apply to all RTI users running the P6/P9 process:
You must ensure that the RTI Uptake profile is set to either Full or Partial. When the P6/P9 process runs, the following applies:
'Partial' only picks up RTI Payroll ID for the PAYE's configured in the Configuration Module
'Full' picks up RTI ID for all the PAYE's within the business group.
When Aggregation is in place for assignments, the process updates the information received in the P6/P9 file as follows:
PAYE aggregation – updates all assignments.
NI Only aggregation – updates only those assignments with the RTI Payroll ID match.
If PAYE aggregation exists and the RTI Payroll ID is not the same across the aggregated assignments (or null against any assignment), then the process raises an error. You must examine and correct the information on RTI Payroll ID before processing the record again.
For RTI customers, HMRC does:
Not supply works number in the field ATT2 / 19 of the MOVDED record.
Instead, it supplies the RTI Payroll ID (as defined within Oracle HMRS).
You must ensure that the RTI Payroll ID is present on all assignments as follows:
Run the Populate RTI Payroll ID with Assignment Number process. See: Running the Populate RTI Payroll ID with Assignment Number
For PAYE aggregation, if you change the RTI Payroll ID manually, then ensure that it is the same across all the aggregated assignments.
If you have migrated to RTI reporting, then note the following:
There are no P14 returns for RTI users.
Running the 'Final' FPS indicates to HMRC that this is an EOY submission.
You can send FPS Final Submission multiple times as required until 19th April
For most employers, the final Full Payment Submission (FPS) return is made on or before 5th April when you make the final payment of earnings for the tax year.
You should indicate that this is your 'final submission for year' through the FPS. However, if you discover on or before the 19th April, following the end of the tax year, that you need to make any amendments or corrections to the information reported you can submit an additional FPS. You must indicate on your amended FPS that this is your 'final submission for year'. If you have to make any amendments or corrections on or after 20th April, you need to complete an Earlier Year Update (EYU). This is the procedure for the end of the tax year only. Within the year, you can make corrections to an FPS by sending a corrected FPS.
The 'Final FPS' indicator lets HMRC know that the employer has completed their submissions for the year. You must report this on the last FPS that you submit which does not include all employees who have been reported during the tax year, but only contains records for employees who have a payment to be reported in this final run. It may be that the last FPS is reporting only a very small number of payments (if this is a supplementary run after the last main payroll of the tax year).
If the Final Submission option is set on the process parameter for EPS and/or FPS, then you must complete the Declaration parameters, otherwise HMRC rejects the file.
After 19 April 19, use the Earlier Year Update (EYU) message to send amendments to employee values for the previous tax year.
Any FPS submission which is for a process in the new tax year (the payroll run / balance adjustment process is on or after 6 April), then you must use the new FPS process for 2013/14. You must run the EPS also for the appropriate year that the payments relate to in the same manner as the FPS. You must run the EPS for any EYU submission that would affect the Statutory Payments Recovery and NI Compensation values.
Oracle HRMS provides a new version of the EDI message types for RTI for each tax year. For the 2012/13 tax year, the EPS message type is 'EPS' and the EYU message type is 'EYU13'. Regardless of the date of submission, if you want to update figures for the 2012/13 tax year, they you must use 'EYU13' and 'EPS' as required. For the 2013/14 tax year, there is an 'EPS14' and 'EYU14'. Use these to adjust the 2013/14 tax year values. So, if you discover in May 2014 that you need to adjust figures for 2012/13, then you can still use 'EYU13' and 'EPS'.
To generate P60, you must run the RTI P60 process. See: P60 and RTI
There is no change to running the P11D processes for RTI users and you must follow the existing processes.
There are no changes to Start Of Year for RTI users and you must follow the normal processes for SOY.
Upload P6/P9 by running the existing process. For RTI users, this process determines whether to use RTI Payroll ID to match the records depending on the RTI Uptake profile value. See: P6/P9 and RTI
For information about setting up your system for RTI reporting requirements, see Setting up Real Time Information Reporting.
To meet RTI reporting requirements, you must ensure that the following are set up:
Register the following extra information types (EITs) and assign them to your responsibility:
RTI Information (Table Name parameter value while registering is PER_ASSIGNMENT_INFO_TYPES and code while assigning to responsibility is GB_PAY_RTI )
RTI New Starter Information (Table Name parameter value while registering is PER_ASSIGNMENT_INFO_TYPES and code while assigning to responsibility is GB_RTI_ASG_DETAILS)
RTI Assignment Aggregation (Table Name parameter value while registering is PER_ASSIGNMENT_INFO_TYPES and code while assigning to responsibility is GB_RTI_AGGREGATION)
Real Time Information - NINO Verification (Table Name parameter value while registering is PER_PEOPLE_INFO_TYPES and code while assigning to responsibility is RTI_NINO)
See: Running the Register Extra Information Types (EITs) Process and Setting Up Extra Information Types for a Responsibility in Oracle HRMS Configuring, Reporting, and System Administration Guide
Ensure you have the Employer Office Reference Number to enter it in the Tax Reference Details organization EIT.
Ensure that all PAYE references are available within the application as RTI is submitted per PAYE.
Passport number is the optional data item required for RTI. If this is available, then map it using the configuration values module type 'Passport Number'. If you are using the Documents of Reference functionality, then ensure that the document type is 'passport' and the document number is the Passport Number. The FPS process picks up the passport number from this field, if present.
If your employees have valid NI numbers that have been in use as verified by HMRC, then you may want to run the Pre-RTI NINO Verification process to set the 'NINO verified' flag as a mass update. This prevents the NINO Verification request process from picking up all the employees un-necessarily when you run it for the first time.
Examine your pay or information elements to deduce if they belong to any of the items listed for reporting in the mapping of the XML fields and allocate them to the additional new secondary classification introduced as part of the RTI functionality. This ensures that the (new) balances being reported on FPS and EAS have the correct value.
See: UK EDI Decommissioning changes effective from April 2018 , My Oracle Support Document 2287642.1 for more details on how to set up XML Processing.
Creation of the Employer Payment Summary XML requires you to submit the values for verification to an 'Approver' who can then 'verify' that the EPS record is correct and ready for XML. Ensure that you have approvers notification set up using workflow to the appropriate individuals so that they get the notifications to approve and verify the EPS record. The XML process does not pick up any records that have not been verified (status should be 'Verified'). If you wish not to use the approver functionality, then you must ensure that the 'RTI Employer Payment Summary approval process required' profile option is switched off by setting the value to No; the default is Yes.
You must run the one-time process called 'RTI Payroll ID Defaulting' to ensure that this attribute on the new 'RTI Aggregation' tab is populated for your existing employees. The EAS, FPS, and NINO processes pick up this field value. It is not necessary to populate this field on an on-going basis and is a one-time uptake procedure only. For further details on this process, see Running the Populate RTI Payroll ID with Assignment Number Process
To uptake the RTI option of reporting, you must set the RTI Uptake profile option with an applicable value. See: User Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide. Additionally, you need to provide values for the configuration type RTI Uptake depending on the value set for the profile option.
Once you are on RTI, ensure that you enter all new starter information using the new RTI tab only. You must not use the other original pre-RTI tabs namely, New Starter, P46 Pension Notification, and P46 (EXPAT) Notification, for those PAYE schemes on RTI, as RTI reporting does not pick up information from these tabs.
Enter RTI aggregation information. See: Entering RTI Aggregation Information
Record RTI specific data using the assignment and person extra information types.
Attach existing elements to the RTI related secondary classifications to establish the feeds to the RTI related balances so that RTI reporting can pick up the relevant figures. The application reports these balances on the RTI Full Payment Submission records.
Additionally, set up your own elements that are deemed as Trivial Commutation Payments and the Payment Type for the following balances:
Trivial Commutation Type A
Trivial Commutation Type B
Trivial Commutation Type C
If there is any value in the balances above, then the FPS process reports these in the FPS employment record section in pairs of type and value. It reports up to three iterations (one per type).
Map existing data using the configuration module if data required for RTI is available in your system and if you are migrating partially (staged approach for groups of PAYE Schemes). Additionally, you can choose the correct BACS process (with or without HASHing field). See: Mapping Existing Data for RTI
Run the following RTI processes to generate the RTI archive and output XML files:
Pre RTI Migration
Run the Populate RTI Payroll ID with Assignment Number Process
Run the Pre-RTI NINO Verification Process
At the time of Migration
Note: The EAS process is not available from April 2018.
Run the Employer Alignment Submission Process (EAS)
Roll Back EAS
Post RTI Migration
Run the Create EPS Payment Values
Run the Employer Payment Summary Process (EPS)
Run the Employer Payment Summary Reset Status
Run the Earlier Year Update Process
Run the Full Payment Submission Process (FPS)
Run the Full Payment Submission Output
Run the NINO Verification Request Process (NVREQ)
Run the NINO Verification Reply Upload Process (NVREP)
P60 and RTI
P6/P9 and RTI
End of Year for RTI
Submit the RTI messages.
Oracle HRMS enables you to record the new starter information for RTI reporting. Use the New Starter (RTI) tab on the Statutory Details window. This tab combines the information for starters that is currently held in the current New Starter and P46 tabs. If you are on RTI, then you must use this tab to input the relevant data instead of the current practice of using the New Starter and P46 tabs. The New Starter RTI tab is for input of new starter declaration, pension amount, and expat information only. You must enter the P45 information using the PAYE details tab and any NI information the NI details tab. RTI reporting uses information from the PAYE details and NI details tabs. After you migrate to RTI, the following tabs will become redundant and RTI reporting does not use any information recorded in the tabs:
New Starter
P46 Pension Notification
P46(EXPAT) Notification
The New Starter (RTI) tab displays three sections which represent starter information being brought in by an employee, an ex-pat, or a pensioner. This tab combines the three types of starters' information that you need to file new starters using RTI.
To enter new starter information for RTI
Query the employee assignment and choose the Tax Information button.
Click the New Starter (RTI) tab.
In the New Starter section, the RTI Sent check box is automatically checked after you have run the FPS process to indicate that the starter information has been sent to HMRC. You can manually select it too. The record is not re-sent in subsequent FPS process. This is the same as the current new starter in-year filing (pre-RTI) process behavior.
As new starter declaration, enter what type of starter this person is where a P46 is sent. Choose from a list of values as follows:
A for First Job since 6th April
B for Only job currently
C for Have another job or pension
Select the Continue with Student Loan check box as required for continuing with student loan deductions.
In the Pensioner section, the RTI Sent check box is automatically checked after the FPS process has been run to indicate that the pensioner information has been sent to HMRC. You can select it manually too. The record is not re-sent in subsequent FPS process. This is the same as the current new starter in-year filing (pre-RTI) process behaviour.
Enter the date when the pension started. The RTI reporting process sends the starter declaration for the pensioner from the date the pension started.
Enter the annual pension.
Do not enter starter declaration but specify if the pensioner is in receipt of occupational pension.
In the EXPAT section, the RTI Sent check box is automatically checked after the FPS process has been run to indicate that the Expat information has been sent to HMRC. You can select it manually too. The record is not re-sent in subsequent FPS process. This is the same as the current new starter in-year filing (pre-RTI) process behaviour.
Do not enter the starter declaration but select the expat P46 statement from the following:
A Intension to live in the UK for more than six months.
B Intension to live in the UK for less than Six months.
C Living abroad, intend to work both inside and outside UK.
Select the EEA/Commonwealth Citizen check box as required.
Select the EPM6 (Modified Scheme) check box as required.
Enter the start date of employment in the United Kingdom.
Select the Continue with Student Loan check box as required for continuing with student loan deductions.
Note: Regarding the RTI Sent check box:
Whenever EAS process is run, the process selects the RTI Sent check box in the New starter section within the New starter (RTI) tab for all the employees picked up by the EAS process.
For new hires created after EAS process, whenever FPS process is run, the process would report the error message "Starter Declaration is Missing" if you have not entered the required data on the corresponding blocks (New Starter, Pensioner, EXPAT) in New Starter(RTI) tab.
If you have entered the data prior to running the FPS process, then the process would not report the error; instead it processes the assignment and checks the corresponding RTI Sent check box and reports the relevant values on FPS XML.
If EAS process is rolled back, then the roll back process deselects the RTI Sent check box selected earlier by the EAS program.
If FPS process is rolled back, then the roll back process deselects the RTI Sent check box selected earlier by the FPS program.
Oracle HRMS enables you to enter data required for aggregation of PAYE and NI by RTI reporting. The Full Payment Submission requires this data for processing aggregated assignments. Use the RTI Aggregation tab on the Statutory Details window.
To enter RTI aggregation information
Query the employee assignment and choose the Tax Information button.
Click the RTI Aggregation tab.
Select the RTI NI Reporting Assignment check box where there is aggregation for NI only, to indicate the assignment record used to pick up the NI YTD values for reporting in the NI section of the FPS employment record.
For NI aggregation, there are multiple employment records output to ensure that the reporting of FPS record is a per HMRC expectation. This check box is not relevant for those assignments that are set for PAYE and NI aggregation as RTI reporting process treats these assignments as one record and output as a single employment record.
Note: The RTI NI Reporting Assignment check box is enabled only when the NI Multiple Assignments check box is selected (this indicates NI only aggregation).
The Effective Date field becomes mandatory after you select the RTI NI Reporting Assignment check box.
You must change the RTI NI Reporting Assignment check box only if the assignment that was the reporting assignment for NI, is terminated. In this case, ensure that you select this check box on the new or different assignment as appropriate.
Enter the effective date to enable the RTI Reporting Assignment check box to be date tracked as the information here is not date tracked as a rule.
Note: At the time of migration to RTI, the process that populates the RTI NI Reporting Assignment check box sets the effective date to the start of the current tax year (06-April-yyyyy).
The application populates the RTI Payroll ID and the effective dates as follows:
Defaults to primary assignment number if the PAYE Aggregated Assignments check box is selected.
Defaults to assignment number of each assignment if the PAYE Aggregated Assignments check box is not selected.
Ensure that you run the Populate RTI Payroll ID with Assignment Number concurrent program to enable the application to populate the Payroll ID Effective Start Date and Payroll ID Effective End Date with the appropriate values. The application sets the effective start date to the hire date of the assignment and the effective end date to end of time (31-DEC-4712). The effective dates ensure that the track history is maintained for NI Reporting flag along with RTI Payroll ID. If the payroll ID is changed for any reason, then all assignments aggregated for PAYE must be updated with the same RTI Payroll ID. This number assists in identifying the person's ID for RTI purposes. RTI reporting process use the RTI Payroll ID for reporting the payroll ID fields on the RTI XML files sent to HMRC. Additionally, the FPS process uses this ID to report employment records as one per payroll ID in cases of aggregation of NI.
Note: Use the Populate Payroll IDs concurrent program to populate the payroll IDs if you are already on the previous version of RTI (first Pilot customers. You must run this program to ensure that the payroll ID's are correctly updated as assignment numbers for non-aggregated assignments. See: Running the Populate RTI Payroll ID with Assignment Number Process
Some data items required by RTI may already exist within your Oracle HRMS application. RTI reporting process can use and report these data items. You can map your existing data that RTI requires using the configuration types within the Real Time Information configuration module in the Configuration Values page.
You do not need to configure the following items if you are using the RTI Information assignment extra information type:
Number of Periods Covered
Irregular Employment
One-Off Payment
Normal Hours Band (Hours Worked listed above)
Receiving Occupational Pension
Ex Pat
Payment to Non-Individual
On Strike
Unpaid Absence
Off-Payroll Worker Indicator
This module is only for mapping the above information if you have it stored already in your own placeholders. The configuration module mapping ensures that the data is picked up from your placeholders and not from the RTI Information EIT.
If you are using the standard Oracle functionality of Documents Of Record to hold passport information, then you do not need to configure this item as this RTI processes pick up this information automatically. However, if you have stored passport number elsewhere using your own flexfield, then map it using the Employee Details – Passport Number configuration type.
The following configuration types are predefined:
Employee Hours – The mapping is entirely optional as the RTI processes pick up the hours from assignment normal hours or if the RTI Information assignment EIT has a Normal Hours band value specified, if the configuration is not present.
Irregular Payment - The mapping is entirely optional as the RTI processes pick up the Indicator from the Irregular Payment value specified in the RTI Information assignment EIT, if the configuration is not present.
Number of Periods Covered - The mapping is entirely optional as the RTI processes pick up the Indicator from the Number Of Periods Covered value specified in the RTI Information assignment EIT, if the configuration is not present.
One-Off Payment - The mapping is entirely optional as the RTI processes pick up the Indicator from the On-Off Payment value specified in the RTI Information assignment EIT, if the configuration is not present. If you are using the User Function option, then note the following:
Provide the inputs of 'assignment_id' and 'effective_date' for the function to work.
Ensure that the user function returns the appropriate values as expected by the relevant data item (for example, for Flags the value 'Y' should be returned; for Hours Worked the value of total number of hours should be returned).
FPS picks up the FF and executes it to return the value expected for the XML field in question.
Off-Payroll Worker Indicator – Use the Off-Payroll Worker indicator to flag an employee as an off-payroll worker.
Student loan deductions to not apply to off-payroll workers. This includes Plan 1 and Plan 2 student loans and postgraduate loans.
Off-payroll workers are not entitled to receive statutory payments (SSP, SMP, SAP, SPP, ShPP or SPBP).
Pensions automatic enrolment does not apply to off-payroll workers.
Secondary (employer) Class 1 NICs relating to employment of off-payroll workers are disregarded when calculating entitlement to claim the employment allowance.
The FPS submission includes the Off-Payroll Worker indicator.
Terminations are processed for an off-payroll worker in the same way as for a regular employee. A P45 will be produced after termination according to employer configurations, reporting taxable pay and other details as usual.
If a person is set up as an employee on the payroll and they also provide services which mean they become a “deemed employee” for that contract, they must have two separate employment records with different payroll IDs. The record relating to the deemed employment would have the Off-Payroll Worker indicator checked; the other would not. The two employments must be completely independent of each other and are processed and reported separately.
No aggregation of either PAYE or National Insurance applies.
Passport Number - The mapping is entirely optional as the RTI processes pick up the passport number from Documents of Records if used or configuration value mapping. The passport number is an optional field to be reported for RTI and is left blank if not present anywhere.
RTI Uptake – Use this configuration type if you have multiple PAYE Schemes and need to migrate to RTI in a phased manner. This configuration type ensures the following:
Differentiates between the BACS process to be used (Post or PRE) as the post RTI BACS process has been changed to include the random number field on the BACS record.
Allows Oracle users with a multiple number of PAYE schemes with large population of employees to migrate in a phased manner (this must be agreed first with HMRC).
Removes the need for Oracle users to choose the pre and post RTI BACS process to be utilised and prevent serious issues on employee payment through BACS.
In order to take up RTI for PAYE Schemes, you must set up the schemes on this configuration type. Mapping the schemes ensures that the schemes are processed for RTI BACS correctly. This configuration type is optional but you must use it in conjunction with the RTI Uptake profile option as follows:
If profile value is None – no need to set configuration value here as the application uses the Pre-RTI version BACS process without generating the random number.
If profile value is All – no need to set configuration value here as the application uses Pre-RTI version BACS process that generates the random number.
If the profile value is Partial – set this configuration type for each of the PAYE Schemes that are migrating to RTI.
The effective date is the date on which the PAYE Reference is going over to RTI. The RTI functionality checks this date and decides which BACS process needs to be used for the given PAYE Reference. You can create multiple configuration types one for each PAYE in question with its own effective date. For any PAYE scheme reference that does not have a configuration type set up when the profile value is Partial, then the application uses the Pre-RTI BACS process for these schemes.
To map your existing data to the required configuration type
Navigate to the Configuration Values page through Other Definitions > Configurations Values.
Query the Real Time Configuration using the search icon next to the Module Name field and select it from the Search page.
Select the applicable configuration type and click Add Configuration Values.
In the Add Configuration Values page for the selected configuration type, enter the following details:
Source - Identify the placeholder source, for example an extra information type, descriptive flexfield, or function.
Context Name - The application populates the list of values with the context names of the source specified and you can select as required.
Segment Column - If the source is an EIT or DFF, then specify the segment column that holds the applicable value.
User Function Name - If the source specified is a function, then select the function name from the list of values.
Click Apply.
If you are migrating to RTI functionality, then you need to populate the RTI Payroll ID field for your existing employees. The application defaults the payroll ID for all new employee assignments once the RTI functionality is implemented, however, prior to RTI migration, you must populate the payroll ID for all existing employee assignments to ensure that all the payroll ID's are in place for RTI reporting. Use the Populate RTI Payroll ID with Assignment Number to populate the RTI Payroll ID with either:
Assignment number as is (for non-aggregated assignments).
Primary assignment number for PAYE aggregated assignments.
This is a one-time process that you must run to ensure the existing assignments have this field populated correctly. All subsequent assignments started after RTI migration default to the appropriate assignment number taking aggregation type into account automatically. Use the Submit Request window.
To run the Populate RTI Payroll ID with Assignment Number process
Select Populate RTI Payroll ID with Assignment Number in the Name field.
Enter the following parameters:
PAYE Ref num – Select from the list of PAYE reference numbers in the organization.
Effective Date – Enter a date from which you want all employees to be picked up. This would normally be the date RTI was implemented as Live to ensure that all employees are picked up.
Prior to RTI migration, you can align your employee data with that held with HMRC using this process. This process enables you to create and submit an alignment report.
The EAS process picks up all employees within the PAYE for the requested tax year if:
They are active or were active during the tax year in question.
Picks up all starters and leavers in the tax year.
It does not pick up any employees who have left in the previous tax year as they are not considered active employees within the current tax year. However, these employees are picked up in the first FPS that follows, as they are considered as having a payment in the tax year.
This process creates one employment record for each assignment provided that they are not aggregated. If they are aggregated for PAYE and NI, then there is one record output with the aggregated values. If they are aggregated for NI only, then this process reports the assignments separately. If P45 is issued, then this process considers the person as 'left', hence the date of leaving is that of the assignment. For aggregated assignments, the Continuous Period of Employment (CPE) start and end dates are reported as P45 is not issued if one of the aggregated assignments is terminated due to it being part of the same employment.
You can submit the Employer Alignment Submission in 'parts' from April 2013 if you are operating your PAYE scheme through different vendors, or choose to send in data for alignment in logical 'chunks'.
Use the Submit Request window.
To run the EAS process 2013/14
Select RTI – Employer Alignment Submission Process (EAS) 2013/14 in the name field.
Enter the following parameters:
Employers PAYE Reference – Select from the list of all the PAYE references within the organization. This is a mandatory parameter.
Effective Date – This date determines the tax year for which the EAS data is to be extracted. The effective date must be the date of the RTI migration. For example, if the RTI migration date is agreed with HMRC as February 2013, then this date must be 01-Feb-2013. If the migration date is agreed as the 1st period in the new tax year and this payroll period spans both tax years (a 4 weekly payroll with dates of 30th March to 26th April 2013), then enter the date as 06-April-2013 to filter out any previous year starters and leavers. The EAS process picks up all the employees current at this date. Additionally, as the process uses this date to derive the start of the tax year it picks up the starters and leavers in the relevant tax year. This is a mandatory parameter.
Number of Parts - Mandatory parameter, with default value set to 1.
Unique Part Identifier - Not mandatory but you must enter the value if Number of Parts parameter is more than 1. This is the payroll unique identifier set up on the payroll if used. It is only enabled if the Number of Parts parameter is more than 1. The Number of Parts and Unique Part Identifier parameters allow part submission of EAS which enables employers to send separate EAS files in 'parts' with same PAYE reference at different times.
Test Submission – Optionally, select Yes to send a test EAS message file. For Live files, default value is always No.
To run the EAS process Pre 06 April 13
Run the Employer Alignment Submission Process Pre 06 April 13 process for tax year 2012/13.
Select RTI – Employer Alignment Submission Process Pre 06 April 13 in the Name field.
Enter the employers PAYE reference, effective date, and specify whether it is a test submission or not as parameters.
Note: EAS is no longer required from April 2018.
Once you run the Employer Alignment Submission (EAS), the application sets the RTI value for the employees so that these new starts are not picked up again. Therefore, to re-run the EAS, you must roll it back. The rollback unsets the RTI value to ensure that when you re-run the EAS, it includes all employees.
Use the Submit Request window.
To rollback EAS
Select GB Rollback in the Name field.
Enter the following parameters:
Year – enter the year for which you want to rollback the EAS.
Process Type – select Magnetic Reports as the payroll process type.
Payroll Process – search for the required payroll process ID to rollback.
Assignment Set – optionally, select the assignment set.
Oracle HRMS for UK enables you to migrate the existing normal hours bands to the revised bands. This concurrent program migrates the normal hours band recorded against the RTI Information assignment EIT to the RTI Information element's input value 'Normal Hours Band'. This enables the application to maintain the date track history.
This program migrates the normal hours band as follows:
A - A
B - B
C - D
D - E
You can run the program in Validate Only - Updates Not Applied To The Database mode first, to ensure that the program reports the expected list of employee records with appropriate normal working hour bands. If you are satisfied with the results, then you can run the process in Validate and Commit mode to commit the changes to the database.
Use the Submit Request window.
To run the RTI – GB Populate Hour Bands
Select RTI – GB Populate Hour Bands in the Name field.
Enter the following parameters:
PAYE Reference – Select from the list of all the PAYE references within the organization.
Effective Date - Enter the effective date from when to migrate the existing normal hours band. The default is 6-APR-2014.
Mode - Select the mode to either validate only or to validate and commit to the database.
Oracle HRMS enables you to process and report foreign tax. Employers can give foreign tax credit relief (FTCR) through the payroll where there is a foreign tax withholding obligation as well as PAYE due on the same income for employees. The Statement of Earnings (SOE), payslip, and FPS report the foreign tax. On submitting FPS, the value of PAYE reported reflects the amount actually deducted against UK PAYE, the amount of PAYE reduced by the amount of FTCR. This relates both to 'This Payment' and 'Year To Date' values. As FTCR is already deducted while computing PAYE deduction in PAYE formula, the PAYE balance reported on the FPS and other reports relate to net PAYE. The application adds foreign tax to Deductions from Net Pay on the FPS.
To set up net of foreign tax reporting for RTI
Link Foreign Tax element to the required payrolls or all payrolls.
Attach an element entry for this element.
Enter the foreign tax amount against the Amount input value for this element.
Oracle HRMS enables you to run three RTI reconciliation reports to aid reconciliation and audit the data to be sent to HMRC. These reports are:
RTI FPS Run Reconciliation Report – you can run this report as required for an FPS. Additionally, the FPS process run spawns this report automatically.
RTI Year to Date Reconciliation Report – you can run this report as required, especially after EYU/P60 for a tax year to reconcile all the values reported. It reports the entire population within the PAYE Reference specified.
RTI Year to Date Reconciliation Report (Discrepancies) - This report identifies records with discrepancies, as opposed to RTI Year to Date Reconciliation Report which would report.
To run RTI FPS Run Reconciliation report
Select RTI FPS Run Reconciliation Report in the Name field.
Enter the FPS Archive Request ID.
To run RTI Year to Date Reconciliation report
Select RTI Year to Date Reconciliation Report in the name field.
Enter the following parameters:
Employer PAYE Reference - Select from the list of all the PAYE references within the organization. This is a mandatory field.
Effective Date - The date entered here determines the timeframe for which the YTD values are to be reported. For example if 05-April 2013 is supplied, then this process reports all the balances up to that point. This is a mandatory field.
Run Mode – Select from the following:
Payroll vs Last FPS - Reports all employees that have FPS runs, compares the reported values reported with the payroll values, and reports discrepancies.
Payroll vs FPS + EYU Amendments - Reports all employees that have EYU runs, compares the reported FPS and EYU values with the payroll values, and reports discrepancies. This option gets enabled when the effective date parameter specified relates to the tax year 2018-19 or previous tax years.
Payroll vs Amended FPS - Reports all employees that have amended FPS runs, compares the amended FPS values with payroll values, and reports discrepancies. This option gets enabled when the effective date parameter specified relates to tax year 2019-20 or future tax years.
Payroll vs P60 - Reports all employees that have a P60 run, matching the specified P60 request ID, compares the reported P60 values with payroll values, and reports discrepancies. If you select this option, then the P60 Request ID parameter gets enabled. Based on the effective date set, this parameter is populated for that relevant tax year.
Compare All - Reports all employees that have reported values for a payroll run, an FPS run, an EYU amendment, an FPS amendment or a P60 run
P60 Request ID – this field is enabled when the mode is Compare All or Compare vs P60.
Number of Threads - Specify the number of threads that this process must take into account. Based on the number of threads specified, the report runs in multi threaded mode.
Assignment Set - Optionally, select an Assignment Set.
The Reconciliation Report displays all relevant information on employees/assignments extracted onto the XML file and this report is similar to the one from P14 EOY extract. This report displays the relevant YTD balance values as follows:
If the Run Mode is set to: Compare Payroll vs Last FPS, then it reports all the employees that have a FPS run. It compares the FPS values reported with payroll values and reports discrepancies, if any.
If the Run Mode is set to: Compare Payroll vs FPS + EYU Amendments, then it reports all the employees that have a EYU run. It compares the FPS and EYU values reported with payroll values and reports discrepancies, if any.
If the Run Mode is set to: Compare Payroll vs P60, then it reports all the employees that have a P60 run, specified by the P60 request ID. It compares the P60 values reported with payroll values and reports discrepancies, if any.
If the Run Mode is set to: Compare All, then it reports all the employees that have payments, reporting figures for payroll run, FPS run, EYU Amendments, P60 run, specified by the P60 request id parameter. It compares these values reported with payroll values and reports discrepancies, if any.
To run RTI Year to Date Reconciliation Report (Discrepancies)
Select RTI Year to Date Reconciliation Report (Discrepancies) in the Name field.
Enter the following parameters, which are same as those of the RTI Year to Date Reconciliation Report:
Employer PAYE Reference
Effective Date
Run Mode
P60 Request ID
All employers are required to send information to HMRC using the real time information (RTI) system. Certain message types have a version that is specific to a single tax year, so each year new versions of certain reports are required.
Employer Payment Summary
Full Payment Submission
Earlier Year Updates
EYU Run Reconciliation Report
Additional Full Payment Submission
Oracle HRMS enables you to start sending Full Payment Submissions (FPS) after you have submitted the 'live' EAS and HMRC has accepted it. You can send it as follows:
First FPS to follow immediately after a live EAS is accepted. This is a one-time FPS that includes all the payment details for the employees paid that period as well as the year to date values of all the employee records sent on the EAS that are not actually processed through the payroll – for example, leavers in the tax year. As these employees may never get processed through payroll again, you can submit their information to HMRC for them to update the YTD figures for these employees. Each group of employees who have had an EAS sent to HMRC must also go through the submission of the "First FPS." You must set the "First FPS" parameter to Yes when running the FPS process.
You can send subsequent FPS on or before any payment is made to employees every time. The FPS covers all employees who have had a payment through the payroll process regardless of the method of payment (BACS, cheque). The period values as well as year to date figures are present on this FPS for all these employees. You must set the "First FPS" parameter to No, while running the subsequent FPS process for any group of employees.
HMRC uses the information submitted on FPS to update their records for the employees on an ongoing basis ensuring that the data they hold is as accurate as possible. If there are no payments made to any employee in any one period, then an FPS is not required, however, you must submit an Employer Payments Summary (EPS) with 'no payment made' indicator for such periods. In order to produce the Full Payment Summary, you must complete your payroll cycle (payroll run) for each group of employees and also the Pre-Payment process. Once these two processes are completed, you can initiate the FPS process. This process archives the data required for reporting on the FPS XML file.
Scenarios for Reporting Dates
The following table shows the results when you enter different combinations of reporting dates in the RTI - Full Payment Submission - (FPS) Request:
Scenario | Reporting Date | Reporting End Date | Result |
---|---|---|---|
Scenario 1 | No value | No value | In this scenario, the program reports no late leavers, only the normal employees who got paid in the current prepayment. |
Scenario 2 | Any date | No value | In this scenario, the program reports all the late leavers from the Reporting Date until the current FPS run date along with the Normal FPS employees. |
Scenario 3 | Any date | Any date | In this scenario, the program reports all the late leavers from the Reporting Date until the Reporting End Date along with the Normal FPS employees. |
HASH Generation
In the FPS assignment/employee record being extracted, a field called BACS HASH is required if the payment is made by BACS. This field is a generated value from an algorithm that has been stipulated for use by HMRC for RTI. The FPS process uses the following rules as to when and how the HASH value is generated: This field is generated using a Random number (on the BACS file) plus the Payment details of BACS Payment being reported in the FPS for the assignment/employee.
If there are multiple BACS payments for the same employee (payments are split between two or more employee bank accounts), then the HASH is on the largest of the BACS amounts.
If there are multiple payment types for the same employee (BACS & Cash / cheque) then the HASH is generated using only the BACS amount.
If there is a combination of multiple BACS and other payment methods (2 BACS payments, 1 Cheque and 1 Cash payment) then the HASH is generated using the highest BACS amount and the other amounts are included.
If there are no BACS payments (Cash or cheque or other non-BACS payment methods) then there no HASH is generated as there is no need for it.
Use the Submit Request window to select the version of the Full Payment Submission Process (FPS) that corresponds to the desired tax year.
This process reports both the normal FPS employees along with the additional FPS late leavers. The summary output also combines both set of employees (normal FPS employees and late leavers).
Note: The FPS process for in-year submissions is no longer valid for tax years 2019/20 and 2020/21, hence the RTI Full Payment Submission Process (FPS) 2019/20 and 2020/21 concurrent program are disabled.
To run the RTI - Full Payment Submission Process (FPS) 2021/22
Navigate to the Submit Request window.
In the Name field, select the RTI - Full Payment Submission Process (FPS) 2021/22.
Enter the following data.
Note: The following table describes the main parameters for the RTI - Full Payment Submission - (FPS) Request process. Due to changing legislative requirements, the parameters listed for your process may vary depending on the tax year.
Parameter | Description |
---|---|
PAYE Reference | Select from the PAYE references available in the application. This is a mandatory field. |
First FPS | Select Yes if this is the first FPS being sent in place of an EAS (this is determined by HMRC). Always submit for each group of employees in the EAS. The default value of this field is No. Entering data in this field is optional. |
First FPS Effective Date | Select the date for which the First FPS is being sent. This is mandatory if the First FPS parameter is Yes. The process uses this to determine the first pre-payment to be listed in the list of values for the Pre-Payment Request ID parameter and to filter pre-payments that were processed prior to migration to RTI. Ensure that this date is the date of RTI migration. |
Payroll | Select from the available payrolls in the PAYE. This is a mandatory field. |
Pre-Payment Request ID | Select a value from the Pre-Payment Request ID list for the PAYE you selected. The list of values shows the earliest pre-payment run that has not yet had an FPS run. The list of values ensures that the values being reported in FPS runs, where there are multiple pre-payments present, are correct for YTD and "this payment" values. This is a mandatory field.
Note: Ensure that each pre-payment has an FPS run separately regardless of BACS being run for multiple pre-payments. It is imperative the FPSs are run in sequence to ensure that the values being reported for "this payment" and year-to-date equal the employees' payments being made by BACS. For a normal FPS, the list of values of pre-payment IDs displays only those pre-payments that have not had an FPS since. |
Reporting Date | Optionally, enter a date within the tax year for which the FPS is being submitted. This date represents the retrospective or current period start date from which the late leavers will be considered for processing. |
Reporting End Date | Optionally, enter the end date until which date the late leavers will be processed. |
FPS Payment Date | Optionally, enter the FPS Payment Date. If you specify a payment date, then the application reports this date as the payment date for all employees processed within the FPS. |
Final Submission | Optionally, select from the following values:
When you select Yes, optional parameters are enabled. |
Date Scheme Ceased | Enter the date on which the date scheme ceased using the date format DD-MON-RRRR. For example, 10-JUL-2015. This is a mandatory parameter if you selected Yes - Final as the option for Ceased PAYE. |
Include Address Details | Select the option for reporting address details to HMRC:
This is a mandatory field. |
Gateway Test Indicator | This is a mandatory field, containing a list of values with the default set to Live. The other values in the list of values are Test, Test In Live (Live Submission), and Test In Live (Test Submission). The options Live and Test in Live (Live Submission) are available only to end users, whereas the options Test, and Test in Live (Test Submission) are available only to software vendors. |
XML Storage Type | This field is optional and contains a list of values with the default set to File System and Database. The other value in the list is Secure Database. |
Late PAYE Reporting Reason | Select one of the following reasons:
|
Debug Mode | Optionally, select whether to set the debug mode for troubleshooting. The default value is No. The other value is Yes. The Debug Mode is enabled if the Gateway Test Indicator is set to Test, Test in Live (Live Submission), or Test in Live (Test Submission). |
Person Name | Enables you to select all the person names that are processed in the selected PAYE Reference. This field is enabled only if the Debug Mode parameter is set to Yes. This is an optional parameter. |
Compress File | This is an optional parameter containing a list of values with the default set to Yes. The other value is No. |
File Split Factor (in MB) | This is an optional parameter with the default value set to 20. |
XML File Name | This is an optional parameter, which is blank by default. |
To roll back the RTI - Full Payment Submission Process
If you need to re-run the RTI - Full Payment Submission Process, first run the GB Rollback program to reset the existing values. This process ensures that newly-added values are included when the full payment submission is rerun. For more information, see Running the GB Rollback Program.
The RTI - Full Payment Submission (FPS) Amendments process, enables you to use the RTI Full Payment Submission to report revised year-to-date (YTD) payment data after 19 April, following the end of the tax year.
Use the Submit Request window to run the RTI - Full Payment Submission Process (FPS) - Amendments 2020/21 process.
To run the RTI - Full Payment Submission Process (FPS) - Amendments 2020/21
Navigate to the Submit Request window.
In the Name field, select the RTI - Full Payment Submission Process (FPS) - Amendments 2020/21.
Enter the following data:
Parameter | Description |
---|---|
PAYE Reference | Select from the PAYE references available in the application. This is a mandatory field. |
Gateway Test Indicator | This is a mandatory field, containing a list of values with the default set to Live. The other values in the list of values are Test, Test In Live (Live Submission), and Test In Live (Test Submission). The options Live and Test in Live (Live Submission) are available only to end users, whereas the options Test, and Test in Live (Test Submission) are available only to software vendors. |
XML Storage Type | This field is optional and contains a list of values with the default set to File System and Database. The other value in the list is Secure Database. |
Assignment Set | Optionally, select an Assignment Set. |
Debug Mode | Select whether to set the debug mode for troubleshooting. The default value is No. The other value is Yes. The Debug Mode is enabled if the Gateway Test Indicator is set to Test, Test in Live (Live Submission), or Test in Live (Test Submission). |
Person Name | Enables you to select all the person names that are processed in the selected PAYE Reference. This field is enabled only if the Debug Mode parameter is set to Yes. |
Compress File | This is an optional parameter containing a list of values with the default set to Yes. The other value is No. |
File Split Factor (in MB) | This is an optional parameter with the default value set to 20. |
XML File Name | This is an optional parameter, which is blank by default. |
RTI - Full Payment Submission Process (FPS) 2020/21 - XML Output
After you submit the RTI Full Payment Submission (FPS) Amendments 2020/21) concurrent program, the application runs the RTI - Full Payment Submission Process (FPS) 2020/21 - XML Output program. This program, in turn, automatically runs the following concurrent programs:
GB IRMark Generator
Payroll File Reporter
The application performs the required business validations during XML generation. To view the generated XML report in the browser, click View Output corresponding to the Payroll File Reporter run.
RTI FPS Amendments Run Reconciliation Report
After you submit the RTI Full Payment Submission (FPS) - Amendments 2020/21 concurrent program, the application runs the RTI FPS Amendments Run Reconciliation report. The reconciliation report displays all of the employee and assignment information that was extracted into the XML file.
To run the RTI - Full Payment Submission Process (FPS) - Amendments 2019/20
Navigate to the Submit Request window.
In the Name field, select the RTI - Full Payment Submission Process (FPS) - Amendments 2019/20.
Enter the following data:
Parameter | Description |
---|---|
PAYE Reference | Select from the PAYE references available in the application. This is a mandatory field. |
Gateway Test Indicator | This is a mandatory field, containing a list of values with the default set to Live. The other values in the list of values are Test, Test In Live (Live Submission), and Test In Live (Test Submission). The options Live and Test in Live (Live Submission) are available only to end users, whereas the options Test, and Test in Live (Test Submission) are available only to software vendors. |
XML Storage Type | This field is optional and contains a list of values with the default set to File System and Database. The other value in the list is Secure Database. |
Assignment Set | Optionally, select an Assignment Set. |
Debug Mode | Select whether to set the debug mode for troubleshooting. The default value is No. The other value is Yes. The Debug Mode is enabled if the Gateway Test Indicator is set to Test, Test in Live (Live Submission), or Test in Live (Test Submission). |
Person Name | Enables you to select all the person names that are processed in the selected PAYE Reference. This field is enabled only if the Debug Mode parameter is set to Yes. |
Compress File | This is an optional parameter containing a list of values with the default set to Yes. The other value is No. |
File Split Factor (in MB) | This is an optional parameter with the default value set to 20. |
XML File Name | This is an optional parameter, which is blank by default. |
RTI - Full Payment Submission Process (FPS) 2019/20 - XML Output
After you submit the RTI Full Payment Submission (FPS) Amendments 2019/20) concurrent program, the application runs the RTI - Full Payment Submission Process (FPS) 2019/20 - XML Output program. This program, in turn, automatically runs the following concurrent programs:
GB IRMark Generator
Payroll File Reporter
The application performs the required business validations during XML generation. To view the generated XML report in the browser, click View Output corresponding to the Payroll File Reporter run.
RTI FPS Amendments Run Reconciliation Report
After you submit the RTI Full Payment Submission (FPS) - Amendments 2019/20 concurrent program, the application runs the RTI FPS Amendments Run Reconciliation report. The reconciliation report displays all of the employee and assignment information that was extracted into the XML file.
Use the RTI- Full Payment Submission (FPS) - Additional Reporting request for the following scenarios:
To report late leavers, having no payments after termination.
Moving employees from one PAYE Reference to another; for example, for mergers and demergers where PAYE schemes are restructured. HMRC recommends that each assignment/person requires a leaver and starter update sent using FPS through RTI because HMRC considers this a change of employment.
To report starter and leaver records when the Employer PAYE Reference is changed at the end of the tax year at the Payroll Definition level. The leaver record would be generated against the old Employer PAYE Reference and the starter record would be generated against the new Employer PAYE Reference.
To run the RTI- Full Payment Submission (FPS) - Additional Reporting Request
Use this process to report all the employees who are transferred from one employer PAYE Reference to another and to report late leavers who have no payments after termination.
Navigate to the Submit Request window.
In the Name field, select RTI – Full Payment Submission (FPS) Additional Reporting 2021/22.
Enter the following parameters:
Parameter | Description |
---|---|
Submission Mode | Select a Submission Mode from the list. You can choose from:
Note: In the new tax year, you must submit the FPS with submission mode 'FPS with Starter Details' before submitting any normal FPS program.
This is a mandatory parameter. |
PAYE Reference | Select from the list of PAYE references in the organization. This is a mandatory parameter. |
Payroll | Optionally, specify the applicable payroll. The application disables this field if the submission mode is either FPS with Leaver Details or FPS with Starter Details. |
Reporting Date | The application defaults the date to 05-APR-YYYY when the submission mode is set to FPS with Leaver Details. It defaults the date to 06-APR-YYYY when the submission mode is set to FPS with Starter Details. This is an optional parameter. |
Gateway Test Indicator | This is a mandatory parameter containing a list of values, with a default value of Live. The other values in the list of values are Test, Test In Live (Live Submission), and Test In Live (Test Submission). Note that software vendors can only use the Test and Test in Live (Test Submission) values, whereas end-users can use only the Live and Test in Live (Live Submission) values. |
Debug Mode | This is an optional parameter, and you can choose between Yes and No. No is the default parameter. This parameter is enabled if the Gateway Test Indicator parameter is set to Test, Test in Live (Live Submission), or Test in Live (Test Submission). |
Person Name | This is an optional parameter containing a list of values with names of all persons processed in the selected prepayment. The Person Name parameter is enabled if the Debug Mode parameter is set to Yes. |
Compress File | This is an optional parameter containing a list of values, with a default value of Yes. The other value in the list of values is No. |
XML Storage Type | This is an optional parameter containing a list of values, with the default set to File System and Database. The other value in the list of values is Secure Database. |
Late PAYE Reporting Reason | Optionally, select one of the following reasons for late reporting:
|
File Split Factor (in MB) | File Split Factor (in MB) is an optional parameter, with the default value 20. This parameter is applicable only when the Submission Mode is XML. |
XML File Name | XML File Name is an optional parameter, which is blank by default. |
To run the RTI- Full Payment Submission (FPS) - Additional Reporting Request
Use this process to report all the employees who are transferred from one employer PAYE Reference to another and to report late leavers who have no payments after termination.
Navigate to the Submit Request window.
In the Name field, select RTI – Full Payment Submission (FPS) Additional Reporting 2020/21.
Enter the following parameters:
Parameter | Description |
---|---|
Submission Mode | Select a Submission Mode from the list. You can choose from:
Note: In the new tax year, you must submit the FPS with submission mode 'FPS with Starter Details' before submitting any normal FPS program.
This is a mandatory parameter. |
PAYE Reference | Select from the list of PAYE references in the organization. This is a mandatory parameter. |
Payroll | Optionally, specify the applicable payroll. The application disables this field if the submission mode is either FPS with Leaver Details or FPS with Starter Details. |
Reporting Date | The application defaults the date to 05-APR-YYYY when the submission mode is set to FPS with Leaver Details. It defaults the date to 06-APR-YYYY when the submission mode is set to FPS with Starter Details. This is an optional parameter. |
Gateway Test Indicator | This is a mandatory parameter containing a list of values, with a default value of Live. The other values in the list of values are Test, Test In Live (Live Submission), and Test In Live (Test Submission). Note that software vendors can only use the Test and Test in Live (Test Submission) values, whereas end-users can use only the Live and Test in Live (Live Submission) values. |
Debug Mode | This is an optional parameter, and you can choose between Yes and No. No is the default parameter. This parameter is enabled if the Gateway Test Indicator parameter is set to Test, Test in Live (Live Submission), or Test in Live (Test Submission). |
Person Name | This is an optional field containing a list of values with names of all persons processed in the selected prepayment. The Person Name parameter is enabled if the Debug Mode parameter is set to Yes. |
Compress File | This is an optional parameter containing a list of values, with a default value of Yes. The other value in the list of values is No. |
XML Storage Type | This is an optional parameter containing a list of values, with the default set to File System and Database. The other value in the list of values is Secure Database. |
Late PAYE Reporting Reason | Optionally, select one of the following reasons for late reporting:
|
File Split Factor (in MB) | File Split Factor (in MB) is an optional parameter, with the default value 20. This parameter is applicable only when the Submission Mode is XML. |
XML File Name | XML File Name is an optional parameter, which is blank by default. |
To run the RTI- Full Payment Submission (FPS) - Additional Reporting Request
Use this process to report all the employees who are transferred from one employer PAYE Reference to another and to report late leavers who have no payments after termination.
Navigate to the Submit Request window.
In the Name field, select RTI – Full Payment Submission (FPS) Additional Reporting 2019/20.
Enter the following parameters:
Parameter | Description |
---|---|
Submission Mode | Select the submission mode:
Note: In the new tax year, you must submit the FPS with submission mode 'FPS with Starter Details' before submitting any normal FPS program.
|
PAYE Reference | Select from the list of PAYE references in the organization. |
Payroll | Specify the applicable payroll. The application disables this field if the submission mode is either FPS with Leaver Details or FPS with Starter Details. |
Reporting Date | The application defaults the date to 05-APR-YYYY when the submission mode is set to FPS with Leaver Details. It defaults the date to 06-APR-YYYY when the submission mode is set to FPS with Starter Details. |
Gateway Test Indicator | This is a mandatory parameter containing a list of values, with a default value of Live. The other values in the list of values are Test, Test In Live (Live Submission), and Test In Live (Test Submission). Note that software vendors can only use the Test and Test in Live (Test Submission) values, whereas end-users can use only the Live and Test in Live (Live Submission) values. |
XML Storage Type | This is an optional parameter containing a list of values, with the default set to File System and Database. The other value in the list of values is Secure Database. |
Late PAYE Reporting Reason | Select one of the following reasons for late reporting:
|
Compress File | This is an optional parameter containing a list of values, with a default value of Yes. The other value in the list of values is No. |
File Split Factor (in MB) | File Split Factor (in MB) is an optional parameter, with the default value 20. This parameter is applicable only when the Submission Mode is XML. |
XML File Name | XML File Name is an optional parameter, which is blank by default. |
Run the GB Rollback program to roll back (reset) a process. For example, if you want to rerun the RTI - Earlier Year Update Process, first run the GB Rollback program to reset the values. This enables newly-added values to be included when the update process is rerun.
You can roll back the following processes:
Full Payment Submission
Full Payment Submission - Amendments
Additional Full Payment Submission
P11D
RTI - Earlier Year Update Process (EYU)
P46(Car) Archive Process
To run the GB Rollback program
In the Name field, select GB Rollback.
Enter the following parameters:
Year - enter the year for which you want to roll back the process. This is a mandatory parameter.
Process Type - Select the Process Type to be rolled back, such as a balance adjustment or estimate costing. This is a mandatory parameter.
Payroll Process - select the required payroll process ID to roll back. This is a mandatory parameter.
Assignment Set - optionally, select an Assignment Set.
XML File Name - optionally, select the XML File Name.
Click OK, and Submit the process.
On receiving the FPS, HMRC calculates the employer liability (PAYE and NI) which is the amount they expect the employer to make for that period for the PAYE scheme. However, when there are any adjustments or reimbursements, for example, statutory payments recovery and the NIC compensation on the recovery amounts that reduce the expected liability, then you need to submit the Employer Payment Summary (EPS) for each period as necessary. The EPS contains the statutory payment recovery values (92% of SMP, ASPP,SAP,) and the NIC compensation on these recovery amounts. It also allows declarations to be made and if there are any amounts claimed for NIC holiday, CIS deductions suffered, or if there was an advance from HMRC to be reported. You send this record after processing all payrolls within the PAYE scheme and after submitting their FPS because this is relevant to the whole PAYE scheme. Oracle HRMS enables you to submit multiple EPS on the same effective date. Submit multiple EPS, after any Earlier Year Update (EYU) submissions, to report changes to a previous tax year that affect statutory payments such as SSP, SMP, and ASPP.
Complete the following steps before you run the EPS process.
Enter the information on Statutory Payments Recovery rates in the Tax Details Reference organization EIT.
Call the GB_EPS_GET_REC_AND_NIC predefined formula function (FF) from the SMP/SAP/ASPP and OSPP element formula. Pass Amount input value as a parameter. The seeded fast formula passes the Recovery and NIC Compensation computed values to the out parameters specified on the user formulae. Return these values to the appropriate predefined indirect elements for Recovery and NIC Compensation using the Formula Results functionality. For example, you must return the computed SMP Recovery amount to "SMP Recovery" element's Pay Value and return the computed SMP NIC Compensation to "SMP NIC Compensation" element's Pay Value. These indirect elements in turn feed the seeded balances which are reported after you run the RTI Create EPS Payment Values 2013/14.
If you are doing internet submission and if you select the 'Database' option for the XML Storage Type parameter, then create the following for usage by the EPS process:
Create the PAY_GB_RTI_SUBMISSION_ENCR table in the encrypted tablespace using the following script:
CREATE TABLE (schema_name)."PAY_GB_RTI_SUBMISSION_ENCR" ("SUBMISSION_ID" NUMBER NOT NULL ENABLE, "BUSINESS_GROUP_ID" NUMBER(22,0), "SUBMISSION_STATUS" VARCHAR2(1), "CONC_REQUEST_ID" NUMBER(22,0), "PAYROLL_ACTION_ID" NUMBER(22,0), "REPORT_TYPE" VARCHAR2(100), "XML_DATA" CLOB, "EFFECTIVE_DATE" DATE, "MESSAGE_TYPE" VARCHAR2(1), "GENERATION_DATE" DATE, "CREATED_BY" NUMBER(22,0), "CREATION_DATE" DATE, "LAST_UPDATED_BY" NUMBER(22,0), "LAST_UPDATE_DATE" DATE, "LAST_UPDATE_LOGIN" NUMBER(22,0), "OBJECT_VERSION_NUMBER" NUMBER ) ;
Create the synonym using the following script:
CREATE OR REPLACE SYNONYM (schema_name)."PAY_GB_RTI_SUBMISSION_ENCR" FOR (schema_name)."PAY_GB_RTI_SUBMISSION_ENCR"
Create the sequence using the following script:
CREATE SEQUENCE (schema_name)."PAY_GB_RTI_SUBMISSION_ENCR_S" MINVALUE 1 MAXVALUE 9999999999999 INCREMENT BY 1 START WITH 1 CACHE 20 NOORDER NOCYCLE ;
Create the trigger to ensure that the who columns are populated in the table PAY_GB_RTI_SUBMISSION_ENCR appropriately.
Grant the required privileges to APPS user.
Note: If you have specified the value as 'Database' for the XML Storage Type parameter, but have not created the required table, then the application displays an error message. You do not require the above mentioned steps if you are running the Electronic Data Interchange submissions.
Run the Create EPS Payment Values process.
Upon successful completion of the creation process, log into self service, and bring up the EPS Self Service page.
Make any changes and additions to the amounts displayed on the page for the PAYE reference and save the record.
Submit the EPS for approval (internal workflow task to be created).
Note: If you do not want the Approval process to occur for the Employer Payment Summary submission, then set the RTI - Employer Payment Summary Approval process required profile option to No. When the value is No, the EPS process bypasses the process of setting the EPS record status to completed and no approver interaction is required. When you submit the record, the application sets it to verified directly. See: User Profiles, Oracle HRMS Configuring, Reporting, and System Administration Guide.
Approver then needs to submit the page which is picked up by the EPS XML process.
Once the information to be sent for the period has been submitted, you can submit the EPS XML process which creates the file for submission to HMRC.
Use the EPS Self Service page to view, update, and submit the Employer Payment Summary record created by the Create EPS Payment Values process. You can grant applicable personnel in your organization to access this page and complete the required tasks.
Navigate to the EPS page using Other Definitions > Real Time Information > Employer Payment Summary. You can perform the following actions:
Search EPS records
In this page you can search and retrieve the relevant PAYE Employer Payment Summary records. In the Search results section, you can select View icon to view the employer payment submission record. The record displays all the values that have been recorded on it by the Create EPS Payment Values process and any user inputs. This is a read-only page that displays information on all the values for the EPS record chosen. The Summary of Payments shown are the calculated values from the process (first column of figures) as well as the values that are editable by the user (second column of figures) that you can use to override the calculated values. The XML file for EPS takes the values shown on the second column.
Update EPS records
To update the values in the second column in the EPS record page, click Update for the applicable record in the Search Results section. The Update – Employer Payment Summary Record page has the following three sections:
Employer PAYE Reference Details: Where the RTI information of the PAYE reference is displayed. All the information on RTI for the entered on the Tax Reference Details organization EIT is displayed here. The statutory reimbursement information shown is that used by the Create EPS Payment Values process. The items displayed are read-only and you cannot update here. The only field that you can update is the Approver Name.
Employer Checklist Declaration: You can enter or update all the declaration information for submitting to HMRC (as necessary). This is similar to the P35 declaration information that is currently required by HMRC at the end of the year.
Summary of Payments: Here you can make all the necessary amendments to the fields shown prior to submitting the EPS record for approval and subsequent submission to HMRC. The summary of payments section displays the actual value calculated from the EPS process. You can overwrite these figures as required by entering the replacement value in the enterable area for each item.
You can choose to either:
Save – This saves the record with a confirmation notification. The status does not change for the record but fields that have been changed are updated.
Submit - This sends the record for approval with a confirmation notification. This action changes the status of the EPS record to 'Completed'. After this status change, you cannot update the record if you have created it. Only the approver can update the record once the status has been set to 'completed'. The application sends a notification to the user set up as the approver so that the record can be checked by them and verified that the record is ready to be picked up by the EPS process.
Cancel – takes you back to the Search page.
Update by approver
When the Approver gets a notification, they can go through the same functional flow to 'Update' or 'Approve' the record. This is same as Update Page for the creator of the EPS, except it is only available to the designated approver. In the Update – Employer Payment Summary Record (for approver) page, click the Verify button to change the EPS record status to 'Verified'. The EPS XML process picks up all 'verified' EPS records for the PAYE scheme and creates the file for submission to HMRC.
Delete EPS records
Click the Delete icon in the Search Results section for the applicable EPS record. Use the Delete button on the Delete – Employer Payment Summary Record page to delete the EPS record. The application displays a confirmation message.
This process extracts all balances for a period for the required PAYE scheme and makes the balances available on the EPS record page. For the given PAYE reference, this process calculates the sum of all statutory balances for all the assignments in the PAYE reference. It uses the parameters set in the Tax Reference Details organization EIT to calculate the statutory recovery values together with the NIC compensation values. Use this process for the tax year 2017/18.
Note: Due to changing legislative requirements, the parameters may vary depending on the tax year of the report selected.
To run the RTI - Create EPS Payment Values 2021/22 process
Navigate to the Submit Request window.
In the Name field, select RTI – Create EPS Payment Values 2020/21.
Enter the following data:
Field | Description |
---|---|
PAYE Reference | Select from the list of all the PAYE references within the organization. This is a mandatory parameter. |
Effective Date | Enter the tax period end date in the format DD-MON-YYYY for the relevant tax period. This is a mandatory parameter. |
Final Submission | This is an optional parameter, containing a list of values, with default value set to No. Other values areYes - Final for Ceased PAYE Ref, and Yes - Final for the Year. |
No of Threads | Specify the number of threads that this process must take into account. This is a mandatory parameter and the default value is 3. |
Submit Bank Details for Refund | Optionally, select whether to submit bank details for refund. The default is No. |
Select Bank Details for Refund | If you selected Yes in the Submit Bank Details for Refund field, then the application enables this parameter, and enables you to select a payment method from the list of all the organization payment methods defined in the business group. This is an optional parameter. |
Claim Employment Allowance | Select whether you are claiming an employment allowance (Yes or No). The field is blank by default. |
This report generates the following output:
SMP/SAP/SPP/ShPP/SPBP Recovery Type
Recovery Percentage Used
SMP Amount Recovered
SAP Amount Recovered
SPP Amount Recovered
ShPP Amount Recovered
SPBP Amount Recovered YTD
NIC Compensation on SMP
NIC Compensation on SAP
NIC Compensation on SPP
NIC Compensation on ShPP
NIC Compensation on SPBP YTD
Apprenticeship Levy YTD
Annual Apprenticeship Levy allowance
To run the RTI - Create EPS Payment Values 2020/21 process
Navigate to the Submit Request window.
In the Name field, select RTI – Create EPS Payment Values 2020/21.
Enter the following data:
Field | Description |
---|---|
PAYE Reference | Select from the list of all the PAYE references within the organization. This is a mandatory parameter. |
Effective Date | Enter the tax period end date in the format DD-MON-YYYY for the relevant tax period. This is a mandatory parameter. |
Final Submission | This is an optional parameter, containing a list of values, with default value set to No. Other values areYes - Final for Ceased PAYE Ref, and Yes - Final for the Year. |
No of Threads | Specify the number of threads that this process must take into account. This is a mandatory parameter and the default value is 3. |
Submit Bank Details for Refund | Optionally, select whether to submit bank details for refund. The default is No. |
Select Bank Details for Refund | If you selected Yes in the Submit Bank Details for Refund field, then the application enables this parameter, and enables you to select a payment method from the list of all the organization payment methods defined in the business group. This is an optional parameter. |
Claim Employment Allowance | Select whether you are claiming an employment allowance (Yes or No). The field is blank by default. |
This report generates the following output:
SMP/SAP/SPP/ShPP/SPBP Recovery Type
Recovery Percentage Used
SMP Amount Recovered
SAP Amount Recovered
SPP Amount Recovered
ShPP Amount Recovered
NIC Compensation on SMP
NIC Compensation on SAP
NIC Compensation on SPP
NIC Compensation on ShPP
Apprenticeship Levy YTD
Annual Apprenticeship Levy allowance
To run the RTI - Create EPS Payment Values 2019/20 process
Navigate to the Submit Request window.
In the Name field, select RTI – Create EPS Payment Values 2018/19.
Enter the following data:
Field | Description |
---|---|
PAYE Reference | Select from the list of all the PAYE references within the organization. This is a mandatory parameter. |
Effective Date | Enter the tax period end date in the format DD-MON-YYYY for the relevant tax period. This is a mandatory parameter. |
Final Submission | This is an optional parameter, containing a list of values, with default value set to No. Other values areYes - Final for Ceased PAYE Ref, and Yes - Final for the Year. |
No of Threads | Specify the number of threads that this process must take into account. This is a mandatory parameter and the default value is 3. |
Submit Bank Details for Refund | Optionally, select whether to submit bank details for refund. The default is No. |
Select Bank Details for Refund | If you selected Yes in the Submit Bank Details for Refund field, then the application enables this parameter, and enables you to select a payment method from the list of all the organization payment methods defined in the business group. This is an optional parameter. |
Claim Employment Allowance | Select whether you are claiming an employment allowance (Yes or No). The field is blank by default. |
To run the RTI - Create EPS Payment Values 2018/19 process
Navigate to the Submit Request window.
In the Name field, select RTI – Create EPS Payment Values 2018/19.
Enter the following data:
Field | Description |
---|---|
PAYE Reference | Select from the list of all the PAYE references within the organization. This is a mandatory parameter. |
Effective Date | Enter the tax period end date in the format DD-MON-YYYY for the relevant tax period. This is a mandatory parameter. |
Final Submission | This is an optional parameter, containing a list of values, with default value set to No. Other values areYes - Final for Ceased PAYE Ref, and Yes - Final for the Year. |
No of Threads | Specify the number of threads that this process must take into account. This is a mandatory parameter and the default value is 3. |
Submit Bank Details for Refund | Optionally, select whether to submit bank details for refund. The default is No. |
Select Bank Details for Refund | If you selected Yes in the Submit Bank Details for Refund field, then the application enables this parameter, and enables you to select a payment method from the list of all the organization payment methods defined in the business group. This is an optional parameter. |
Claim Employment Allowance | Select whether you are claiming an employment allowance (Yes or No). The field is blank by default. |
To run the RTI - Create EPS Payment Values 2017/18 process
Navigate to the Submit Request window.
In the Name field, select RTI – Create EPS Payment Values 2017/18.
Enter the following data:
Field | Description |
---|---|
PAYE Reference | Select from the list of all the PAYE references within the organization. |
Effective Date | Enter the tax period end date in the format DD-MON-YYYY for the relevant tax period. |
Final Submission | Optionally, select Yes if you are creating final EPS payment values for ceased PAYE schemes or final values for the tax year. The default value is No. |
No of Threads | Specify the number of threads that this process must take into account. This is a mandatory parameter and the default value is 3. |
Submit Bank Details for Refund | Optionally, select whether to submit bank details for refund. The default is No. |
Select Bank Details for Refund | Optionally, if you selected Yes to submit bank details for refund, select a payment method (otherwise the field is disabled.) |
Claim Employment Allowance | Select whether you are claiming an employment allowance (Yes or No). The field is blank by default. |
Click OK and Submit the request.
This report generates the following output:
SMP/SAP/OSPP/ASPP Recovery Type
Recovery Percentage Used
Recovery Percentage Used
SMP Amount Recovered
SAP Amount Recovered
OSPP Amount Recovered
ASPP Amount Recovered
NIC Compensation on SMP
NIC Compensation on SAP
NIC Compensation on OSPP
NIC Compensation on ASPP
Apprenticeship Levy YTD
Apprenticeship Levy Month
To run the RTI - Create EPS Payment Values 2016/17 process
Use this process for the tax year 2016/17.
Navigate to the Submit Request window.
In Name field, select RTI – Create EPS Payment Values 2016/17.
Enter the parameters. (For field descriptions, see “RTI - Create EPS Payment Values 2017/18.”)
Click OK and then submit the request.
To run the RTI - Create EPS Payment Values 2014/15 process
Use this process for tax year 2014/15.
In the Name field, select RTI – Create EPS Payment Values 2014/15.
Apart from the parameters of the Create EPS Payment Values 2013/14 process, enter the following:
Select the applicable organization payment method defined within the business group. If you have selected Yes to providing bank details for refund, then the application enables the Select Bank Details for Refund field.
Indicate whether you are claiming employment allowance. The default value is No.
Note: Ensure that you run this process prior to querying the EPS record for the period using the self service user interface relating to the PAYE Scheme. This process reports the following details for 'Employer Payment Summary – Created':
SMP/SAP/OSPP/ASPP Recovery Type
Recovery Percentage Used
Recovery Percentage Used
SMP Amount Recovered
SAP Amount Recovered
OSPP Amount Recovered
ASPP Amount Recovered
NIC Compensation on SMP
NIC Compensation on SAP
NIC Compensation on OSPP
NIC Compensation on ASPP
Click OK and submit the request.
To run the RTI - Create EPS Payment Values 2013/14 process
Use this process for tax year 2013/14.
Select RTI – Create EPS Payment Values 2013/14 in the Name field.
Enter the following parameters:
PAYE Reference: Select from the list of all the PAYE references within the organization.
Effective Date: Enter the tax period end date as 05-MM-YYYY for the relevant tax period.
Final Submission: Optionally, select Yes if you are creating final EPS payment values for ceased PAYE schemes or final values for the tax year. Default value is No.
Click OK and submit the request.
To run the Create EPS Payment Values 2013/14 Multi Threaded process
Apart from the parameters of the Create EPS Payment Values 2013/14 process, enter the following:
Specify the number of threads that this process must take into account. This is a mandatory parameter and the default value is 3.
Click OK and submit the request.
To run the Create EPS Payment Values Pre 06 April 13 process
Use this process only for returns that relate to tax year 2012/13 even if the physical date for the tax year end (05-April) has passed.
Select RTI – Create EPS Payment Values Pre 06 April 13 in the Name field.
Enter the PAYE Reference and Effective Date parameters.
Next Step: Retrieve the EPS record for the tax period (using self-service application) for a PAYE scheme, make required adjustments, and you are ready to run the Employer Payment Summary process.
Click OK and submit the request.
To run the RTI - Employer Payment Summary Process (EPS) 2021/22:
Navigate to the Submit Request window.
In the Name field, select RTI - Employer Payment Summary Process (EPS) 2020/21 .
Enter the following data:
Parameter | Description |
---|---|
PAYE Reference | Select from the list of PAYE references in your organization. This is a mandatory parameter. |
Effective Date | Enter the tax period end date in the format DD-MON-YYYY for the relevant tax period. For example, if running a July monthly payroll EPS for payments at the end of the month (for example, 28 July), then the tax period is considered as period 05 running from 06-July to 05-Aug, and as such the date you enter is the end of the tax period in question (enter 05-Aug-YYYY). If running a weekly payroll and its dates span the tax period, then the EPS does not cover the values for this payroll as it falls into the next tax period. For example, a weekly payroll pay date of 07-Aug would be eligible for the next tax period from 06-Aug to 05-Sept. Therefore, the effective date entered of 05-Aug does not include the weekly pay run values. This is a mandatory parameter. |
Gateway Test Indicator | This is a mandatory parameter containing a list of values, with the default set to Live. Other options in the list of values are Test, Test in Live (Test Submission), and Test in Live (Live Submission). Note that software vendors can only use the Test and Test in Live (Test Submission) options, while end-users can use only the Live and Test in Live (Live Submission) options. |
XML Storage Type | This field is enabled only if the Submission Mode is XML. Select an XML Storage Type from the list:
This is an optional parameter. |
Click OK, and then Submit the request.
To run the RTI - Employer Payment Summary Process (EPS) 2020/21:
Navigate to the Submit Request window.
In the Name field, select RTI - Employer Payment Summary Process (EPS) 2020/21 .
Enter the following data:
Parameter | Description |
---|---|
PAYE Reference | Select from the list of PAYE references in your organization. This is a mandatory parameter. |
Effective Date | Enter the tax period end date in the format DD-MON-YYYY for the relevant tax period. For example, if running a July monthly payroll EPS for payments at the end of the month (for example, 28 July), then the tax period is considered as period 05 running from 06-July to 05-Aug, and as such the date you enter is the end of the tax period in question (enter 05-Aug-YYYY). If running a weekly payroll and its dates span the tax period, then the EPS does not cover the values for this payroll as it falls into the next tax period. For example, a weekly payroll pay date of 07-Aug would be eligible for the next tax period from 06-Aug to 05-Sept. Therefore, the effective date entered of 05-Aug does not include the weekly pay run values. This is a mandatory parameter. |
Gateway Test Indicator | This is a mandatory parameter containing a list of values, with the default set to Live. Other options in the list of values are Test, Test in Live (Test Submission), and Test in Live (Live Submission). Note that software vendors can only use the Test and Test in Live (Test Submission) options, while end-users can use only the Live and Test in Live (Live Submission) options. |
XML Storage Type | This field is enabled only if the Submission Mode is XML. Select an XML Storage Type from the list:
This is an optional parameter. |
Click OK, and then Submit the request.
To run the RTI - Employer Payment Summary Process (EPS) 2019/20:
Navigate to the Submit Request window.
In the Name field, select RTI - Employer Payment Summary Process (EPS) 2019/20 .
Enter the following data:
Parameter | Description |
---|---|
PAYE Reference | Select from the list of PAYE references in your organization. This is a mandatory parameter. |
Effective Date | Enter the tax period end date in the format DD-MON-YYYY for the relevant tax period. For example, if running a July monthly payroll EPS for payments at the end of the month (for example, 28 July), then the tax period is considered as period 05 running from 06-July to 05-Aug, and as such the date you enter is the end of the tax period in question (enter 05-Aug-YYYY). If running a weekly payroll and its dates span the tax period, then the EPS does not cover the values for this payroll as it falls into the next tax period. For example, a weekly payroll pay date of 07-Aug would be eligible for the next tax period from 06-Aug to 05-Sept. Therefore, the effective date entered of 05-Aug does not include the weekly pay run values. This is a mandatory parameter. |
Gateway Test Indicator | This is a mandatory parameter containing a list of values, with the default set to Live. Other options in the list of values are Test, Test in Live (Test Submission), and Test in Live (Live Submission). Note that software vendors can only use the Test and Test in Live (Test Submission) options, while end-users can use only the Live and Test in Live (Live Submission) options. |
XML Storage Type | This field is enabled only if the submission mode is XML. Select an XML storage type:
This is an optional parameter. |
Click OK, and then Submit the request.
To run the RTI - Employer Payment Summary Process (EPS) 2018/19:
Navigate to the Submit Request window.
In the Name field, select RTI - Employer Payment Summary Process (EPS) 2018/19 .
Enter ythe folloiwng data:
Parameter | Description |
---|---|
PAYE Reference | Select from the list of PAYE references in your organization. This is a mandatory parameter. |
Effective Date | Enter the tax period end date in the format DD-MON-YYYY for the relevant tax period. For example, if running a July monthly payroll EPS for payments at the end of the month (for example, 28 July), then the tax period is considered as period 05 running from 06-July to 05-Aug, and as such the date you enter is the end of the tax period in question (enter 05-Aug-YYYY). If running a weekly payroll and its dates span the tax period, then the EPS does not cover the values for this payroll as it falls into the next tax period. For example, a weekly payroll pay date of 07-Aug would be eligible for the next tax period from 06-Aug to 05-Sept. Therefore, the effective date entered of 05-Aug does not include the weekly pay run values. This is a mandatory parameter. |
Gateway Test Indicator | This is a mandatory parameter containing a list of values, with the default set to Live. Other options in the list of values are Test, Test in Live (Test Submission), and Test in Live (Live Submission). Note that software vendors can only use the Test and Test in Live (Test Submission) options, while end-users can use only the Live and Test in Live (Live Submission) options. |
XML Storage Type | This field is enabled only if the submission mode is XML. Select an XML storage type:
This is an optional parameter. |
Click OK, and then Submit the request.
To run the RTI - Employer Payment Summary Process (EPS) 2017/18
Use the Employer Payment Summary Process (EPS) 2018/19 for returns that relate to the tax year 2017/18.
Navigate to the Submit Request window.
In the Name field, select RTI - Employer Payment Summary Process (EPS) 2017/18 .
Enter the following data:
Note: Due to legislation changes and requirements, the parameters that appear on the RTI - Employer Payment Summary Process may differ depending on the tax year selected.
Parameter | Description |
---|---|
PAYE Reference | Select from the list of PAYE references in your organization. |
Effective Date | Enter the tax period end date in the format DD-MON-YYYY for the relevant tax period. For example, if running a July monthly payroll EPS for payments at the end of the month (for example, 28 July), then the tax period is considered as period 05 running from 06-July to 05-Aug, and as such the date you enter is the end of the tax period in question (enter 05-Aug-YYYY). If running a weekly payroll and its dates span the tax period, then the EPS does not cover the values for this payroll as it falls into the next tax period. For example, a weekly payroll pay date of 07-Aug would be eligible for the next tax period from 06-Aug to 05-Sept. Therefore, the effective date entered of 05-Aug does not include the weekly pay run values. |
Test Submission | Indicate whether this is a test submission. |
Submission Mode | Choose one of the following values:
Note: When you run the EAS/EPS/FPS programs with the submission mode set to'XML, the program performs the following actions:
|
Gateway Test Indicator | This field is enabled only if the submission mode is XML. Specify the gateway test indicator. The default value is No. |
XML Storage Type | This field is enabled only if the submission mode is XML. Select an XML storage type:
|
Version | Specify whether the process is Post October or Pre October. |
Click OK, and then Submit the request.
To run the RTI - Employer Payment Summary Process (EPS) 2016/17
Use the Employer Payment Summary Process (EPS) 2016/17 for returns that relate to the tax year 2016/17.
In the Submit Request window, select RTI - Employer Payment Summary Process (EPS) 2016/17 in the Name field.
Enter the mandatory parameters PAYE Reference, Effective Date, And Submission Mode.
Note: For parameter descriptions, see Parameter Descriptions for the RTI - Employer Payment Summary Process.
Click OK and submit the request.
To run the RTI - Employer Payment Summary Process (EPS) 2015/16
Use the Employer Payment Summary Process (EPS) 2015/16 for returns that relate to the tax year 2015/16.
In the Submit Request window, select RTI - Employer Payment Summary Process (EPS) 2015/16 in the Name field.
Enter the mandatory parameters PAYE Reference, Effective Date, and Submission Mode.
Note: For parameter descriptions, see Parameter Descriptions for the RTI - Employer Payment Summary Process.
Click OK and submit the request.
To run the RTI - Employer Payment Summary Process (EPS) 2014/15
Use this process for the tax year 2014/15.
In the Submit Request window, select RTI – Employer Payment Summary Process (EPS) 2014/15 in the Name field.
Enter the PAYE Reference, Effective Date, Final Submission, and Test Submission parameters.
Optionally, enter the following parameters:
Submission Mode
Gateway Test Indicator
XML Storage Type
Note: For these and other parameter descriptions, see Parameter Descriptions for the RTI - Employer Payment Summary Process.
Click OK and submit the request.
To run the RTI - Employer Payment Summary Process Pre 06 April 13
Use the Employer Payment Summary Process Pre 06 April 13 for returns that relate to tax year 2012/13 through the Submit Request window.
Select RTI – Employer Payment Summary Process Pre 06 April 13 in the Name field.
Enter the PAYE Reference, Effective Date, Final Submission, and Test Submission parameters.
Click OK and submit the request.
If you need to resubmit the EPS for a particular tax period, then you must reset the status of the EPS record. This is required because after the system updates the EPS to Sent status, no updates can be made to the EPS record on the system. Using the EPS Reset Status process, you can update the EPS record and resubmit. This process resets the EPS record to its original state (before it was approved and sent). The Status flag reverts to Saved and the EPS can be updated and resubmitted as normal.
To run the RTI - Employer Payment Summary Reset Status process
Navigate to the Submit Request window.
In the Name field, select RTI – Employer Payment Summary Reset Status.
Enter the following parameters:
PAYE Reference: Select from the list of all the PAYE references within the organization. This is a mandatory field.
Effective Date: Enter the tax period end date using the format DD-MON-RRRR (for example, 12-DEC-2016) for the tax period that you wish to roll back. This is a mandatory field.
Click OK and Submit the request.
Oracle HRMS prevents you from sending NINO verification requests to HMRC where the NI numbers for the payroll population have been deemed as 'verified' because they have been in use prior to RTI and therefore correct. To stop existing (Pre-RTI) verified NI numbers being included in the NVREQ XML file, you must run this process to check the verified flag.
Use the Submit Request window.
To run the Pre - RTI - NINO Verification process
Select Pre - RTI - NINO Verification in the Name field.
Enter the following parameters:
Employers PAYE Reference – Optionally, select from the list of PAYE references in the organization.
Effective Date – Enter a date from which you want all employees to be picked up. This process sets all employees who are 'active' at this date to 'Pre-RTI' verified status. This process does not select any employees who have not started but are in the system (future starters) and any employee that was not an active employee at this date (if date entered is before the current system date e.g. date today = 01-Jan-2012 and effective date entered is 30-Nov-2011 then this process excludes the employees started between 01-Dec to 01-Jan-2012).
Payroll – Optionally, select from the list of all the payrolls within PAYE reference chosen. If you do not select a payroll, then the process selects all payrolls within the PAYE reference. If a person has multiple assignments, then run the concurrent program with the PAYE reference of the primary assignment.
Upon completion of this process, it generates an output report indicating any NI numbers that are missing and a total of NI numbers flagged as 'verified'. Additionally, the process updates the NINO Verified field on the RTI NINO person EIT for all the employees processed with the value 'Yes – Pre-RTI'.
Use this process to request National Insurance Numbers for new or existing employees through an XML message file submission. Using the same method, you can for verification of existing National Insurance Numbers. This process archives the data required for reporting on the XML file.
Use the Submit Request window.
To run the NVREQ process
Select RTI – NINO Verification Request Process (NVREQ) in the Name field.
Enter the following parameters:
PAYE Reference – Select from the list of all the PAYE references within the organization.
Payroll – Optionally, select from the list of all the payrolls within PAYE reference chosen. If no payroll is entered, the process selects all payrolls within the PAYE reference and scans for all records where the NI Verification data is missing.
Test Submission – Select Yes if you are sending a test message file. For 'live' files, default is always No.
Process Type – Optionally, you can run this process for an assignment set or an individual employee. If you set this parameter to Assignment Set, then the Assignment Set field becomes mandatory. If the parameter is set to Employee, then the Employee ID field becomes mandatory. Enter applicable values.
Upon sending this file, you receive an acknowledgement that contains a correlation ID. This correlation ID is present in the reply message (NVREP) that HMRC sends.
The National Insurance Number Verification Reply (NVREP) is a message that HMRC sends for the following reasons:
A reply to the National Insurance Number Verification request (NVREQ) sent by the employer.
A result of an incorrect or missing National Insurance Number on the Full Payment Summary (FPS) sent.
In either case, you must act on the information supplied and upload the correct NI number for the employee where necessary. Use the NVREP process to upload the NVREP file received from HMRC through the Submit Request window.
To run the NVREP process
Select RTI – NINO Verification Reply Upload Process (NVREP) in the Name field.
Enter the following parameters:
File Name – select the name of the incoming file to be uploaded through the process.
Validate mode – select the validate mode. Depending on the following modes, the process does the following:
Validate only –no updates made to the person's record. Only validation is carried out.
Validate and Commit- Live – you can use this mode for a live or test file being sent by HMTC.
For a test file (test indicator on the header = '1'), a warning appears to that effect and the person record is not updated with the NINO number on the file. The process reports missing employees. It checks whether all employees processed (under Validate mode) are on the report as described in the Output Report.
For a live file (test indicator on the header = blank), the process checks whether the NINO Verified flag on the person EIT is set (box is ticked). There is no update to the person record as the NINO is already verified and correct for the person and a message to that effect is provided. If the NINO Verified flag on the person EIT is NOT set (box is un-ticked), then the process updates the record with the NINO supplied on the incoming file.
Validate and Commit - Always – use this is a parameter during pilot testing runs with HMRC, Depending on the NINO Verified flag on the person EIT, the result is different. If the NINO Verified flag on the person EIT is set (box is ticked), then there is no update to the person record as the NINO is already verified and correct for the person and a message to that effect is provided. If the NINO Verified flag on the person EIT is NOT set (box is un-ticked), then the process updates the record with the NINO supplied on the incoming file.
Note: The difference between the Validate Always and Validate Live mode is that the 'test' indicator on the incoming file header is not be checked for Validate Always mode. Use this option with care. All employees processed (under Validate and Commit mode) are reported on the Output Report from the process. Once the record is found using the 'Validate and Commit options, the process updates the employee record on Real Time Information NINO Verification Details EIT with the NINO to Use number provided in the file sent by HMRC as a reply to NVREQ.
Oracle HRMS enables you to make amendments to the updates for the previous tax year after you have completed and returned the end of year submissions for the current year. This process enables you to submit an earlier year update because HMRC does not accept any further FPS submissions after 19th April for the previous tax year. The process generates the XML file for submission to HMRC.
Note: If you submit an EYU where the amendments affect the statutory payments, then you must submit a corresponding EPS to inform HMRC of the change in liability where applicable.
Where multiple EYUs are processed, the EYU takes into account values submitted in an earlier EYU and therefore these are not resubmitted.
If the EYU is affecting any changes to the employer liability due to the amendments to statutory payments, then you must submit an EYU related to the tax year in question.
Use the RTI - Earlier Year Update Process (EYU) if you need to make amendments to the updates for the previous tax year after you have completed and returned the end of year submissions for the current year.
To run the RTI - Earlier Year Update Process (EYU) 2018/19
Navigate to the Submit Request window.
In the Name field, select RTI - Earlier Year Update Process (EYU) 2018/19.
Enter the following data:
Parameter | Description |
---|---|
PAYE Reference | Select from the PAYE references in your organization. This is a mandatory parameter. |
Effective Date | Enter the tax period end date as DD-MM-YYYY for the relevant tax period. For example, if running a July monthly payroll EPS for payments at the end of the month (for example, 28 July), then the tax period is considered as period 05 running from 06-July to 05-Aug, and as such the date you enter is the end of the tax period in question (enter 05-Aug-YYYY). If running a weekly payroll and its dates span the tax period, then the EPS does not cover the values for this payroll as it falls into the next tax period. For example, a weekly payroll pay date of 07-Aug would be eligible for the next tax period from 06-Aug to 05-Sept. Therefore, the effective date entered of 05-Aug does not include the weekly pay run values. This is a mandatory parameter. |
Gateway Test Indicator | This is a mandatory parameter, which contains a list of values, with a default value of Live. The other values in the list of values are Test, Test In Live (Test Submission), and Test In Live (Live Submission). Note that software vendors can use only the Test and Test in Live (Test Submission) options. End users can use only the Live and Test in Live (Live Submission) options. |
XML Storage Type | This is an optional parameter containing a list of values, with a default value of File System and Database. The other value in the list of values is Secure Database. |
Processing Option | Select one of the following values:
This is a mandatory parameter. |
Debug Mode | This is an optional parameter containing a list of values, with the default value of No. The other value in the list of values is Yes. If you set the Gateway Test Indicator parameter to Test or Test in Live (Test Submission), then the application enables this parameter. |
Person Name | Enables you to select all the person names who are processed in the selected PAYE Reference. This field is enabled only if the Debug Mode parameter is set to Yes. This is an optional parameter. |
Compress File | This is an optional parameter containing a list of values, with the default value set to Yes. The other value in the list of values is No. |
File Split Factor (in MB) | This is an optional parameter with the default value set to 20. |
XML File Name | This is an optional parameter. By default, this is blank. You use this parameter only when you need to re-run the archiver for files with errors. |
When the RTI - Earlier Year Update Process (EYU) 2018/19 runs, it automatically generates the RTI EYU Run Reconciliation Report.
To run the RTI - Earlier Year Update Process (EYU) 2017/18
Navigate to the Submit Request window.
In the Name field, select RTI - Earlier Year Update Process (EYU) 2017/18.
Enter the following data:
Parameter | Description |
---|---|
PAYE Reference | Select from the PAYE references in your organization. This is a mandatory parameter. |
Effective Date | Enter the tax period end date as DD-MM-YYYY for the relevant tax period. For example, if running a July monthly payroll EPS for payments at the end of the month (for example, 28 July), then the tax period is considered as period 05 running from 06-July to 05-Aug, and as such the date you enter is the end of the tax period in question (enter 05-Aug-YYYY). If running a weekly payroll and its dates span the tax period, then the EPS does not cover the values for this payroll as it falls into the next tax period. For example, a weekly payroll pay date of 07-Aug would be eligible for the next tax period from 06-Aug to 05-Sept. Therefore, the effective date entered of 05-Aug does not include the weekly pay run values. This is a mandatory parameter. |
Gateway Test Indicator | This is a mandatory parameter, which contains a list of values, with a default value of Live. The other values in the list of values are Test, Test In Live (Test Submission), and Test In Live (Live Submission). Note that software vendors can use only the Test and Test in Live (Test Submission) options. End users can use only the Live and Test in Live (Live Submission) options. |
XML Storage Type | This is an optional parameter containing a list of values, with a default value of File System and Database. The other value in the list of values is Secure Database. |
Processing Option | Select one of the following values:
This is a mandatory parameter. |
Debug Mode | This is an optional parameter containing a list of values, with the default value of No. The other value in the list of values is Yes. If you set the Gateway Test Indicator parameter to Test or Test in Live (Test Submission), then the application enables this parameter. |
Person Name | Enables you to select all the person names who are processed in the selected PAYE Reference. This field is enabled only if the Debug Mode parameter is set to Yes. This is an optional parameter. |
Compress File | This is an optional parameter containing a list of values, with the default value set to Yes. The other value in the list of values is No. |
File Split Factor (in MB) | This is an optional parameter with the default value set to 20. |
XML File Name | This is an optional parameter. By default, this is blank. You use this parameter only when you need to re-run the archiver for files with errors. |
When the RTI - Earlier Year Update Process (EYU) 2017/18 runs, it automatically generates the RTI EYU Run Reconciliation Report.
To run the RTI - Earlier Year Update Process (EYU) 2016/17
For the tax year 2016/17, use the EYU17 version of the earlier year update (EYU) EDI, and XML message type.
Navigate to the Submit Request window.
In the Name field, select RTI - Earlier Year Update Process (EYU) 2016/17.
Enter the following data:
Note: Due to changing legislative requirements, the parameters may vary depending on the tax year of the report selected. Enter only the report parameters required for your tax year.
Parameter | Description |
---|---|
Employers PAYE Reference | Optionally, select from the PAYE references in your organization. |
Effective Date | Enter the tax period end date as DD-MM-YYYY for the relevant tax period. For example, if running a July monthly payroll EPS for payments at the end of the month (for example, 28 July), then the tax period is considered as period 05 running from 06-July to 05-Aug, and as such the date you enter is the end of the tax period in question (enter 05-Aug-YYYY). If running a weekly payroll and its dates span the tax period, then the EPS does not cover the values for this payroll as it falls into the next tax period. For example, a weekly payroll pay date of 07-Aug would be eligible for the next tax period from 06-Aug to 05-Sept. Therefore, the effective date entered of 05-Aug does not include the weekly pay run values. |
Test Submission | Indicate whether this is a test submission. |
Submission Mode | Select one of the following:
Note: When you run the EAS/EPS/FPS programs with the submission mode set to XML, the program does the following:
Note: From April 2018, you can no longer use the EDI as a Submission Mode. |
Gateway Test Indicator | Specify the gateway test indicator. The default value is No.
Note: This field is enabled only if XML is selected as the submission mode. |
XML Storage Type | Select the storage type as File System or Database. The application enables this field when the submission mode is XML. Default value is File System.
Note: This field is enabled only if XML is selected as the submission mode.
|
Processing Option | Select one of the following values:
|
Debug Mode | Select whether to set the debug mode for troubleshooting. The default value is No. |
Person Name | Enables you to select all the person names who are processed in the selected PAYE Reference. This field is enabled only if the Debug mode parameter is set to Yes. |
Click OK and submit the report.
To run the RTI - Earlier Year Update Process (EYU) 2015/16
For the tax year 2015/16, use the EYU16 version of the earlier year update (EYU) EDI, and XML message type:
Submissions relating to the 2015/16 tax year: Use EYU16. The general processing requirements are essentially the same for both versions. In addition, earlier versions of the process are retained (for example, EYU14)
Submissions relating to the 2014/15 tax year: Use EYU15.
Navigate to the Submit Request window.
In the Name field, select RTI - Earlier Year Update Process (EYU) 2015/16.
Enter the required parameters.
Click OK.
Click Submit.
When the RTI - Earlier Year Update Process (EYU) 2015/16 runs, it automatically generates the RTI EYU Run Reconciliation Report.
To run the RTI - Earlier Year Update Process (EYU) 2013/14
Select RTI – Earlier Year Update Process (EYU) 2013/14 in the Name field.
Apart from the parameters of the 2012/13 EYU process, enter the following:
Submission Mode – Select XML to generate XML version of the EYU file or select EDI to generate the EDI version. The default value is EDI.
Note: From April 2018, you can no longer use the EDI as a Submission Mode.
Gateway Test Indicator – Select Yes to indicate test in live or select No. Default value is No.
XML Storage Type – Select storage type as file system or database. The application enables this field when the submission mode is XML. Default value is File System.
Note: If you submit an EYU where the amendments affect the statutory payments, then you must submit a corresponding EPS to inform HMRC of the change in liability where applicable.
Where multiple EYUs are processed, the EYU takes into account values submitted in an earlier EYU and therefore these are not re-submitted.
If the EYU is affecting any changes to the employer liability due to the amendments to statutory payments, then you must submit an EYU related to the tax year in question.
To roll back the RTI - Earlier Year Update Process (EYU)
To re-run the EYU process, use the GB Rollback Process, See: Running the GB Rollback Program
Run the Earlier Year Update Reconciliation Report from the Submit Requests window. The output from this process and the subsequent EYU process produces a PDF report showing the following employee and assignment data:
One page per assignment/employee showing all the relevant data for this run and year-to-date (YTD) values.
Summary totals page to show all this run and YTD totals needed for reconciliation.
Note: The RTI EYU Run Reconciliation Report is automatically generated when you run the RTI - Earlier Year Update Process (EYU) concurrent program.
The RTI EYU Run Reconciliation Report shows details about the employees/assignments that were extracted onto the XML file such as:
Processing Parameters:
Effective Date
Company/Business Group Information
Business Group Name (Company Name)
PAYE Reference
Account Office Number
Date Scheme Ceased
SAUTR
Individual lines (Assignment Details):
Employee Identification Line
Name
NI Number
Date of Birth
Gender
Payroll ID
Assignment Number
Aggregated for PAYE and NI
Start Date
Leave Date
Director Indicator (Yes if Director flag set)
EEA Citizen
Indicator that this is an EPM6
Recently Bereaved
Annual Amount of Occupational Pension - Payment to a Non-Individual
Payments Summary Information for each assignment reported:
Tax Code & Basis
Student Loan Indicator
Payment Date
Taxable Pay
Tax Paid
Net Pay Deductions
Benefits Taxed
Employee Pensions Contributions (Both pre Tax & Post Tax to be added & reported)
NI Category
NICable Pay
Total Employee & Employer NI Contributions (by NI Letter)
Student Loan Repayment
Trivial Commutation Type A
Trivial Commutation Type B
Trivial Commutation Type C
Pension Rights:
Pension Death Benefit
Flexible Accessing Pension Rights
Flexible Drawdown Taxable Payment
Flexible Drawdown Non-Taxable Payment
Report Totals: Prints the totals at PAYE level so that the customer can reconcile records:
Taxable Pay
Tax Paid
Benefits Taxed
NICable Benefits
Employee Pensions Contributions (Both Pre Tax & Post Tax to be added & reported)
NICable Pay
Student Loan
SMP
SPP
SAP
ShPP
To run the RTI EYU Run Reconciliation Report
Navigate to the Submit Request window.
In the Name field, select RTI EYU Run Reconciliation Report.
Select the archive request ID of the EYU process for which you want to create the report.
Click OK then submit the request.
Use the Standalone IRMark generation program to modify the XML file generated by system manually on account of a bug in the software or for some specific business reasons.
You use the Submit Requests window to run the IR Mark Generation Program.
To run the IR Mark Generation Program:
Navigate to the Submit Requests window.
Enter GB Generate IR Mark in the Name field.
Enter the following details in the Parameters window:
File Path: This is a mandatory parameter. Use this to specify the directory path of the file in the middle tier. The directory path you specify should have read write privileges.
Write to Database: This is a mandatory parameter, with options Yes and No. When you set this parameter to Yes, the updated file with new IRMark overrides the old file in the database which is already created when the archiver is processed
When the Write To Database option is set to Yes, the application does one of the following:
If the File Name (File System) is entered, then the application selects the file with the corresponding name for processing from the middle tier.
If the File Name (File System) is not entered, then the application selects the file from the middle tier is selected based on the name in File Name (Database).
XML Request ID: This parameter is enabled when Write to Database is set to Yes. The XML Request ID along with the File Name(Database) enables you to uniquely find the file record in the database that needs to be updated with the new file.
File Name (Database): This parameter is enabled when the Write to Database option is set to Yes.
File Name(File System): When the Write To Database option is set to No, this becomes a mandatory parameter. The application selects the file with the corresponding name for processing from the middle tier.