HMRC trials new PAYE code trigger

Rat hole
istock_dabjola_aw
Share this content

Up to 500,000 tax codes currently operated by employers may be wrong, based on the most recent code issued. HMRC is tweaking dynamic coding to solve this problem. 

Dynamic coding started to roll out in July 2017, complete with a set of trigger points that lead to a new code being issued, as I explained when examining the problems that initially emerged.

The aim of dynamic coding is to reduce the number of P800 computations produced after the tax year end. These P800 forms are necessary because, despite the operation of PAYE, there are under or overpayments of tax.

Dynamic coding aims to use the increased information provided by taxpayers or their employers within the tax year to recalculate the employee’s “estimated pay”. Then if necessary, amend the current tax code in use to achieve a more accurate deduction of tax.

Current triggers

Until April 2019, trigger events included the following:

  • Full Payment Submission (FPS) with a start date for an employee or pensioner: a recalculation is based on the number of days to the end of the tax year and the first reported pay figure.
  • FPS with a leave date: based on the final FPS year to date figures.
  • Benefit in kind reported by the employee or employer.
  • Allowance or relief reported by the taxpayer.

In addition, there is a bulk run of revised PAYE codes in January before the annual coding exercise for the next tax year, which is undertaken for employees but not for pensioners. This uses the year-to-date figures on the FPS prior to the chosen date.

New trigger

From April 2019, HMRC has begun a “controlled go live” of a new coding trigger.

This involves comparing the tax code reported for an employee on the FPS with the code HMRC believes it has issued for the taxpayer, as shown on the National Insurance and PAYE Service (NPS). Where the codes don’t match and the employer hasn’t implemented the code issued more than 60 days ago, the HMRC computer will reissue the PAYE code to the employer.

When comparing tax codes, the HMRC computer doesn’t take into account the suffix (L, T, M etc) or whether the code is cumulative or non-cumulative, ie WK1/MTH1.

If the code hasn’t been used by the employer, the computer will recalculate to see if the HMRC held code is still appropriate. If the HMRC held code is still appropriate, it will be reissued and if not, HMRC will issue a brand new PAYE code to both the employee and employer.

During the control phase, which is now in month two, HMRC has issued new codes to the first 30,000 mismatches identified. It is also working with selected employers to sense-check for any unexpected scenarios.

HMRC expects the volumes of reissued codes will ramp up in June, with the full “go live” of this project to be confirmed at a later date.

Who checks code rejections?

If there are 500,000 PAYE codes currently ignored by employers, this prompts a number of questions:

  • Are employers and agents downloading the employees’ tax codes before each payroll run?
  • If the employer still receives paper codes, is the correct employer address and contact details held on the HMRC record for that employer?
  • Is the employer sure all codes are being received?
  • If the employer is downloading codes online (which all decent payroll software should do), does the software alert any mismatches, such as employee name or NI number, so those points can be followed up with HMRC?

New starter process

HMRC has identified that 500,000 new employees are being defaulted to an “undeclared” starter declaration. This means the employee didn’t tick one of the following boxes on the starter checklist under “employee statement”:

A:  This is my first job since 6 April and I’ve not been receiving taxable state benefits or pension

B:  This is now my only job but since 6 April I’ve had another job or received taxable state benefits or pension

C:  As well as my new job, I have another job or receive a state or occupational pension.

In this situation, the employer defaults the new employee to tax code 0T/1 and supplies statement C.

Why does this happen?

The operation of the starter checklist is not optional; it is mandatory for all new starters even if they have a form P45. However, the new starter checklist is baffling for some employees, so they leave the employee statement box blank hoping the employer will know what to do!

Some employers think rather than getting a new starter to 'fill in a form’ they put the employee on 0T/1 until HMRC look at the taxpayer's record after the first FPS is submitted. This leads to the new employee receiving no personal allowance at all and overpaying tax.

Warning

HMRC has begun to visit the top 100 offending employers to review their new starter process to ensure that it is legally compliant.

