Prepopulation feeds start to shine

Programming code
istock_monsitj
Brought to you by
gbooks
Share this content

The new prepopulation data feeds for self-assessment returns are starting to prove their worth. Various APIs allow accountants to access client data direct from HMRC’s system and, after a slow start, 2016/17 information should now be available for the majority of clients. Matt Bailey, founder of Gbooks, looks at the data available and how it can be used, in particular how the information on National Insurance can be incorporated into a client’s tax calculation.

In April 2017 HMRC started to roll out the main part of its data prepopulation service. The new feeds allow accountants to access the PAYE data submitted to HMRC for a tax year, along with information on private pensions, certain state benefits and whether a taxpayer is claiming marriage allowance as transferor or recipient. This data can be imported into a client’s tax return with the click of a button, avoiding the need for manual data entry and helping to avoid errors and omissions.

In addition to the fairly straightforward data on income, benefits and tax paid, HMRC also provides information on Class 1 and Class 2 National Insurance payments. This information can be used to help calculate the Class 2 NI contributions due for self-employed taxpayers, and also to calculate any restriction in Class 4 for taxpayers who had both PAYE and self-employed income during the tax year.

So what information is available on Class 2 National Insurance? HMRC provides those taxpayers who were self-employed (including those working via partnerships etc) with basic information on the Class 2 NI due, based on the number of weeks of self-employment and the weekly rate in place for the year. This amount may be scaled back if the taxpayer started or ceased trading during the year, or if they reached the state retirement age prior to the end of the tax year.

While it sounds simple, it’s worth pointing out some limitations to the data. Taxpayers have until 5 October following the tax year in which they first become self-employed to notify HMRC (and longer to notify about cessation). So it’s possible HMRC will not have the relevant start or end dates when the API is checked, and in some cases will give a different figure if checked in November to that given in April. So the accountant should check whether the figure is correct given the taxpayer’s circumstances.

So what information is provided on Class 1 NICs, and why is this relevant? HMRC provides the amount of earnings for Class 1 purposes that fell between the Primary Threshold and the Upper Earnings Limit. This information will not be available immediately at the start of the new tax year (unlike the basic Class 2 figure), but will be copied across from HMRC’s PAYE system between June and August each year.

This figure is relevant because it can be used to check whether the taxpayer’s Class 4 National Insurance liability needs to be restricted under Regulation 100. This regulation says that taxpayers who have already paid Class 1 NICs at the main rate should not also have to pay the full Class 4 rate (currently 9%) on the normal slice of self-employed income. They can instead scale back the Upper Profits Limit and start paying the lower rate (i.e. 2%) sooner than other self-employed taxpayers.

This is a fiddly calculation to perform, and relies on earnings information that is not always easy to compile, particularly for taxpayers with more than one employment during the year. But it can be worth the effort, with the relief lowering the Class 4 bill by as much as £2,500. So the availability of Class 1 earnings information via the API is welcome, and the accountant’s tax software can use it to calculate an accurate Class 4 NI bill at the time the tax return is prepared.

So where does this all leave accountants? The new API feeds provide new sources of information to make tax returns more accurate, reducing the chances of enquiries (and possible penalties) later on. But the API information will take a few months to become available each year, meaning a tax return prepared in October could be less likely to attract future penalties than one prepared in May. So does this give practitioners (and clients) an incentive to delay preparing tax returns until after the summer?

About Matt Bailey

matt_bailey

Founder of Aegia Cloud Systems (Gbooks), the leading cloud-based tax and accounts system.

Replies

Please login or register to join the discussion.

31st Aug 2017 08:36

Why does the banner graphic include code for manipulating vectors, which is nothing to do with tax?

Oh, in fact it's Blender python, so it's code for mirroring vector graphics in 3D space.

Thanks (0)
to SteLacca
31st Aug 2017 08:58

Weren't Blender Python an avant-garde dance troop in the 70s?

Thanks (2)
to TomHerbert
31st Aug 2017 09:21

