Universal Credit - two payrolls in calendar month

Problem for employee's universal credit following two payrolls in December

Didn't find your answer?

I am interested to know how widespread a problem that I came across today is.

An employee of a client of mine has had their Universal Credit stopped/suspended because they received two payrolls in the calendar month of December.

I normally submit a paydate of between 1st to the 5th for this client's monthly payrolls, but the christmas paydate was pulled forward (I think this is quite common) and the employees were paid at the end of December. So M8 paid on 3/12/21 and M9 paid on 31/12/21. This led DWP to belive that the employee's income has doubled.  HMRC says that this happens a lot because DWP run on calendar month and HMRC run in tax month periods. As the agent, I cannot fix this. Apparently the employee has to contact HMRC who then email DWP requesting that DWP update their database.

This must be quite a widespread problem, but I have not come across it before.

Replies (30)

Please login or register to join the discussion.

avatar
By paul.benny
05th Jan 2022 13:01

To prevent this problem, HMRC guidance instructs you to submit your RTI with the normal paydate, even if you are paying early for Christmas.

Thanks (6)
Replying to paul.benny:
RLI
By lionofludesch
05th Jan 2022 17:30

paul.benny wrote:

To prevent this problem, HMRC guidance instructs you to submit your RTI with the normal paydate, even if you are paying early for Christmas.

Agree. I'm afraid the OP is at fault here, imho.

Any chance of resubmitting with a revised pay day ?

Thanks (1)
Replying to lionofludesch:
avatar
By Hugo Fair
05th Jan 2022 19:00

