Member Since: 27th Jul 2012
25th Jan 2018
All this sounds good/bad depending on one's viewpoint.
The AI 'learning' aspect is fascinating. Machines neither 'think' nor 'learn' (not yet, anyway) so instead currently rely on their programming to decide the action to take. They will need lots of information and experiences and indeed coding to enable a choice of actions. There are huge practical problems that will have to be overcome. And we shouldn't overlook that an accountant or other service provider may have a liability to their clients if they give incorrect advice.
The robot you've outligned is surely no more than a bot that will sift queries / messages and deal with those which are 'simple' (eg ask for more information) or refer the matter for resolution by a higher intellect (the accountant?).
29th Jun 2017
Thank you for this Kate. I have tended to 'delete' all HMRC emails about webinars - so missed this one which sounds like it was really informative.
Certainly my own move onto receipt of the state pension has revealed how HMRC allocates my personal allowance.
HMRC's tax coding systems were never perfect. And I suspect that there were many errors leading to under and overpayments of tax.
I remember the days when tax relief on mortgage interest was provided via tax codes...with the huge numbers of coding changes occurring several times a year.
And with the baby boomers increasingly moving into receipt of pension payments from two or more sources this is inevitably a potential source of coding errors for HMRC.
And of course many individuals have two or more sources of earned income nowadays.
I wonder whether overall HMRC is better today with issuing coding notices than it was say thirty / forty years ago?
11th May 2017
"HMRC's quite complex" national minimum wage regulations?
Hmm, the regs are not HMRC's but are those of the former trade and industry department (or whatever its name is today).
HMRC has the task of NMW enforcement.
19th Jan 2017
"Flawed real time information (RTI) from HMRC’s payroll systems"
That text may be correct...but I'm presuming you mean 'from HMRC's PAYE systems'?
2nd Nov 2015
PAYE in meltdown
The plan for RTI was imposed on HMRC but in my opinion it was too ambitious and unrealistic. HMRC had an implementation deadline to work to in order that earnings info would be instantly available to the DWP for purposes of UC payments to claimants. Well, UC also had an utterly unrealistic overly ambitious plan - and remains it would seem many years from roll out (if ever) across the UK.
In addition, HMRC has been subject to headcount reductions - again imposed by the Treasury.
It seems to me highly probable that HMRC senior staff warned the Treasury against unrealistic plans for RTI and headcount reductions.
The blame for this shambles rests in my opinion with Treasury ministers.
15th Jun 2015
HMRC's RTI system - filing expectation
You're right to draw attention to the problem with how this filing expectation works.
I imagine that many employers (and their payroll systems) are unaware a FPS is required each pay period for each employee/pension recipient and think that all they need to do is send a FPS file containing FPS records for those actually paid in the period. This misunderstanding may in part derive from HMRC persistently referring to the FPS as though it is a file rather than a record for each person.
Perhaps employers should consider requesting a new PAYE scheme to distinguish between those with different payment frequencies?
18th Mar 2015
What a mess!
I also have been told by an HMRC call centre operator to ignore the entries on the dashboard. To answer my query about a specified charge the operator looked at the actual entries held by HMRC which were different to those shown in the dashboard.
Specified charges arise where no RTI return (FPS or EPS) is submitted for the PAYE scheme for a tax month. Once on the system these SCs have the potential of causing mayhem in the dashboard, and HMRC's debt management department will pursue payment for it even though a payment made for the scheme will partly or fully extinguish the SC entry. Avoid SCs!
As regards UC, RTI and BACS, I'm in the HMRC camp with this. If it's ok for non-BACS payment to be passed to DWP and accepted for purposes of UC what makes a BACS-hashed supported RTI return better for UC purposes? Surely the RTI data in the FPS returns is what is important?
2nd Mar 2015
The problem with DDs
What I wonder would be the reaction of employers were HMRC to operate a DD and take too much/little? If their ETMP is useless and the data unreliable...
2nd Mar 2015
Kate, great article.
I suspect some of the problems with HMRC's RTI systems is that these were designed by people (software developers etc) who really had no concept of practical issues.
And there is the duplicate records issue which has been known about by HMRC for many years but the real implications of this were not recognised. This issue has not been resolved.
HMRC introduced ETMP to replace its old accounting (debt management) system probably in order to support/deliver the non or late payment penalty regime. The recent announcement that the regime has been put on ice (perhaps indefinitely) suggests to me that the ETMP is incapable of fulfilling its purpose.
It seems to me the ETMP a least for PAYE purposes is inoperable, so I doubt that HMRC can identify employers who are not paying fully on time. This would surely be a fundamental failure of its duties by HMRC.
The abolition of the annual P35 return which set out the PAYE scheme's tax etc liability can be seen I think as a serious mistake. This return worked for employers and HMRC.
13th Feb 2015
A definition of RTI BACS / "BACS"
CreDec, I notice in the article you refer to here, you again imply that using Bacs can prevent an HMRC automatic penalty for late filing. There is no linkage (currently) between Bacs submissions and RTI penalties for non- or late filing, that I am aware of. It is the non or late filing of the FPS which will lead to a penalty, so irrespective of whether a Bacs record with the random string has been submitted and received by HMRC, the onus will still it seems to me to be on the employer to demonstrate the FPS has been sent 'on or before'. If you know differently please advise.
Indeed, if we take this a step further, HMRC has issued guidance that where a pay day falls on a non-banking day (e.g. 6 April 2015) the normal pay date is to be shown in the FPS even though the payment may be delivered on a preceding bank working day (e.g. Thursday 2 April). Inevitably in these cases the Bacs records and the FPS records will bear different dates, but this is ok for HMRC as it is the FPS which they will use for late filing penalty purposes.
In your reply above you say "HMRC and DWP have confirmed that the only way for DWP to receive net earnings values, as paid, in their own systems so as to manage claimant queries is if their employer is hashing."
This is surely incorrect, as there are many employees who are paid other than by Bacs. There must therefore exist a channel by which HMRC supply data to DWP which meets requirements for UC. Indeed, a Bacs record is not of itself an indicator of an employee's (or pension recipient's) net pay as the employee may have their net pay split with different pay methods used for each. Moreover, the employee may have savings or other 'non-allowable' deductions made, with the residue of earnings paid as net pay. Another issue is that the employer might in some circumstances make a payment outside of the payroll and simply adjust the year to date figures for tax and NICs etc in the next FPS. Unless HMRC's system picks this up by checking the YTD movements and includes it in the data supplied to DWP, the latter will not know about it at all from Bacs records as these will not exist.
I'm sure you're also aware that there is a HMRC specification for the FPS data which is in part intended to identify an employee's 'real' net pay.