Save content
Have you found this content useful? Use the button above to save it to your profile.
Road map
iStock_yvon52_roadmap

Roadmap needed urgently for MTD ITSA

by

Time is running out to adequately test MTD ITSA and there is still no agreed roadmap to mandation, but Andrew Jackson has five alternative solutions to this conundrum.

16th Jun 2022
Save content
Have you found this content useful? Use the button above to save it to your profile.

The first mandation date for Making Tax Digital for income tax self assessment (MTD ITSA) is less than two years away. Sole traders and individual landlords with turnover exceeding £10,000 will need to comply with the MTD regulations from 6 April 2024. Remember, those taxpayers will have to report income and expenses under MTD on the tax year basis from 2024/25, whether they like it or not – and whether or not the software and systems are up to the job.

The process of reporting and agreeing profits/losses from an accounting period takes nearly three years to complete. For example, the accounting period ending on 31 March 2024 must be reported on the 2023/24 tax return by 31 January 2025, with the window for amendments to that period closing on 31 January 2026.

Limited testing 

There is a very limited MTD ITSA pilot running that currently involves just nine taxpayers. However, HMRC has just announced it will be expanding restrictive criteria for participating in the pilot from 6 July 2022. 

Those taxpayers in the pilot will make their last quarter report for 2022/23 by 5 May 2023 and submit their end of period statements by 31 January 2024, just nine weeks before mandation. They are the only people in the country who will have had a chance at practising all the MTD filings before they’re legally obliged to make them.

Put bluntly, there is not enough time for us to be sure that MTD ITSA will work.

What are the solutions? 

Here are my suggestions for resolving this MTD problem.

1. Delay mandation

This is obvious: as MTD ITSA has already been deferred or delayed at least four times (from dates in 2018, 2019, 2020, 2023), what harm would another year do? However, for exactly those reasons, it seems to be the least likely solution to be accepted by HMRC or government.

2. Accelerate testing 

Test the MTD ITSA principles using complex data within a simulator – a sort of second life for MTD. This would not test the interaction of MTD and other tax systems, but neither does the current pilot. 

3. Run in parallel

This would involve a hybrid of MTD ITSA quarterly reporting and the current tax return system, such that taxpayers submit quarterly updates but also include their annual accounts as now on their current self assessment return. It would however highlight the fact that quarterly reporting is irrelevant to the return process, and so would probably also be unacceptable.

4. Delay the EOPS

The HMRC developer hub reports that the Application Programming Interface (API) to submit the end of period statement (EOPS) is in production. What is not clear is whether those few businesses who have been within the MTD ITSA pilot since 2018, have actually completed the process by submitting an EOPS (I have no evidence that they have, but may have missed something). If the quarterly reporting can be separated from the EOPS, leaving more time to develop the EOPS process, this might ease the pressure a bit – but does appear to devalue the quarterly reporting.

5. Scrap quarterly reports

It seems to me that the quarterly reporting has become an end in itself and the original purpose of MTD ITSA has been lost. The essential part of the tax process is the EOPS, plus the finalisation report, which replaces the tax return. The quarterly reports are not needed to calculate the tax due, but the EOPS absolutely is. In my opinion, the correct response is to scrap the quarterly element and concentrate on the EOPS.

Core reason for quarterly reports

HMRC see the key reason for requiring quarterly reporting (for any tax) is to ensure that the accounts are digitised. Thus, the main benefit of quarterly reports is that obliges the business to use accounting software.

This may or may not be a good thing for small businesses. Using accounting software would, in my view, impose a discipline on the business’s tax reporting, but it is not necessarily the best way to provide assurance that their tax returns are complete. 

This objective could be better achieved by broadening the obligation for businesses to show they have a robust accounting process. Adopting accounting software is an easy way to demonstrate this, but allowing alternatives that meet the same quality assurance criteria would remove many of the problems associated with MTD while still achieving the goal.

Where is HMRC’s roadmap? 

The current MTD roadmap (discussed with the Chartered Institute of Taxation but not published by HMRC) allows for only simple forms of the EOPS to be tested by the few taxpayers who are currently in the pilot. 

