Kate Upcraft reports on the HMRC webinar on tax coding, which covered the way certain trigger events generate changes to tax codes. This is an area that has long mystified tax agents and their clients.
State benefits and tax codes
The first part of the webinar dealt with the four different scenarios that are catered for when DWP tell HMRC that an individual has just started to receive state pension or Employment and Support Allowance (ESA).
DWP has informed HMRC within one month of the benefit start date. The annual amount of the benefit is coded out, but a month 1 code is issued just to recover tax on 1/12th of the annual amount each month for the rest of the year, so there will be no potential underpayment.
DWP has informed HMRC later than one month after the benefit start date (I asked why this happens, as surely it is automated, but got no reply from the presenters). The actual amount to be received in the rest of the tax year is coded out and the code issued on a month 1 basis. An underpayment will be generated that will carry forward to the next tax year to code out the amount received prior to the tax code change.
The benefit recipient won't be a taxpayer when the new source of income is included. The amount to be received for the rest of the tax year is included in the code on a cumulative basis, but the code won’t be issued as there is will be no tax to pay.
The benefit causes the taxpayer to have a tax liability for the first time. The actual amount for the rest of the tax year is included and the code is issued on a month 1 basis, but this will lead to a potential underpayment that will be coded out in the next tax year.
Prior to the start of each tax year DWP informs HMRC of the taxpayer’s new state pension or ESA. HMRC code these amounts out considering any other income sources. As the state benefit increases usually take effect in week two of the tax year the annual amount coded out is: 51 x the new rate + 1 x the prior year weekly amount.
When an occupational pension is notified to HMRC by the pension provider, this will have no impact on the live employment, as the taxpayer may be continuing to work as well as receive a pension.
If there is a live employment the occupational pension will always be treated as the secondary source, so the taxpayer will need to make contact with HMRC to change the occupational pension to the primary source, if that is what they want.
Reliefs and allowances
This is where there is an amount in the taxpayer’s code related to:
- flat rate expenses;
- job-related expenses (e.g. mileage, laundry allowance); or
- professional subscriptions
Unless the taxpayer tells HMRC that any of the above adjustments are not due for the next tax year, the amount will carry forward unchanged.
Fixed in code
If the individual leaves the employment for which flat rate expenses, job-related expenses or subscriptions relief was due, those amounts are not pro-rated, but remain in the code.
This is because HMRC assumes that the next job will be in the same sector, so a similar adjustment will be due. The adjustment will only be removed from the code if as part of the annual records’ scan it is found that the employment has ceased and the only remaining income source is a pension, or the taxpayer notifies HMRC that the adjustment is no longer due.
If an employee is claiming job-related expenses at more than one employment, those expenses are totalled up as they can only be applied to the primary employment income source.
This can relate to personal pensions as well as occupational pension schemes that have had tax relief given at source. The pension relief is permitted for taxpayers up to age 75. The payments are grossed up to provide the tax relief, if HMRC is not aware that is a one-off pension contribution. The relief is not removed even if there isn’t a live employment, as long as the employee has not reached age 75.
Gift Aid relief
This works in the same way as pension relief, other than it is not age dependant. Remember: charitable giving via payroll applies tax relief at the employee’s highest marginal rate, but only if the employee is a taxpayer, in the same way as the net pay arrangement for pension contributions.
I was surprised this didn’t generate any questions from the audience given the problems HMRC has had with the different rates of tax on banks interest and dividends. There doesn’t seem to be a solution in the offing. HMRC’s only suggestion was: “ask the taxpayer to contact us if the amount in their code is wrong”. HMRC want taxpayers to do this via their personal tax account, so they can keep a track of the request and challenge it if it isn’t actioned correctly.
We need to try to engage taxpayers with using their personal tax account, particularly if they aren’t represented, as this is the best route to see an amended code (in fact the only route if you’ve 'gone paperless', either inadvertently by ticking the box when you activated your account) or by choice.
Other than that, the most obvious message is tell HMRC if things change year-on-year as their systems will otherwise make assumptions that are incorrect. Where this is around low level reliefs and allowances, that may not be so problematic but if a one-off amount of investment interest or pension contributions has skewed the code then that needs more immediate attention.
Primary and secondary income sources
Here the tone of the webinar changed to ‘employers/agents can cause all sorts of problems”. This was centred around sending incomplete starter information where statement A, B or C is either not selected correctly or not sent at all.
I confess to being bemused by this, I’m not aware of any reputable payroll software that allows a new starter to be set up without a starter declaration, so if this is the cause of so much incorrect coding, why aren’t HMRC doing more data analysis of the software, and the employers using that software, who are causing these issues – surely that’s an easy nut to crack?
It was also clear that the issue of only being able to send leaver information at the time you pay employees causes problems. If the ‘new’ employer reports the new employee and ticks statement B (I've already had a job this tax year but haven't now), HMRC can't move this job to be the new primary employment (and restore a cumulative personal allowance) until the ‘leaving’ FPS arrives from the previous employer.
For example, if the previous employer had the person on a quarterly payroll there will be a significant time lag before that FPS arrives – one wonders why HMRC can't act on the taxpayer’s assertion that they have no other employment, if this causes arrears as if it’s untrue the taxpayer has signed the starter declaration so can’t complain?
I also wonder at the point of code BR when the taxpayer selects statement C, but an undeclared statement C (the default operated by the employer) provides a better outcome of 0T/1. Isn’t BR an out-of-date blunt instrument in this regard?
If there is software that sends a previously unknown employee on the FPS without a start date and declaration HMRC systems assume the following:
- BR, DO, D1, OT or NT supplied – statement C
- Any ‘standard’ tax code on a week1 /month 1 basis – statement B
- Any ‘standard’ tax code on cumulative basis – statement A
This can cause HMRC to do the following:
- Create a secondary income source instead of primary ie issue BR instead of the current year cumulative personal allowance
- Live employment ceased – why this happens I don't know if the leaver FPS hasn’t arrived, as that conflicts with what they said earlier in the webinar?
- The current emergency tax code is issued instead of cumulative
Finally, much was made of payroll ID being used to distinguish between employments. Sadly, those of us who’ve been involved in this since the beginning of RTI know that much-needed work to finesse this was shelved by HMRC and yet it is one of the main causes of duplicate records, even if the old agent and new agent do everything by the book when they hand over the client.
I had an example just today of a client payroll totally duplicated. So, please can we start this debate again proactively and come up with a robust solution? Moving clients between agents and software and TUPE changes are 'business as usual', so cannot continue to cause chaos for taxpayers, employers and agents.
Finally, I was surprised that no mention was made in the webinar of what the impact of these triggers would be from 1st July when dynamic coding goes live. Will it be the case that changes that have historically led to an underpayment will no longer do so and will be coded out in-year, leading to more aggressive tax deductions? We’ll try to find out more and share that with you as soon as we know.
This is even more important information ahead of the move to dynamic coding, which we have seen confirmed in the latest Employer Bulletin as July 2017. We’ve been told by HMRC more precisely it is due to be 1st July.
About Kate Upcraft
Kate is a technical writer, editor and lecturer on all aspects of employing people - primarily payroll and HR matters.