About Kate Upcraft

Kate is a technical writer, editor and lecturer on all aspects of employing people - primarily payroll and HR matters.

Replies

Please login or register to join the discussion.

avatar
By CJaneH
21st May 2019 15:51

I just hope they issue the revised coding to the tax payer and if the taxpayer has an agent make them accessible to the agent.

Having suffered HMRC informing the employer but not the employee I think we will have a lot more wrong codings for tax payers who have income from other sources as well as payrolls.

Thanks (1)
avatar
By tedbuck
22nd May 2019 10:51

Only 500,000?
Adding in spurious underpayments from previous years.
Ignoring changes of employment.
Incorrectly dealing with multiple employments.
Ignoring cessation of benefits.
Ignoring cessation of employment.
I am sure there are many others.
HMRC's computer systems cannot cope with the multitude of changes so they would be better to stop wasting our time trying to correct things and just leave them alone.
Incidentally do they actually reply to post these days?

Thanks (1)
22nd May 2019 11:05

I received for myself a notice of coding with higher rate tax relief on pensions.

I am not and never have been a higher rate taxpayer and my income was at least £10,000 below the higher rate threshold. So now I have an underpayment of £135 for 2018/2019.

Absolute waste of time.

Thanks (1)
22nd May 2019 12:01

Hmmm

I kind of expected that the RTI system should already check the code - if you're using a live system why not and try to get it correct. In the old days when we had to do end of year checks in HMRC a difference in code would mean a further review was required. Once computers came in (yes I am that old) it would produce reams of fanfold paper of taxpayers who were not on the expected code. It's an old problem and I don't understand why it's only being addressed now!

Thanks (3)
22nd May 2019 12:28

Well I imagine that given most codings are bobbins, then many employers ignore them rather than waste a lot of time putting in rubbish, dealing with the employee who then has to get it junked, potentially paying out temporary loans, and then changing it back in 3 months time.

Much easier to ignore it, especially when it gets sent to a portal which then deletes it in 30 days. Tax code? What tax code?

The way to fix the problem, is for tax codes to be accurate in the first place.

Thanks (2)
to ireallyshouldknowthisbut
23rd May 2019 18:48

Bobbins ha not heard that since I left Manchester ...

Thanks (0)
avatar
22nd May 2019 18:24

Is the reality that many employers are ignoring the requirement for new starter checklist altogether, or are waiting for a P45 to turn up (late). Putting starter information in the second payment is too late and tardy and the employer has inadvertently confirmed to HMRC that the individual has two job.

Defaulting to C 0T is an error recovery position, many may think it appropriate, when in reality the employee has just been disadvantaged.

Also seen are valid P45 entries but also accompanied by declaration C when in most cases the PAYE required value is B.

The challenge will be that if left blank (yes it will cause rejection of the entire FPS) then software will default to C.

Is one of the issues with the starter checklist it’s poor design over multiple pages.

Thanks (0)
avatar
22nd May 2019 20:39

I wonder if this article is the answer to why my higher rate clients May 2019 code has changed from April K198 to May K559.
A Previous Years underpayment (u/p) £2484 was coded in for April and the restriction was 6210. That was what I had expected, (6210 @ 40% = £2484).
Following the submission of the P11d the code only needed to be reduced by 50. The May code shows this adjustment but now the code is K559 and shows u/p £2474 restriction 9097 and in-year u/p £94.40 restriction 518.
I understand (I thought I understood) dynamic coding. I appreciate there would a u/p if the K code increases April to May but, I cannot calculate £94.40 (I make it £120.33) and I don’t understand why the Previous Years u/p restriction has changed either.
Am I correct, is my client a victim of HMRC’s erroneous Trial or I am totally wrong in my calculations of the Previous Years U/p restriction and my understanding of dynamic coding?
Who said “Tax doesn’t have to be Taxing”? I think they were wrong.

Thanks (0)

Related content