In-year triggers – it’s all in the coding

01 March 2019

This article was featured in the March 2019 issue of the magazine.

Helen Hargreaves MSc ChFCIPPdip, CIPP associate director of policy, sets out the development of what was formerly known as ‘dynamic coding’

In July 2017, HMRC introduced a system of dynamic coding enabling it to make quicker use of real time information (RTI) data and making in-year adjustments (IYA) to a person’s tax code.

By using third-party information from pension providers and personal tax accounts (PTAs), HM Revenue & Customs (HMRC) began updating tax codes to collect underpayments in year through an IYA rather than show it as a potential underpayment which, in the past, was collected during the following year. The intention was also to minimise the use of week-1/month-1 basis codes to speed up tax refunds which were not previously repaid until after the tax year end.

Initially this concept was welcomed; after all, wasn’t this one of the benefits we were promised when we began submitting RTI data? But as with almost all HMRC projects, this seemingly simple enhancement wasn’t quite what it seemed.

...as with almost all HMRC projects, this seemingly simple enhancement wasn’t quite what it seemed

Trigger points

HMRC relies on two key factors to make an IYA – the individual’s estimated pay, and a trigger point. The tax code will only be amended if HMRC becomes aware of a change in the employee’s circumstances – this is the trigger point. A trigger point could arise in any number of ways such as an individual amending their PTA or by an employer notifying a change via a full payment submission (FPS).

Estimated pay

To check whether an IYA is required following a trigger event, HMRC will estimate the employee’s income for the tax year by taking details of earnings reported for the period to date and performing a simple pro-rating calculation to arrive at an annualised figure. The estimated pay calculation assumes that pay accrues evenly throughout the year – and herein lies the source of many problems for employees and payroll practitioners alike.

Bonus payments

The flaw in the system is that the calculation of estimated pay does not discriminate between regular payments of salary and irregular bonuses. As this calculation is only performed at the time of the trigger event and not each time a FPS is made, this can lead to the estimated income for the year being too high, and inaccurate IYAs being included in employees’ tax codes.

Unexpected outcomes

When I say ‘unexpected outcomes’, I mean that HRMC seemed to be caught unawares by the impact dynamic coding had on many payroll practitioners. Many employers reported an influx of new tax codes being received, often several for the same employee in the same month with little clarity over which one was correct.

Payroll bureaux were particularly impacted, with even medium sized bureaux claiming they received up to fifty new codes every day, and some received many more than that.

For those employees who received a bonus at the beginning of the tax year the outcome was even worse. Because HMRC’s system cannot identify one-off payments, employees often discovered that they were hundreds of pounds out of pocket as a result of an incorrectly issued tax code. HMRC’s solution was to advise employees to update their estimated annual income on their PTA. Not quite fulfilling the promise that dynamic coding would help people pay the right tax on their income as they earned it.

Finding a fix to these problems was the subject of many long conversations between HMRC and payroll stakeholders including the CIPP.

New in-year triggers

HMRC has now announced its plans to introduce two new enhancements to the system, now known as in-year triggers, to help ensure that employees have the correct tax code and end the year balanced with neither an underpayment nor overpayment.

Tax code comparison trigger – This compares the tax code shown in HMRC records for that particular employment against the one shown in the individual’s latest submission from that employer.

The rules attached to this are as follows:

It has got to be the same employer.
The code held in HMRC’s records should have not been issued in the last sixty days.
When comparing tax codes, attention is not given to the suffix letter (L, T, M etc) or to the basis of operation (cumulative or week-/month-1 basis).

Where the tax codes match no further action is taken.

Where the tax codes do not match a new tax code calculation takes place. If the tax code to be issued is the same as the one held in HMRC records, a P6 coding notice will go out to that employer. If the new calculated tax code does not match – for example, after an IYA or new expenses etc – then a P6 notice will be sent to the employer and a P2 notice will be issued to the employee.

HMRC does acknowledge that some employers and pension providers could receive more tax codes over the first few months, but suggests that if the codes are operated, the volumes should return to normal.

Significant pay difference trigger – Whilst HMRC hasn’t yet found a comprehensive solution to address bonus payments, it is hoped that the significant pay difference trigger will go some way to resolving the issue for most. Whenever a submission is received for an employee a comparison takes place with the previous submission for the same employer. The comparison is looking for a significant increase (which currently is set at 50%) in the ‘Pay in period’.

The rules attached to this are as follows.

It has to be the same employer.
HMRC need to have at least one other submission to make the comparison.

Where there is a significant difference in the pay in period, a flag is set to review the case when the next FPS for that employment is received.

On receipt of the next submission for that employment a review takes place to ascertain whether the significant increase has been maintained.
If the difference has not been maintained, then no further action is necessary. HMRC would not look to update estimated pay.
If the difference has continued, HMRC will recalculate the estimated pay and trigger a coding calculation.
If the coding calculation indicates that the customer’s tax rate bands have changed and a code change is necessary, a P2 notice will be sent to the employee and a P6 notice sent to the employer.

Whilst HMRC announced these triggers in the December issue of the Employer Bulletin, there is no confirmed date for when the triggers will be implemented, though we are led to believe that it won’t be before May 2019.

HMRC have agreed to monitor live running with some trusted employers to ensure the triggers are operating correctly. The CIPP’s policy team will keep you informed once the implementation date is announced.