industry monitor RTI issues Systemdesign
John Black and Neil Tonks of MidlandHR’s legislation team identify issues that HMRC needs to address to improve employers’ RTI experience
W
e remarked in our November article (see page 19 of the
November issue of PayrollProfessional) that real time information (RTI) had gone relatively well so far given the size of the project. Indeed, for the majority of employers it is still quite painless, but there are some issues that HM Revenue & Customs (HMRC) must address so that the experience is a good one for all. Recently we have been hearing about ‘duplicate employments’ being created for a variety of reasons and these are a significant cause of ‘disputed charges’. Disputed charges is the term given to the situation where an employer believes they have paid across the right amount of tax and national insurance contributions (NICs) to HMRC but HMRC are expecting the employer to pay a different amount – usually more! HMRC has been working with representatives from the payroll industry to track the sources of the creation of duplicate employments and these will no doubt have been well publicised by the time you read this article. The concern we share with a number of other payroll professionals is that up to now HMRC have been reluctant to admit to weaknesses in the design of their system and therefore even more reluctant to make changes. Instead, HMRC has tried to get round these problems by presenting employers with guidance that does not feel right and which their software might not readily support.
...MORE RESPONSIVE WHERE PROBLEMS ARISE THAT CAN BE ATTRIBUTED TO DESIGN OF THEIR SYSTEM(S)...
One example that has been a source of some frustration to many is the HMRC advice that once you have reported a leaving date, even if this is subsequently changed within the employer’s records, you must always show the originally reported leaving date on any subsequent RTI file submitted for the individual (e.g. for a payment after leaving).
But this is not the true leaving date
and HMRC are asking employers to report incorrect data. Not only does this seem wrong to payroll professionals, it is not necessarily a straightforward matter for their software to support this apparently incorrect principle. Software developers may be reluctant to change their software because surely this guidance will be revoked at a future date. Also, from a very early stage before the RTI pilot began, people were asking HMRC for a mechanism to correct errors like changed leaving dates. Unfortunately, at the moment, if you do not follow this advice there will be a duplicate employment created that almost certainly will lead to a disputed charge. Another example of impractical guidance is this, taken from HMRC’s website, covering late notification of leavers (where no further payment is due):
“Late notifications If an employee leaves your employment, but it does not become apparent until sometime later, you should: l include them on the next FPS l show the leaving date l enter zeros in the pay and tax in this period field l enter the last reported figures of pay, tax, NICs and so on in the year to date field l show the payment date as the last date the employee was paid.
If the leaving date is in an earlier tax year you must send an Earlier Year Update for that year to report the date of leaving.”
This guidance is probably not that well known and is the subject of a current debate between software developers and HMRC. Firstly, showing the payment date at all is fairly meaningless because there is no payment – you are really just reporting a leaving date. Software may have been (or will have to be) changed to automatically report the correct payment date in such circumstances, but this seems pointless. However, the part that is completely unreasonable for employers is the need to complete an earlier year update (EYU) to notify the leaving date in March that is not advised until April. This ‘gets round’ HMRC’s validation that says the payment date must be in the current tax year, meaning an April full payment submission (FPS) would fail. How many employers will actually do this? Our message for HMRC is that they really need to be more responsive where problems arise that can be attributed to design of their system(s) not matching what happens in the real world. That is not to say that where malpractices have occurred for years, HMRC should not seek to change employer behaviour, but they should not expect employers to change perfectly reasonable behaviour just because it does not fit HMRC’s system design.
After all, in the second half of December software developers are still awaiting final advice on the following changes we need to implement from April 2014: l SCON (scheme contracting out number) being mandatory l reporting of multiple SCONs for the same employee l updated list of ‘late reporting reason’ (field 154 of the FPS). This follows the package of help for micro employers announced by HMRC on 9 December.
PP Industry Monitor is sponsored by
PayrollProfessional 35
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56