Author: Yvette Lamidey
Published in: PAYadvice
Date: April 2006
Taxation: Online Filing
Common Errors in Online Filing
Avoid the errors that employers made last year and filing your End of Year Returns will be much smoother. Remembering that this year errors will cause files to be rejected.
Having processed most of the 2004/5 Employer's Annual Returns HMRC have published a list of the more common errors encountered in the returns. If the full front end validation had been in place then majority of returns that included these errors would have been sent back to employers to be corrected and resubmitted. However, this year many of these errors will have been corrected by HMRC, sometimes working with employers to establish what the correct information should be whilst others have been corrected by HMRC where it is an illegal character in an address line for instance. But employers and agents must remember that next year these corrections won’t be undertaken by HMRC and that where a file fails the validation process the file will be returned to the employer for correction and resubmission therefore it is in everyone’s best interest to start doing some work now to sort out any little idiosyncrasies in advance of the main year end tasks.
HRMC have also written to each of the software houses and advised them of where employers sent poor quality returns using their software and the common errors that their clients had made. We would hope that the software providers will use this information to improve their products and also review the communications and support given to their clients as there are clearly learnings for all of us. . HMRC are also contacting as many employers as possible where there were errors in their submissions, this will mostly be the large employers who submit the bulk of the P14s. Help from HMRC's Business Support Teams (BSTs) is available for any employer completing their Employer's Annual Return. February's edition of HMRC's Employer's Bulletin will have some hints and tips to help you avoid the most common mistakes.
These common errors have proved that some of the products/computerised software that employers are using doesn’t have full validation to match the Quality Standard and some don’t have the logical validation that you might expect such as allowing non-existent dates e.g. 31st September to be entered!
Looking at the types of errors reported by HMRC we believe that although validation has been written and implemented for data entry to prevent incorrect characters etc. being entered for new starters and changes to addresses, NINO updates etc the data that has been held on payroll systems for many years and not changed hasn’t been through this type of validation. So it may be that new employees have quite clean data but long serving employees who haven’t moved in recent years for instance won’t have clean data.
One way that you can tackle this problem is by writing some quick reports to capture any employee records that have this spurious data or it may be that your software provider can provide you with a suite of reports, although this may be at an additional cost. We have also heard anecdotal evidence of software providers and bureaux having these reports available as part of their year end routines but employers either do not realise that these are available and what they are for or simply not using them. Check with your provider to see what is available as this may save you a lot of time and frustration at year end.
Remember the reason why you need to ensure that your employee’s data is clean and conforms to the standards is that if a P14 contains data that does not pass the validation process when the 2006 Employer's Annual Return is submitted then the whole of your return will be rejected and you will have to correct the data and resubmit.
Employee names
In both the forename and surname fields the first character must always be a letter ; a comma, apostrophe, full stop of space is not acceptable. Other than the letters A to Z in both upper and lower case the only other characters allowed in the forename field are hyphen and apostrophe; it is important that you use “’” and not “`” for the apostrophe. Second forenames should be shown in the forename field.
In the surname field in addition to A to Z in upper and lower case and the numbers 0 to 9, comma, full stop, forward slash, ampersand (&), hyphen, space, apostrophe and brackets can be used for the second and subsequent characters .
Addresses
The first character of the address line must be either the letters A to Z or numbers 1 to 9. It is important that there are no empty lines in the middle of the address and that the post code field is in the correct format e.g. BR2 6XB. Again this is an area where running reports may be helpful to try and identify any incorrect formats. Post codes were a particular issue with this year’s returns.
NINOs
Despite the publicity re NINO formats and that temporary NINOs are no longer acceptable many systems still hold NINOs in this format. If you do not hold a valid NINO then you should leave the field blank and ensure that you submit the employee’s gender and date of birth. This should be something that you can easily run a report for. If your software package has to generate a temporary NINO if a proper one isn’t entered when setting up a new starter ask your software provider to ensure that as part of end of year process these NINOs are stripped out.
There is also a list of valid NINO prefixes detailed in an Annex to the Quality Standard that it may be useful to check. Parts of the Quality Standard for 2005-06 are different to 2004-05, so make sure you look at the right one! Other prefixes that are not valid are NI and PZ. Unfortunately some NINOs with a prefix of PZ have been sent in error to employers who have updated them on the employee record and these NINOs should be removed.
Tax codes
There were a number of common errors in the format of tax codes. Many of these are very simple but when entering data in a hurry it is easy to make mistakes especially if your system doesn’t validate the data at the point of entry.
Unless the tax code that you are entering is long enough to fill the entire filed it is not necessary to fill the entire tax code field with leading zeros and when using K codes do not use leading zeros between the numbers and the ‘K’. Remember tax codes should always be left justified in the field.
Where the employee is on a week 1/month 1 tax code this should be recorded in the appropriate indicator field and not in the same field as the tax code.
And where using 0Tand D0 ensure that you are using a zero and not the letter ‘o’.
Unfortunately some employers still have the dreaded H codes on their systems. These codes have not been valid for some time and if they are being used it is possible that the employee is not paying the correct amount of tax. If you have any current employees with an H tax code please contact your local HMRC office so that the correct code can be issued; as a precaution you should change the ‘H’ suffix to a ‘T’ suffix to ensure that the record isn’t rejected on submission. If an ‘H’ code is held on the system for a leaver in this current tax year then change the ‘H’ to ‘T’ to ensure the data is not rejected at year end.
Pay, NIC and Statutory Payment Fields
Negative values are not allowable in the statutory payment fields, pay or NIC fields.
One common error is to transpose the pay and tax information when entering P45 or P6b information so it’s wise just to check that you are entering the pay in the previous pay field and the tax in the previous tax field on the audit trail. These errors will not be identified until the P14 has been processed and the employee’s record is being checked.
PAYE Reference Number
Generally the PAYE reference number is set up once and forgotten about but this year’s processing has highlighted that many of these numbers have been entered incorrectly and has caused a lot of problems when processing the annual returns.
A valid PAYE reference number is made up of the three digit HMRC office number and the employer’s unique PAYE reference number.
It is important that the HMRC office number is not repeated in the PAYE reference number field or that you only show the PAYE reference number. For example a reference of 913/WZ51258 should not be shown as just WZ51258 or 913/013WZ51258.
Yvette Lamidey
Yvette Lamidey is director of Paris and Parks Consulting
www.parisandparks.com