Now that would be an 'interesting' experiment!
No problem from HMRC's perspective, but the exact processing rules via which an extract is passed from HMRC to DWP are undocumented (at least in the public domain) ... so the resultant consequences on the UC system are unknown.
[I wouldn't put it past that system to treat the 'new data' as an additional payment rather than a correction ... so talking to the UC people is probably the safer option].

Thanks (1)
Replying to paul.benny:
avatar
By Paul Crowley
05th Jan 2022 20:02

Agree
Understood by all involved with wages

Thanks (0)
Replying to paul.benny:
avatar
By Catherine Newman
07th Jan 2022 16:48

This is paying early for New Year-not Christmas but I agree OP is unfortunately and unwittingly at fault here-didn't show pay between 1 and 5th of January. As I said to a client in the summer when she asked me to advise about a revision to partnership shares and the criteria for the third grant hadn't yet been announced, my service doesn't plan for entitlement to benefits and grants. Hindsight is a good thing.

Thanks (0)
avatar
By Wanderer
05th Jan 2022 13:45

Been a known issue for many years.

Just another case of incompetence with HMRC. Then they instruct us to use a workaround (which goes against the whole idea of RTI when it was sold to us) because their systems are so useless.

Thanks (0)
Replying to Wanderer:
avatar
By paul.benny
05th Jan 2022 14:28

Wanderer wrote:
..Just another case of incompetence with HMRC...

Not in this case. UC is administered by the DWP not HMRC.

And I do have sympathy with both in this case. It's employers who cause the problem by having a non-standard pay date that's impossible for HMRC or DWP to predict reliably. Asking employers/payroll providers to submit RTI using normal pay date seems to be reasonable.

Thanks (3)
Replying to paul.benny:
avatar
By Wanderer
05th Jan 2022 14:35

paul.benny wrote:

Not in this case. UC is administered by the DWP not HMRC.

Incompetence that HMRC design a system which does not properly correllate with the UC system in all permutations.
Thanks (0)
Replying to Wanderer:
By Duggimon
05th Jan 2022 15:40

Wanderer wrote:

Incompetence that HMRC design a system which does not properly correllate with the UC system in all permutations.

I am pretty certain the HMRC system predates UC and in fact the UC system is terrible in almost every way. The RTI system of course is also terrible in every way, I just don't think it's fair to stick poor old HMRC with more than say 48% of the blame in this instance.

Thanks (2)
Replying to Duggimon:
avatar
By Wanderer
05th Jan 2022 18:22

Duggimon wrote:

I am pretty certain the HMRC system predates UC and in fact the UC system is terrible in almost every way..

They were intertwined. RTI was brought in (so we were told) as it was necessary for UC.
Thanks (1)
Replying to Wanderer:
avatar
By Hugo Fair
05th Jan 2022 19:12

FWIW, no.

RTI was the ba5tard child of the stillborn Centralised Deductions proposal (ER sends gross pay to HMRC who ... perform calcs / retain taxes / send net pay to individual EEs)!

UC was a later entrant when someone realised that they could use that RTI data as a way of cross-checking individual claims (hence the BACS hash value, within FPS files, that was dropped once it proved to be not fit for purpose).

Basically the UC systems have been 'designed' (aka cobbled together) pretty much on the fly without public specifications or documented procedures.
Sound familiar?
It's like an Aesop's fable (morality tale) that should have been read & absorbed before starting out on the MTD road ... but of course wasn't!

Thanks (1)
Replying to Hugo Fair:
avatar
By Wanderer
05th Jan 2022 20:20

Hugo Fair wrote:

FWIW, no.

FWIW Yes.
Look at the timing of RTI & UC. The implementation of the former was very much driven by the 'dream' of the latter. Also look at how RTI is mentioned in the Universal Credit Regulations 2013. RTI was very much in mind when they wrote the UC regulations.
It's also what we were told at the time!

From the Post Implementation Review:-

HMRC wrote:
The Real Time Information (RTI) Programme implemented the biggest change to Pay As You Earn (PAYE) since 1944.
It introduced more frequent or “Real Time” filing of employers’ payroll information to help ensure collection of the right amount of tax and NIC from employees, improve the accuracy of tax credits payments and support the successful introduction of Universal Credit.
&
HMRC wrote:
The drivers for delivery of RTI were:
• significant modernisation of the PAYE system to reduce the burden on employers
• providing real time data for future exploitation
• to ensure a real time earnings feed was sent to DWP to enable them to deliver Universal Credit (UC).
Thanks (0)
Replying to Wanderer:
avatar
By Hugo Fair
05th Jan 2022 23:59

Ah, the infamous RTI Post Implementation Review ... possibly the most egregious retrospective re-write of history produced - even by HMRC's standards.

RTI, which had been a couple of years in detailed planning by early 2011 (as I know having been at many of the meetings thrashing out said detail), was formally introduced within The Income Tax (Pay As You Earn) (Amendment) Regulations 2012 ... effective 6th April that year.

All of which pre-dates the UC regs ... which is what I said in my previous post.

UC may well have been a twinkle in someone's eye at the time (it was certainly a dream of IDS who never had anything to do with RTI or even general PAYE) ... but mention of it does not appear anywhere within early RTI documentation (from legislation to software specifications or draft user guidance).

It was only after some professional compadres pushed (via select committees and the OTS etc) for the mandated review that had 'gone missing', that the so-called Post Implementation Review was quietly published (to gasps of disbelief from those who'd been at the coal-face throughout) at the end of 2017.
And, presumably in desperation for some post-hoc justification of the 'benefits' (since most of those initially promulgated had failed to some degree or other), it was only from this point that revisionism claimed the support of UC had been the intention all along.

This might remind you of the recent claims that the proposed Basis Period changes are an essential precursor to MTD for ITSA, despite several years of the latter's evolution without the former even being mentioned?

In other words when you say "It's also what we were told at the time!" ... not in my world.
I even sat in meetings with DWP where (as late as 2015) I was asked to explain how several aspects of RTI worked, and what problems I could foresee IF they were able to gain access to automated RTI extracts ... and guess what some of the earliest identified potential problems were (as per the original topic of this thread)!

Thanks (4)
Replying to paul.benny:
avatar
By The Dullard
05th Jan 2022 14:36

No. The UC legislation is the problem. It's too rigid. People that are paid 4-weekly get a nasty surprise in the month that they do actually get paid twice. Well, it shouldn't be a surprise after the first year of claim, but the system should be capable of adjusting to the people that it is intended to support, rather than the other way around.

Thanks (0)
Replying to paul.benny:
avatar
By Hamlin
05th Jan 2022 17:19

Thanks for your comment. Now that I know, I agree that it is not difficult for me to file the RTI with a typical payment date rather than the actual payment date. I do, however, think that since the RTI submission indicates which months the payments belong to, that the HMRC/DWP systems should be able to cope with this better.

Thanks (0)
Replying to Hamlin:
avatar
By Catherine Newman
07th Jan 2022 16:57

My software Qtac has the expected set pay dates. You can put end of month, 4 weekly, weekly. Even if the pay is paid early, it generates the usual date. You just run it early but it still files as the usual pay date. It is very quick to run too.

Thanks (0)
avatar
By SXGuy
05th Jan 2022 14:12

Ask client to get UC to contact you and explain what happened. They are quite accommodating from past experience.

Thanks (1)
avatar
By Hugo Fair
05th Jan 2022 17:02

This is not a new issue, nor does it only affect the typical pre-Christmas early payment.

https://www.gov.uk/running-payroll/reporting-to-hmrc
"You must enter the usual date that you pay your employees, even if you pay them earlier or later. For example, if you pay your employees early because your usual payday falls on a Bank Holiday, you should still enter your regular payday."

Of course it has taken HMRC the best part of 10 years to admit to the problem (caused by them supplying an 'extract' of FPS data to DWP for running their UC system) and then come up with this workaround (that actually contravenes the written rules of RTI) ... but hey ho!
And they still don't have an answer to the same problem when the cause is payrolls paid at at a frequency of multiple weeks (weekly/fortnightly/4-weekly) ... although they've trialled various software 'solutions' at the UC end - to try and identify such occurrences, so as to enable manual intervention (before UC automatically changes the amount paid out).

Oh the joys of joined-up thinking in a digital world. Happy New Year.

Thanks (3)
Teesside
By Teesside
05th Jan 2022 18:07

Get the employee to speak to UC and explain that they got paid early and they should move the payment into the following assessment payment for UC as if they had been paid on the usual pay day.

Thanks (0)
avatar
By Paul Crowley
05th Jan 2022 20:13

Yet another example of how the British state just cannot understand its own rules.
Basic rule is HMRC MUST be informed before payment is made and date of payment
No, we changed our mind. Create fictional pay dates
But disobey our rules (cannot remenber which rules that you must obey) and we will punish you

Thanks (2)
Replying to Paul Crowley:
RLI
By lionofludesch
06th Jan 2022 07:36

Paul Crowley wrote:

No, we changed our mind. Create fictional pay dates

More like "we weren't smart enough to see that this very predictable scenario wouldn't work in practice so we're kindly granting a concession - aren't we nice?"

Thanks (2)
Replying to lionofludesch:
avatar
By Hugo Fair
06th Jan 2022 12:46

Normally I'd agree ... that's a fair summary of their typical approach.

But in this case they've quite categorically (and without shame) instructed employers to break the RTI rules by lying ... and not as one-off, the instruction is now part of the formal day-to-day RTI guidance (despite inherent contradiction).

And this is not a unique example ... a 'deemed worker' FPS requires you to insert an 'Employment start date' (despite by definition there being no such value).

Thanks (1)
Replying to Paul Crowley:
By Charlie Carne
10th Jan 2022 09:33

I don't see a rule discrepancy. Yes, you need to report on FPS before employees are paid, but the paydate reported is the usual paydate. Where's the problem? If they are normally paid on the 31st of the month and you pay Xmas salaries early on 17th December, you need to report (by filing FPS) by 17th but show paydate as 31st. No "fictional dates" are involved.

Thanks (1)
Replying to charliecarne:
picture of a mushroom
By mushroom_dept
10th Jan 2022 10:24

I agree - I process our payrolls dated 25th of the month but the December payroll payment can be much earlier than that and I submit the FPS on that day, meeting the obligation to report on or before payment day, but still with the date set as 25th.

Thanks (0)
Replying to charliecarne:
avatar
By Hugo Fair
10th Jan 2022 13:38

Except that the data item being reported is not 'paydate' but 'payment date'!

The 'rule' discrepancy lies in HMRC's inability to provide a coherent definition as to the meaning of the 'payment date' data item in the FPS ... and everything that then follows on from that definition (including whether or not the submission has been made on/before payment *according* to automated rules within HMRC's systems).

To most people, a 'payment' date is the date on which payment actually is made.
But the HMRC definition says "Enter the payment date for your employee. If the payment date falls on a 'non-banking day' show the payment as having been made on the regular payday."
[Note that the item is called 'payment' date but the definition refers to a regular 'payday' - which is not a concept understood by many employers whose contracts may say something like ".. on the last Wednesday of the calendar month".]

In the early days of RTI, HMRC fully believed that all (or at least most) FPS files would include a 'BACS hash code' value - which they could use, amongst other things, to automatically detect whether the physical payment was before the reported 'payment' date ... and so generate a Penalty. In particular this was meant to trip up those clever clogs who always reported the payment date as the final day of the tax month (irrespective of when actual payment took place).

And there is no doubt that the initial intention was to capture *when* the payment actually took place ... hence all the furore over people being paid daily (e.g. at the end of event shifts) and, without the ER being allowed to treat or report any of that as 'advances', therefore having to file an FPS every day!

Following LOTS of representations to them (which resulted in a period of a few years when the definition - and guidance in things like the Employers Bulletin - changed backwards and forwards, often out of sync with each other) ... HMRC started issuing easements (such as the one about early payment pre-Christmas).
And eventually they introduced the 'Late PAYE reporting reason' data item - mostly as a means of reducing the penalty appeals.

But that still left lots of areas with problems (most famously for UC claimants) - only some of which have been (belatedly) tackled ... see Kate Upcraft's post below.

Rant over ... but it is indeed 'fictional' data that is being requested - and on the basis that "it will mean what we (HMRC) choose it to mean - until we tell you otherwise"!

Thanks (3)
Replying to Hugo Fair:
avatar
By rbw
10th Jan 2022 16:37

Well if rants are the order of the day...

It's way past time that HMRC consolidated the regulations *and* aligned law and practice. But successive governments wanted a more businesslike Civil Service so no one should be surprised if HMRC's view is that the details of legislation can be ignored where nobody's going to enforce them. And if the Treasury worries about the integrity of the system the evidence has escaped me.

I'll get back to me drooling and trouser-rolling now.

Thanks (0)
Pile of Stones
By Beach Accountancy
10th Jan 2022 09:41

This issue was also mentioned in both the most recent Employers Update and Agents Update, specifically because it can affect Universal Credit.

Thanks (0)
By Kate Upcraft
10th Jan 2022 10:26

I agree with the posts here that there are two different filing requirements: file on or before actual pay day (other than in December when this is relaxed to file on or before contractual pay date) and the pay date in field 43 which has always been (since 2013) is contractual if even if brought forward to the first non-banking day before the weekend/bank holiday and in December only regardless of how early pay is brought forward, recognising this common practice. It's a worry that this is still not understood but to the UC point. The regs were changed in November 2020 to require DWP to move the second amount of earnings to the period they are in respect of as a result of the Johnson judgment. see here for CPAg's very good summary: https://cpag.org.uk/welfare-rights/legal-test-cases/universal-credit-ass...

Thanks (2)
Replying to bassett1:
avatar
By Paul Crowley
10th Jan 2022 14:03

Much appreciated

Thanks (0)