It probably should have been, but sadly I think not (though I'm sure DJKL will be along to prove me wrong).

Thanks (0)
avatar
31st Aug 2017 10:06

Quote from above: Taxpayers have until 5 October following the tax year in which they first become self-employed to notify HMRC

I thought the limit was three months?

Thanks (0)
to newbaraban
31st Aug 2017 11:37

Since the HMRC site also quotes 5 October (whilst saying you should do it as soon as possible) then it would appear you were mistaken.

https://www.gov.uk/log-in-file-self-assessment-tax-return/register-if-yo...

Thanks (0)
avatar
31st Aug 2017 10:12

What about Student Loan deductions?

Thanks (1)
to leon0001
01st Sep 2017 08:50

That's another good one.

Thanks (0)
avatar
By raju m
31st Aug 2017 10:38

I think prepopulation sounds like a good idea. In practice I think it will solve one problem but create six new ones.

Thanks (1)
31st Aug 2017 10:50

I've been using the APIs for a few months. The main problem is that HMRC is only releasing the employment/benefit details as and when HMRC have reconciled that taxpayer's PAYE for 2016-17: when an API returns no data there's no way to distinguish between (a) a PAYE reconciled taxpayer who genuinely has no employment/benefits and (b) a taxpayer who has employment/benefits and not been reconciled. There is another problem.
There's another problem. The employment API returns details for each employment but the pension API returns a single gross figure for all pensions and a single tax figure. The Tax Return notes require each pension to be listed in the white space. Our software handles this by opening a table into which we input each pension individually: pension payer, reference, address, gross and tax, the software then lists this in the white space and puts the totals in page TR3. The API wipes out everything and replaces with totals only. We then have to delete the API data and re-input the original data. HMRC should issue API data which meets HMRC's own requirements for the tax return.
Despite the above problems, the APIs are a good step forward. We now need APIs for other areas especially CIS.

Thanks (1)
to kevinringer
31st Aug 2017 12:48

thats interesting, so all its really doing for employment/pension is "confirming the totals" from client paperwork. So we still have to ask 'em for it as usual.

This seems to just cut out the phone call to HMRC to check the total if the client has multiple employments etc. Which of course now results in a letter to the client.

Still all helpful in the long run, but the key really is to get the PAYE data in once the employer's RTI hits or it going to be next to useless for half the year.

Thanks (0)
to ireallyshouldknowthisbut
31st Aug 2017 13:25

ireallyshouldknowthisbut wrote:

Still all helpful in the long run, but the key really is to get the PAYE data in once the employer's RTI hits or it going to be next to useless for half the year.


Too true. I've been using the APIs since early June. The employment API didn't return any data until July. By the end of July it was returning data for about half the taxpayers I queried. It's now returning data for 90% of taxpayers. My understanding is that this is the pattern HMRC will be adopting in future. The tax return window is 10 months. So there will be no API data for about 35% of the filing window, 50% data for about 20% of the filing window and 100% of about 45% of the filing window ie less than half the filing window. HMRC has been "selling" MTD on the strength of the APIs in which case having data for less than half of the filing window is hardly something to shout about. The deadline for the final RTI EPS is 19 April so HMRC should be able to release the PAYE data on 20 April. I don't understand why HMRC won't release the API data until after the PAYE reconciliation. And if there is a good reason, why doesn't HMRC start the reconciliation on 20 April?
Thanks (2)
avatar
to kevinringer
31st Aug 2017 15:03

Yes I have exactly the same issue with the total occ pension figure overwriting the separate entries for each pension. But I have had many cases also where the HMRC download opens up a new employment schedule for what is actually a pension. I correct it but then get constant queries as to whether I want to add back the incorrect employment page. it is a helpful check that you have picked up all P60s and for clients who always lose them but does cause some extra irritation as well!

Thanks (0)
to debrahuzzard
01st Sep 2017 08:50

debrahuzzard wrote:

But I have had many cases also where the HMRC download opens up a new employment schedule for what is actually a pension.

I've run the API for about 100 taxpayers so far and not experienced this problem once. In fact our software, PTP, seems to handle employment very well: it will have b/f employers from last year and use them unless the API downloads an employer for which there is no b/f schedule when the software will create a new employment schedule. The only scenario that I haven't yet come across is where a taxpayer worked for the same employer for two separate periods during the same tax year and therefore would have two employment histories: I wonder whether the software will use two separate employment schedules or merge into one.
Thanks (0)
to kevinringer
03rd Sep 2017 13:38

I have just done one for this scenario (two separate employments with the same employer). And it totally ignored the first period and only brought in the figures for the second period.

And another one I did last week was for a payroll we run ourselves. We ran the payroll to the end of the year, and then realised that the person had left so re-sent the correct March 2017 FPS with zero pay/tax. The employer paid the correct deductions to HMRC and all seemed fine until I did the tax return, and it was pre-populated with the original larger amount. I spoke to them on the phone, and they were insistent that they had the larger original figure. When I pointed out that if that was true, they would have an outstanding amount of PAYE unpaid. She said it had all been paid up, so in one system, they had the correct figure, in the P60 bit, the wrong figures. She then told me that if you file 2 FPSs in one day, their computer simply chooses the biggest one. I was thinking at that point that she didnt really have a clue, and assume that has to be total rubbish, isnt it ?!

Example 3 is a director who we had to change when they had left, so we re-ran one month with zero-pay, but the tax return picked up the original erroneous bigger amount.

And I have had loads saying no pay found, when there obviously shoud be.

So basically their 'P60' details being uploaded onto the tax returns are highly unreliable and contrary to what they are telling people is going to lead to loads more mistakes.

Thanks (2)
to kenny achampong
04th Sep 2017 08:24

Very interesting experiences Kenny.
Example 1: have you discussed this with your software supplier to establish whether it is HMRC or your software?
Example 2+3: these are alarming. I've not had any amendment cases yet. HMRC need to investigate this. One way that it might get serious attention is to report it to your accounting body and have them escalate through WT.
The "pay not found" could be cases where HMRC has not yet carried out the PAYE reconciliation. I've previously commented that (1) we have no mechanism for distinguishing between clients for whom HMRC have not carried out the reconciliation [and thus not releasing any PAYE data] and those for whom HMRC have no data and (2) given employers have to file RTI there should be no need for a PAYE reconciliation and HMRC should release the data on 06/04/17.

Thanks (0)
avatar
By johnt27
31st Aug 2017 11:31

Personally I'm excited about HMRC's APIs.

I'm not a tax accountant so the benefits in terms of prepopulation are limited to my tax return but at least it brings us up to speed with some of our European neighbours who have had such systems for 10 years or more!

The real exciting benefits, I think, exist outside of the tax return system where switched on firms and other businesses can provide something else to their clients and prospects...

Thanks (0)
avatar
31st Aug 2017 13:20

I realise I'm swimming against the tide on this one and that I'm going to have to fall in line at some point but I'm swerving the whole API issue for this tax year.

Articles like this make me realise what a good decision that was.

Thanks (3)
avatar
to adam.arca
31st Aug 2017 13:33

Spot on. I've been swimming against the HMRC tide for years. I find it preferable to being swept out to sea and drowning!

Thanks (3)
avatar
31st Aug 2017 13:44

The Office is split on this,and I am very wary of pre population.When preparing tax returns,you have to be in control,mistakes are not admissible in tax and pre popultion does throw in a lot of guff.Also was it last week or the week before that HMRC went down for two hours.

Thanks (0)
avatar
31st Aug 2017 15:52

TRex Metal Guru

Thanks (1)
01st Sep 2017 08:53

What is the legal status if the API download is wrong? I had a client who received a P800 after his PAYE had been reconciled. I checked it and discovered one employment missing. I phoned HMRC. That employer had not filed their EPS until August after the PAYE reconciliation had occurred. That employer had filed RTIs but for reasons known only to HMRC they had disregarded the RTIs because there hadn't been a final EPS.

Thanks (1)
avatar
By mabzden
to kevinringer
01st Sep 2017 12:36

I would have thought you'll have a good case for claiming there should be no penalties if you relied on HMRC data and the data was either wrong or changed later on.

A bigger question is what happens if you don't check the APIs? I had a case last year where the client (a family member) got "confused" about his P60s/P45s and ended up with a penalty of £1,500 (it was quite a big confusion...).

In future can clients say OK, I may have supplied you with the wrong data but I'm an idiot and you're a professional accountant with access to HMRC's data feeds. How come you didn't press a button to check my figures and point out my mistake?

Oh, and here's a professional negligence claim demanding the penalty I paid plus generous legal costs.

Thanks (1)
avatar
By CptCave
01st Sep 2017 10:08

This is probably a silly question. If anyone is currently using the API's does it bring through private pension income as well as standard employment through PAYE?

Thanks (0)
to CptCave
01st Sep 2017 11:12

It brings through the total gross of all PAYE pensions and the total tax for all PAYE pensions. It does not bring through state pension.

Thanks (1)
to CptCave
18th Sep 2017 15:06

Yes it does.

Thanks (0)
avatar
to Kent accountant
18th Sep 2017 18:03

Exactly this was the first pre population data to fall in , presumably because they know what its going to be .

Thanks (0)
to Kent accountant
25th Sep 2017 14:16

I'm using PTP and the API still hasn't imported any state pensions. What software are you using?

Thanks (0)
avatar
to kevinringer
25th Sep 2017 15:27

well i use HMRC & Taxfiler . i use HMRC for pre pop info

Thanks (0)
avatar
By mabzden
to CptCave
05th Oct 2017 17:17

I realise you asked this a while ago but I've just used the API for someone with income from a private pension.

It brings through the name, income, tax etc in the same way as for a regular employment. You can then drop it into an SA102 form.

So the answer to your question is yes, and (I assume) the API provides details for each private pension.

Thanks (0)
to mabzden
06th Oct 2017 09:36

@mabzden what software are you using?

Thanks (0)
avatar
By mabzden
to kevinringer
06th Oct 2017 09:49

I'm using Gbooks.

That said, all software providers should be able to access the same data.

Thanks (0)
to mabzden
06th Oct 2017 10:08

Interseting that Gbooks downloads the individual pensions whereas most other software (eg PTP, BTC) downloads the totals only. Anyone got software other than Gbooks which downloads the individual pensions?

Thanks (0)
avatar
to kevinringer
06th Oct 2017 09:52

Using BTC here, I don't have many clients with pensions, but just downloaded the data for 1 elderly client and although my online agent shows a state pension, BTC didn't bring the figure through.
In respect of private pensions, he has 3, and the total gross and tax figures were drawn down, unfortunately no split between the 3 pensions so I've no idea whether it's picked up all 3 or just 2, or even just 1. "It looks about right" is probably all I can rely upon.

Thanks (0)