Member Since: 12th Mar 2015
7th Apr 2016
Do you realise how much impenetrable jargon you're spouting?
As someone who has been in IT for over 40 years but never bothered with any social media (preferring as per the previous post to deal with real people, face-to-face) ... I have no idea what you mean when you use words like "follow" or "unfollow" (or indeed "hashtag"). It's not the actual words that's a problem, just the underlying assumption that they have some sort of explicit meaning in the context that you've used them ... which may be true for you but not for all your readers!
The whole concept of 'tweeting' seems to be like people just randomly shouting out of windows ... for what purpose (let alone benefit to others) remains unclear. Since I understand that the number of twitterati (if there's such a word) is now in decline, perhaps it's time to look through the emperor's new clothes and start talking to live people (who have the option of telling you to your face what they think of your 'opinions')?
7th Apr 2016
Facts vs Recommendations
Just to be clear, I wasn't giving any advice (let alone recommending avoidance of paying via direct BACS) ... merely pointing out (in response to an earlier post in this thread) that IF you put a 'pay date' in your FPS that is AFTER the date when you actually paid staff then HMRC can automatically detect this IF you pay by direct BACS (and therefore 'BACS hashing' values are included in your FPS file).
CreDec is quite correct about the potential impact on UC claimants ... although not strictly so correct when saying "any mismatch .. means the employee claimant will be referred back to the employer". In the first instance, when a mismatch is found (not just of dates but of reported vs claimed earnings) DWP refer the anomaly back to HMRC - who may (not will) refer back to the employer for clarification.
None of this has anything to do with failing to report 'on or before' the pay date (or late reporting penalties). Indeed the closest I meant to come in terms of advice was:
* Don't put an incorrect 'pay date' value in your FPS if you pay staff via direct BACS, because HMRC can detect this automatically (without any human 'policing').
The pros and cons of using direct BACS - let alone whose fault it is that there is only a partial solution within RTI for tracking actual payments - are entirely different stories!
6th Apr 2016
But be careful if you pay employees via direct BACS
... because if you do then HMRC will know when the payments were actually made.
I too have clients who (anecdotally) report 'pay date' in the FPS as the final day of the calendar month, even though the payment was actually made on (say) the 25th. In our case the FPS submission takes place automatically once the processing is confirmed as 'complete' - and only at that point are the 'payment instructions' released, thereby ensuring that at least the 'on or before' rule is enforced.
However, my point is that if your client pays via 'direct BACS' (as opposed to say online banking) then HMRC are automatically notified of the actual payments (including the date) so have the ability to detect when that date differs from what was reported in the FPS.
6th Apr 2016
The short answer is No.
It is more than advisable to ask the questions (and record the answers) in order to justify which tax code you apply (until notified otherwise direct by HMRC) and whether to make Student Loan deductions (and if so for which plan type).
However it is the questions (and logic flow) that matters, not the physical makeup of the form ... which can be paper or electronic, and can be your own creation (so long as it incorporates the same questions).
1st Feb 2016
Wait for what's around the corner ...
The rules for SRIT in 2016-17 are so simple that it's hard to see from where NAO managed to get their £35m figure ... unless they've cottoned on to the 'killer waiting in the wings' - which Nick alludes to in his final 5 words ("for the 2016-17 tax year").
Wales has been promised (and so Scotland is now demanding) considerably greater control over their tax-setting powers ... specifically to be able to introduce thresholds (with associated rates) in any structure that they want - i.e. unrelated to what we're used to in rUK (aka the rest of the UK)!
So we can look forward to scenarios like there being 3 'bands' in England, 5 in Wales and 7 in Scotland ... with no correlation between these sets of bands or indeed the rates applicable to them.