This is not good enough. We need more complex tax profiles to be tested before mandation so that the system can be adjusted. My suggestions above would provide more time to do this. 

More importantly, taxpayers and their agents need to know what the timeline is. A new accounting system is a major change for a business: it needs to be planned well in advance, and it takes time to do. How many clients does a typical agent have? Between now and March 2024 they all need to move over to accounting software. 

That’s what, 80-odd weeks? If you have 80 clients then you can get them ready for MTD if you start now, you know what they need to do, and you can take each them through the whole “customer journey” (in HMRC parlance) in a week. On top of your normal workload.

If you have more than 80 clients, or you can’t spare that time, or you can’t start now, then you have a problem.

To start the journey, we need a roadmap.

Replies (56)

Please login or register to join the discussion.

Replying to kevinringer:
By Charlie Carne
20th Jun 2022 10:00

I agree completely with your first sentence in point 2, but that's an argument about syntax, not the system. Whether 'T' stands for tax or transactions is not important. As for the difficulty in complying, my experience suggests that this is not as great as many suppose. There is no requirement to check the data submitted each quarter, so we just need to link their bank to an MTD-compliant system (eg Coconut) and click the 'submit' button once quarter. As I said above, it's not about accurate in-year data, but "about checking at multiple points during the year that the business is using and updating its digital systems".

I also broadly agree with you that MTD is unlikely to improve accuracy. It will for some but not for others. That was always a silly reason given by HMRC, who should always have sold this solely as a means to make data more easily interrogable (by HMRC). This was always for their benefit.

Thanks (0)
Replying to charliecarne:
Morph
By kevinringer
20th Jun 2022 10:32

charliecarne wrote:

There is no requirement to check the data submitted each quarter, so we just need to link their bank to an MTD-compliant system (eg Coconut) and click the 'submit' button once quarter.


Really? Just import and submit? No manual processing of those transactions?
Thanks (0)
Replying to charliecarne:
Morph
By kevinringer
20th Jun 2022 09:45

charliecarne wrote:

The reasons, I suspect, for wanting systems to be digital is so that, in the long term, HMRC can interrogate the data both easily and remotely, eventually allowing algorithms to automatically check all data and even potentially cross-referencing the supplier and customer's record of the same transaction.


If this was truly HMRC's goal, they've got a very long way to do. Currently, if HMRC want to carry out a VAT check, HMRC can't handle the data or software. If HMRC wanted this goal they should have set a standard data format at the outset so that all accounting software data is stored in that format the the different software suppliers basically sell the business an interface and functionality to access and process that data. That way HMRC would then be able to interrogate the data because everyone would use the one format. The other advantage is if a business wanted to change software supplier, there would be no need to convert data because all suppliers would use the same structure.
Thanks (0)
Replying to kevinringer:
Tornado
By Tornado
20th Jun 2022 09:56

This was the most logical way to approach MTD as I pointed out some years ago -

https://www.accountingweb.co.uk/any-answers/universal-software-goverment...

I also had something to say about the original Pilot -

https://www.accountingweb.co.uk/any-answers/400000-guinea-pigs-any-news

Thanks (1)
Replying to kevinringer:
By Charlie Carne
20th Jun 2022 10:13

kevinringer wrote:

Currently, if HMRC want to carry out a VAT check, HMRC can't handle the data or software.

The answer is API's. If Dext Precision or Futrli or a whole host of other tools can extract meaningful data from Xero, QBO, FreeAgent, etc., then so can HMRC. There is no need to mandate a single format for all software houses to use. And, if they did, that would stifle competition and innovation.

Thanks (0)
Replying to charliecarne:
Andrew Jackson
By Andrew Jackson
20th Jun 2022 13:18

I think you're right about HMRC's aspirations, but 'what HMRC wants' and 'a sensible tax system' are not necessarily the same thing.

I'm aiming for something workable that makes life easier. Over-engineering a process tends to cause problems on both those counts.

Thanks (0)

Pages