Share this content

Sage50 payroll FPS error - FPS figure too much

Lost all client data, restored back-up but not FPS. New FPS sent but it included past months.

Didn't find your answer?

Hi,

For one of our clients there was some kind of issue and their data (Sage50 Cloud Payroll) was deleted. We managed to restore everything via a back-up except for the FPS (I'm assuming RTI data was not included in the back-up) and thought everything was then okay. However we didn't realise that the payroll would include the FPS liability for previous months (they had already been sent at their respective times) and so thus the liability figure included in this new FPS submission was essentially a lot more than it should have been (with the client appearing to owe money which they had actually paid.)

What exactly can be done about this? We're hoping the FPS data would include a date range within it which would be flagged up on HMRC's end (with them ignoring the amounts for the previous months) but if not can it be fixed by us calling HMRC, doing something with the FPS again on Sage50 or something else? Obviously we don't want the client to find out and would like to fix the issue with minimal mess and fuss.

Many thanks.

Replies (11)

Please login or register to join the discussion.

By williams lester accountants
24th Oct 2021 13:42

Have you tried Sage support?

Thanks (1)
Replying to williams lester accountants:
avatar
By ThomasMalcolm15
24th Oct 2021 13:44

Not yet. Would you imagine that this is a difficult issue to fix?

Thanks (0)
Replying to ThomasMalcolm15:
avatar
By Hugo Fair
24th Oct 2021 14:10

Only if Sage (which I don't use) has done something very strange.

An FPS has distinct data items for both 'this period' and 'ytd' values across most earnings/tax/nic/etc reported elements, so are you sure you're looking at the relevant items when you believe "the FPS liability for previous months" is being included?

And, yes, an FPS does include a date range ... but this is unlikely to be particularly relevant, as HMRC's systems are mostly interested in the YTD values (from which it derives, or cross checks, the this period values as the difference from the previous YTD values).
So sending an FPS with the correct YTD values should not cause a problem.

What will cause a problem is if the new/replacement FPS is for some reason using new PayID values for client's employees ... as this will result in new employment records at HMRC's end (generating 'duplicate' earnings that, with only one lot of tax being paid of course, looks to HMRC like a major underpayment)!

As you will have gathered by now, there are too many potential variables to be able to give a certain answer here ... but talking to Sage support would be a good first step (if only to ascertain whether there really is a problem) before setting off down the road to contact HMRC.

FWIW I've obviously no idea what "some kind of issue" led to your client's data (Sage50 Cloud Payroll) being deleted ... but it would be a good idea to understand how that happened and put in place measures to prevent it in future ... along with a documented routine to restore everything (including FPS/EPS files) if so needed.

Thanks (3)
Replying to Hugo Fair:
avatar
By ThomasMalcolm15
24th Oct 2021 14:35

To answer your first question I deduced it had duplicated because the FPS figures shown for this month are significantly inflated compared to previous months. There isn't any other way to explain the discrepancy.

Thanks (0)
Replying to ThomasMalcolm15:
avatar
By Hugo Fair
24th Oct 2021 15:09

But which "FPS figures shown for this month are significantly inflated compared to previous months"?
For instance: 'Taxable pay in this pay period including payrolled BiKs', or 'Value of tax deducted or refunded from this payment', or ... 'Gross earnings for NICs year to date', or 'Gross earnings for NICs in this period', or ...

And are these values "significantly inflated" for ALL employees or only a subset of them? If the latter, are there any factors common to that subset?

If you pick a few of the affected employees and look at their details, can you see a mathematical relationship between the amount that is significantly inflated over and above the value you would have expected (such as the YTD figures from the previous period)?

Unfortunately there are a lot of other ways to explain the discrepancy ... many of which will depend on exactly what was done to "recover" the lost data + some of which will depend on how Sage software reacts to those actions + a few of which are entirely dependent on how HMRC interprets what you've sent them (not just the various FPS files but also EPS files).

So ... you need to understand what actions were taken to recover your system - which in turn may affect what Sage advise you to do now. But if you can identify specific value errors, then it may also be worth contacting HMRC in order to find out what they want you to do to 'tidy up' any errors that have ended up in their systems.

Thanks (2)
Replying to Hugo Fair:
avatar
By ThomasMalcolm15
24th Oct 2021 15:21

What I mean is the figures shown on Sage50's FPS screen for the month. On Sage50 when submitting an FPS or looking at an FPS in the log it gives the employee name, NI number etc. and gives a single monetary figure for that employee. Those are the figures which I am talking about. Basically, you go back and look at the paper FPS records for previous months and the figures are all roughly in the same range (with a minimum difference) yet this month is radically different. If that makes sense.

As for your other question this is the case for all employees. All of them have significantly higher FPS figures than they usually have.

Thanks.

Thanks (0)
avatar
By DKB-Sheffield
24th Oct 2021 16:34

Out of interest, at what point in time (i.e. the payroll routine) was the (restored) backup taken? Was it after the prior period(s) update(s)? If not, how many pay periods have you processed (i.e. now) since the last FPS submission recorded on Sage?

You also state the figure is a lot higher. Is that double, triple (etc.) or is it more marginal? This may help you understand how many pay periods are included. If it's only marginal, there may be other calculation issues.

I also think your port of call is Sage Support but, you'll have a much quicker call if you can say "I had to restore back 2 pay periods plus current and the FPS figures are now treble the amount. What should I do" than if you say "I restored data and the FPS figures are wrong. What should I do?"

EDIT: Also, were your 'manual' reconciliation checks okay?

Thanks (2)
Replying to DKB-Sheffield:
avatar
By ThomasMalcolm15
24th Oct 2021 16:37

Hi, it was taken at the time of the previous month's payroll. Back-up taken, file updated, FPS sent. So when we restored it we only needed to update the record for that month and then change the processing date and begin with the current month's payroll. Realistically, it was all straightforward and issue-free (with the exception of the FPS issue).

As for the figures they are a lot higher. I would estimate they go back several months at least (maybe as far back as April if not further).

Thanks (0)
Replying to ThomasMalcolm15:
avatar
By DKB-Sheffield
24th Oct 2021 16:57

Okay. I strongly suspect a call to Sage is required - BEFORE submitting anything to HMRC. As Hugo has said, this maybe a problem with a duplicate payroll ID (which can cause no end of problems - particularly for employees receiving UC). Conversely, it may be nothing - Sage should know. It does however sound like there was some corruption in the data files that has not been reversed by the restore (i.e. may have existed before the most recent backup).

Incidentally, you say the current period payments (as opposed to YTD) may be as high as a full year's payment. Have you checked this against YTD figures to confirm if this is the case? I would certainly be doing this as it may help understand the problem!

Thanks (1)
Replying to ThomasMalcolm15:
avatar
By Hugo Fair
24th Oct 2021 18:40

"Realistically, it was all straightforward and issue-free (with the exception of the FPS issue). As for the figures they are a lot higher."

I'm getting more confused ... if everything (with the exception of the FPS) was issue-free, then you are saying that individual employees were processed with the correct gross pay for the pay period AND the correct Tax/NICs were deducted?
So the subsequent FPS (with all the 'higher figures') did not reflect the values from your processed payroll that period?

Also, you said previously that "On Sage50 when submitting an FPS or looking at an FPS in the log it gives the employee name, NI number etc. and gives a single monetary figure for that employee."
I don't know Sage50 but I do know RTI (too intimately for comfort it sometimes seems!) ... and I have no idea what this "single monetary figure" per employee represents.
An FPS contains over 120 discrete data items for each employee - of which in excess of 35 are mandatory within every FPS - so I would expect you to be able to see all these values. Which will be necessary for anyone trying to dig down and find out the nature/scale of the problem (which is not necessarily to be confused with the cause of it).

Good luck, you certainly need someone who understands RTI in depth who is prepared to look into your files (hopefully someone at Sage).

Thanks (1)
Replying to Hugo Fair:
avatar
By DKB-Sheffield
24th Oct 2021 19:25

Agreed regarding FPS. This is one of those times I'd be checking the full FPS/ XML submission file to cover off YTD values etc. - as opposed to what Sage (and other software) states is "an FPS"!

As with you, I don't have an 'in depth' regular working knowledge of Sage payroll software (just the odd non-managed client) so can't give details of how to get the full FPS. Others on here perhaps can? However, explaining how to reconcile it is perhaps beyond the realms of a public forum.

@ OP... if you're not sure what Hugo is saying about the FPS and RTI, I'd perhaps suggest a bit of reading around 'what RTI is'. If you know the basic mechanics of the system,you will know what the software is 'meant' to do and what then happens at HMRC's end. If you run multiple payrolls, knowing the basics (and how to check, reconcile and fix errors) will be invaluable. It won't stop software corruption... but it will help you diagnose issues!

Thanks (0)
Share this content