The new way to submit Tax NI and other PAYE information to HMRC
Welcome to the SDS page on the new Real Time Information programme which is being rolled out by HMRC. Here you will find links to information and details which are regularly updated as the developments unfold.
HMRC are introducing a new process for businesses to submit PAYE information on an ongoing payroll period basis rather than at the end of each tax year. The links below and those to the side will explain in more detail what companies can expect from this new programme as it is rolled out and how it will affect their current processes.
HMRC RTI: Overview | ||
Significant changes to the way payment details are communicated to HMRC Real Time Information (RTI) is a priority government program aimed at improving the operation of PAYE. It will make the system better for individuals and easier for employers and HM Revenue & Customs (HMRC) to operate. The current system has been in existence since 1948 so the changes proposed are very radical and mean a restructure of how all payments and deductions (i.e. Tax, National Insurance (NI), Sick Pay etc.) are reported to HMRC. Under the new system, all employers will have to report employee tax and NI details along with other information, to HMRC every time a payment is made, instead of just once a year at the end of the tax year. The data reported each pay period will include statutory payment / deduction data and data relating to Starters and Leavers in a single file. The key changes are: • The current In Year Movements (IYMV) process will no longer be required The channel for transmission and reporting of this data will be via BACS and the new file format will contain both the net pay data for making the deposits into employee's bank accounts, together with the statutory data for HMRC. The BACS communication will be two-way, with the Acceptance/Rejection reports coming back to the employers through BACS. The new RTI systems will: • make the PAYE process simpler for employers and HMRC back to top Interim Solution In response to concerns from the software and banking industries about the timescales for developing the ISO standards for use in the BACS channel, HMRC will also accept RTI data through Electronic Data Interchange (EDI) until at least April 2014 in addition to the internet channel. HMRC announced that in addition to the tax data within the RTI submission, a cross-reference (hash) will also be required for each employee. There are two parts to the cross-reference: (a) a hash included in the RTI submission to HMRC; The hash needs to be generated by payroll software and all of the elements used to create the hash, including the random string, need to be present in the Standard 18 file used by BACS for payment. The hash will then be reproduced as part of the payment process and sent with confirmation of payment to HMRC for matching with the tax data hash. The Hash will encompass: • originator bank sort code (6), HMRC will match the hashes returned with the RTI data against hashes generated during payment file processing to inform HMRC’s compliance activity. In April 2013 there will be two methods of reporting: • Internet through the Government Gateway. back to top Future BACS Solution BACS is the HMRC’s strategic solution for RTI reporting and they are actively working with the banking and software industries to develop a service which will enable RTI reporting through BACS. This would enable employers who pay their employees through BACS to report RTI automatically at the time electronic payments are made to their employees. back to top Why BACS? • 90%+ employees paid via BACS back to top |
HMRC RTI: SAP's Proposed Solution | |||||||||||
SAP have outlined their potential solution to accommodate the new HMRC Real Time Processing. The solution is still in development so some details may well change. The proposed process will be as follows: Changes to SAP Payroll A new feature will be delivered which will allow you to activate RTI processing for different payroll areas and feature GBIEI will allow you to define groups of employees who work irregularly. A new payroll function (GBRTI) will be created and called at the end of schema GEND prior to function EXPRT. This function will create all the information required for RTI and perform complex checks of the data. The calculated values will be updated into new tables RTI and RTINI for the In Period only. They will not be changed in retro calculations. New cumulation classes in the range /7** have been created and relevant customer wagetypes will need to be mapped to these to identify expense related payments. If customers have used the /7* range for their own processing this will need to be changed. A new wagetype NHWK will be made available to capture weekly hours paid. By default RTI processing will take the weekly working hours from Infotype 0007. If some reason that isn’t appropriate then the new wagetype can be entered on Infotype 0014 to store the weekly hours value for the employee. The wagetype could also be created during the payroll processing if the value fluctuates. Payroll processing will be updated so that employees without an Infotype 0009 record will be rejected. The Pre-DME process will generate the random RTI indicator (/###). This value will be updated in to the Results tables into the new table RTI. The RTI indicator is used to create the hash code. Infotype 0088 will be extended to include fields to capture information for ‘Partners Personal Data’ for additional paternity pay processing. The RTI program (RPCFPSG0) will be very simplistic and will perform some basic checks to make sure that there are not umlauts or accents in the name fields that could cause the file to be rejected. The random RTI indicator will be picked up from the RTI table. This report can be run by PAYE Reference or payroll area and chunking up the running is possible to make sure files remain within size restriction imposed by the Government Gateway. It is assumed that all companies will run the RTI program in ‘Test in Live’ mode prior to exiting payroll. This will allow any problems/rejects from the government gateway to be corrected and reprocessed through payroll if required. Once payroll has exited the RTI program can be run as a live updated. The status of Exit Payroll is not mandatory but probably the process most customers will follow. A Clean Sweep report will also be available to allow final checking to ensure all employees have been processed for RTI. Any rejections by HMRC resulting from the “live” run will not be able to be resolved via the payroll. A BADI will be provided to amend data (at EE level) to facilitate correcting erroneous data (if required) Customers must raise a VERY HIGH message for any HMRC rejections as they should NEVER occur!
back to top |
HMRC RTI: Timescales | ||
Timescales HMRC will pilot the RTI service, with volunteer software developers and employers for a year, starting in April 2012. HMRC and NHS are two of the five pilot customers for April. There will then be a further 295 pilot customers going live in May providing the first runs have been successful. A review will be carried out after the first live postings for RTI and any adjustments identified during testing will be made in Autumn 2012. Employers of more than 250 employees must be using RTI by April 2013. All employers will be using the RTI service by October 2013. NB: Before you go live with RTI you must synchronise your data with HMRC. HMRC have set a target of a 21day turnaround for checking the data submitted. Pilot Phase Timelines
|
HMRC RTI: Pilot Customers | ||
The following have been announced as SAP pilot customers: • Department for Transport |
HMRC RTI: Planning | ||
Before you go live with RTI you must synchronise your data with HMRC (DAS – Data Alignment Submission). HMRC have set a target of a 21day turnaround for checking the data submitted. It is highly recommended that you pay all employees via BACS. If you don’t pay by BACS then you will be unable to generate the unique hash code used for matching RTI data with payment details and this will flag the payment for audit. |
No comments:
Post a Comment