I have a client paid a monthly salary denominated in a foreign currency so the salary changes each month depending on the exchange rate used by the bank. The February salary was not paid in February, so we submitted a no payments report for month 11 to avoid a non filing penalty. The February salary was paid in the first week of March. As an RTI submission has to be made on or before the salary payment, an RTI submission was made in the first week of month 12. The March salary was also paid later in March but the software won't allow a roll back or any way of updating or amending the earlier March submission. We have been told to to roll forward to the next tax year and wait until after 19th April to submit an Earlier Year Update (EYU). Is there no way round? What would happen if we used alternative software to submit an additional month 12 submission or would that be rejected by HMRC?
Replies (25)
Please login or register to join the discussion.
What payroll software do you use?
With Moneysoft, for example, you can easily re-open a period, make amendments and re-submit an FPS. Even if you have already marked your early March RTI submission as the final one for the tax year, you could re-submit a final EPS for 2017/18.
It is certainly possible in Payroo to re-open a submitted period and alter the figures in it (eg adding a bonus) and re-file them. I can't remember the exact procedure for doing this, but it should just be a case of finding the appropriate menu options. I did this recently for a non-profit that I volunteer for who wanted to re-run a previous month where the AE calculations had been done incorrectly.
However this (and the suggested Moneysoft solution) aren't quite what you really want to be able to do. In a perfect world you would do a "supplementary run"; add the additional payment to an employee at a later date to the first payment, and in the tax/NI/pension/etc calculations the previous payment in the month would be taken into account as if both payments were being made simultaneously. There is payroll software on the market that can handle this kind of thing, but such packages tend to be very expensive (a couple of orders of magnitude more than the likes of Moneysoft and Payroo) and very cumbersome for the types of payroll scheme typically operated by AW members.
I don't believe the advice you got from their helpline is correct. When I rolled Payroo back and re-ran the periods it certainly *behaved* as if it was submitting the RTI again with the revised correct figures and it would be very misleading if it weren't actually doing so. Indeed if it doesn't do so I would regard that as a bug in the product that Payroo ought to fix! If a rollback doesn't ultimately result in an FPS resubmission I'd argue that there is then no point in the rollback functionality being available.
Thank you, I will try rollback and see what happens.
I think that is a good idea. Even if I am wrong (yes, it has been known where other people's software is concerned
;) ) then all you have to lose is the time you spend doing the rollback and recalculation.
The roll back worked perfectly calculating the correct figures until I tried to submit it to the Revenue and then I got an error message saying that no payroll data had been found. I tried changing the frequency to annual, and to weekly, but it would not submit. Back to the drawing board, but many thanks for your help.
Bizarre; the strangest thing about that behaviour is that there would literally be no downside whatsoever to submitting the same data again, even if nothing had changed, and everything to gain from submitting the data again if something *has* changed. Resubmissions are one aspect of RTI that the HMRC processing system actually handles very well!
Star will handle supplementary pay runs in this way, but is insanely expensive for small practitioners, and is more aimed at larger bureau.
Star will handle supplementary pay runs in this way, but is insanely expensive for small practitioners, and is more aimed at larger bureau.
Likewise Pay Right, which is completely out of the typical price range of small practices and bureaus.
And, indeed, Bond Payrite - which is one of the fastest (though quirkiest) payroll packages I have ever used, but also insanely expensive for small practice.
I downloaded the HMRC Basic PAYE Tools and submitted another FPS from there which seemed to work so hope everything goes through ok now.
There is an unfortunate potential pitfall with this solution. Did you make sure that the RTI ID of the person on the FPS was the same in both pieces of software? If you don't there is a design bug in RTI which makes it *by default* treat such filings as if the person had 2 completely different jobs in the same PAYE scheme, and all the cumulative payments and cumulative PAYE/NI liabilities for that person will end up being doubled up.
Sorry but could you elaborate on what is meant by "RTI ID"? Thanks
In Basic PAYE tools it is called, "Payroll ID", part of the employee details.
I think in Moneysoft it is the employee number, though a Moneysoft specialist can probably tell you more about this. From memory Moneysoft allows that field to be left blank.
These need to have the same value in both systems. Since you'd already filed details for that employee using Moneysoft you should have entered the same employee ID in basic PAYE tools.
Has the employee lost out by you submitting nil for Feb?
I would put the March pay in Feb and resubmit that since then you have one payment per month. You will have to find another way to get round the exchange rate issue so you can submit on time each month.
Sorry Caroline this crossed with your reply saying you could not change Feb or March. Maybe Tom or Euan will come back with some other suggestions since they are the experts.
If you used Month 12 for the first run then the employee would have had the benefit of two lots of allowances etc and received a much higher net pay than usual.
Logically, there is nothing wrong with the payroll so far so nothing to amend.
You would then need to run a month 13/week 53 submission for the second payment in the month. How would your software cope with 4 weekly or week 53 payments?
It doesn’t help you now, but I have a client who’s payroll date is the 4th working day of the new month. I know, crazy. Could be 4th, could be 6th, which means in theory I could quite easily have 2 paydays in 1 period. If it’s 6th, I have to date it 5th as Moneysoft can’t deal with 2 payruns.
It doesn’t help you now, but I have a client who’s payroll date is the 4th working day of the new month. I know, crazy. Could be 4th, could be 6th, which means in theory I could quite easily have 2 paydays in 1 period. If it’s 6th, I have to date it 5th as Moneysoft can’t deal with 2 payruns.
Even if Moneysoft could deal with it, your client wouldn't like the results. It would cause over-taxation problems where employees had non-cumulative tax codes, and you would get bizarre NI effects due to some months having double pay and other months having none. Depending on the level of employee pay it could result in employees either paying a lot more NI than necessary, or a lot less than monthly pay would indicate.