Spreadsheet accounts at risk in MTD ITSA plans
HMRC’s iterative approach to Making Tax Digital for income tax software specifications is raising concerns within the profession that key principles and legal conditions - including the use of spreadsheet accounts - are being left behind.
You might also be interested in
AccountingWEB’s Editor at large has been with the site since 1999, rising from news editor to editor in chief, global editor and head of insight. As a roving editor, he continues to investigate the profession's use of technology around the world. He devotes his spare time to technology history and an oddball collection of stringed instruments...
Replies (61)
Please login or register to join the discussion.
As has ever been the case, there is no way to know what we will be required to do and I don't expect to find out until 6-8 weeks prior to the system becoming mandatory.
My only real choice here is to worry about it or not worry about it, there's nothing useful to be done other than help those clients who can and want to use digital bookkeeping systems to get set up. Those others who keep records as spreadsheets or on paper will have to wait until we know what's going to be delivered before we can make a plan.
HMRC gets what, six years so far, plus another two to decide what they're doing and we won't know for sure until a couple of months beforehand what that is, what's required and how best to address it.
If HMRC were a commercial organisation with competitors, their shambolic approach to everything would have seen them out competed years ago, this is no way to run a project, no way to deliver software and is completely unreasonable.
This is also shaping up to be the exact same process we went through with VAT though I suppose at least this time we know how it's likely to go; HMRC will announce in advance all the myriad things businesses will have to do to comply, then scale back and scale back what's actually deliverable and then the system will be reduced to filing a small list of numbers through a slightly new web portal and the rest will be pushed back until half past never.
Couldn’t agree more Duggimon!
It especially irritates me when I cannot see any gain either financially (other than for software companies), or in regards to accuracy or time consumption.
To me it’s a complete unnecessary farce!
MTDv wasn’t as bad as those clients were larger and had good accounting systems, including excel spreadsheets in some cases, but having to get a taxi driver, for instance, computerised is going to be a total waste of time, effort and money for no gain as far as I can see.
Quite right - it’s almost as though HMRC are completely unaccountable to anyone . . .
On the VAT - yes what a joke! I worried about it for ages and deferred signing up until they started talking about penalties. Now I enter the four VAT figures from my Excel on a third party website which submits them to HMRC thus satisfying the much vaunted “digital link” requirement. An unbelievable palaver for zero benefit as far as I can see. Can’t wait for the Income and Corporation Tax rollouts!!!
Thank you John for finally joining the same choir (i.e. singing from the same hymn book), although you've not sufficiently focussed on the two key 'errors':
1. Development plans (for software and/or processes) only ever work when the whole journey has been specified in advance ... it is unbelievable that we (and apparently HMRC) still have no overall specification; and
2. Agile is a term best reserved for a cat on a hot tin roof, as it is solely concerned with immediate short-term 'wins' without a strategic bone in its body.
FWIW 'agile' is my bête noire in that it's been purloined by those extracting cash by the lorryful from HMRC, who don't understand its applicability to disposable (short shelf-life) apps doesn't translate to infrastructure (long-term) system architecture.
The best (lack of) insight I've heard into the weakness of agile as a concept was when I asked one of those big consultancies the following:
"If I asked you to design the optimum method for me to get from London to Edinburgh, would you expect me me to be happy if your answer was ...
... First we'll design a procedure for putting one foot in front of the other without falling over?"
"Well it's a reasonable initial response - and it's quick to do & test"
"So you might characterise that as 'agile' development?"
"Yes, indeed"
"But I forgot to mention that I meant London, Ontario ... so how does that help?"
"Well because it was quick & cheap to develop there's not much wasted is there!"
Me ... "But we've still not actually started the journey ..." (blank looks all round)!
I feel compelled to observe that there is no aspect of HMRC’s cumbersome and poorly thought out MTD project which could possibly merit the adjective “agile” - and indeed least of all the organisation itself!
Its use of the methodology is also questionable as I find so many large companies use the terminology but with very little adherence to the principles.
I fully agree with your statement " Development plans (for software and/or processes) only ever work when the whole journey has been specified in advance ... it is unbelievable that we (and apparently HMRC) still have no overall specification"
However I beg to differ when it come to the use of Agile which I have used extensively in my last years of work before retiring
If done within an overall business architecture, project scope and overall plan it is an excellent way of focusing on key benefits and delivering them early.
The big issue with MTD ITSA as I see it is the total lack of clarity of the end of year processing something that should have been sorted out ages ago.
The information in this article is very confusing and misleading. Spreadsheets are entirely acceptable for digital record keeping, and bridging solutions are very welcome by HMRC. Please read here if you need a summary of the Making Tax Digital for Income Tax process: https://vitaltax.uk/income-tax/. If you have any questions, we are happy to help.
The vitaltax link contains the statement: "Final Declaration (Crystallisation): Once all the necessary quarterly and annual information for all income sources is submitted and all EOPSs are provided, taxpayers will need to finalise their overall tax position for the tax year by providing a Final Declaration."
The SA tax return comprises 30 sections of which 90% is not related to Self Employment or Property Income. Some are complex such as CGT and Child Benefit for higher rate taxpayers. Some are inter-related to other sections e.g Date of Birth affects the NIC parts of Self employment and Partnership. Most filed have associated help text some which has to be modified each year to reflect the financial values appropriate for the current tax year
What is vitaltaxes' solution to submitting information not related to Self Employment or Property Income?
You will be able to provide data for all income sources using VitalTax. These include employment income, bank and building society interest, dividends, capital gains, etc. You will be able to configure your VitalTax account to include any non-business income sources that you want to declare.
Thank you for the quick response
Will the complex end of year processing provided by VitalTax also run alongside bridging software so enabling clients to maintain their existing spreadsheets?
Why do my clients need full blown double entry bookkeeping software for their little rental property from which they receive £850 rent per month and no "business bank account". They have been very happy to let us sort annually (accounts prepared in spreadsheets) up until now????
Especially when the only/biggest expense is mortgage interest, when they only get one statement pa in September. And good luck to HMRC explaining to them why the profit ignores the interest (which they have probably overstated by entering the total repayments anyway) because we certainly won't have time to check and file the figures and also attempt to explain restricted mortgage relief to them all. And presumably HMRC will still be operating 'telephony shuttering'.
It is the sole responsibility of HMRC to make MTD work, not ours or even the Software Developers.
A very good article John, and you have highlighted once again just how farcical this project is.
As far as I am concerned, I am thoroughly fed up with the whole thing and will only take it seriously when HMRC have developed and tested the complete MTD Systems and all we have to do is join up our clients and go.
In the meantime, my clients have far more important matters to cope with than MTD and I will be concentrating on helping them with these first.
I wasted enough time on the George Osborne project. Dread to think how many wasted hours. Won't be bothering until last minute now, as you can be sure the 2024 deadline will be pushed back or watered down a considerable amount.
Just to be clear, the process for delivering large projects involving multiple software systems talking to each other is, broadly:
Define your API - this defines exactly what information and in what format can be passed between the different software systems, and what functions one can request the other performs. This is a set of immutable rules sitting between systems so that the different designers involved don't need to know the intricacies of each other's systems.
Then, and only then, design your separate software systems with this API in mind, knowing what is available and what restrictions are in place.
HMRC have set the date for when businesses are legally mandated to use this new system, but have not yet completed the first step. It is currently impossible for anyone to design a system that will comply with the new procedures from April 2024 because they haven't decided on them. The software companies involved do not yet have a set of specifications to work from.
It is no wonder there are no bridging solutions in place, bridging solutions are simpler to design and implement and it would be a waste of time and effort to design one now to comply with what HMRC think the system might do but they haven't decided yet.
It is no wonder there are no bridging solutions in place, bridging solutions are simpler to design and implement and it would be a waste of time and effort to design one now to comply with what HMRC think the system might do but they haven't decided yet.
We have already built a spreadsheet bridging product available for you to use if you sign up for the HMRC MTD for Income Tax pilot. We are working on the demo version, so you will be able to try it before committing to the pilot.
Who in their right mind would want to sign up for the MTD for ITSA Pilot???
Apparently only 9 people have signed up and stayed in the Pilot and it seems they were all associated with software developers
https://www.accountingweb.co.uk/any-answers/only-9-people-are-in-the-mtd...
This is a lost cause
We have many customers who showed interest to sign up for the pilot. The difficult part is very strict HMRC eligibility criteria for who can join the pilot. Unfortunately, many taxpayers and agents are waiting when they will be eligible. The eligibility criteria should be significantly widened next April, and we expect many customers will be joining the pilot scheme.
To get meaningful results you would need at least 100,000 in the Pilot covering all conceivable scenarios. That is a long, long, way from just 9 at this stage.
It beggars belief that they can expect such a big project to launch in 2024 when there's only NINE taxpayers involved in the beta
Just looking back at some of my past posts, I see that 4 years ago HMRC were expecting 400,000 people to sign up for the Pilot!
I attended a HMRC MTD meeting in 2016 when HMRC said they expected several hundred thousand (I thought it was 800,000) to volunteer for the pilot. They now have a mere 0.001% of their anticipated numbers in the pilot. Even HMRC must realise that is not meaningful. And to think in the early days HMRC even argued MTD would be cheaper for businesses than their existing record keeping systems. If that had been true then they'd have had millions in the pilot.
Designing the APIs is important but needs to be done in the context of an overall business architecture and set of overall business rules. I have yet to find a statement where these have been defined
You can find the HMRC business service guide with a detailed description of how each API will be used here: https://developer.service.hmrc.gov.uk/guides/income-tax-mtd-end-to-end-s...
I have read these APIs in detail. They do not define how things work only what data flows between systems.
The end of year processing, if it replicates everything already in the current system, is probably 80% or more of the build and 90% of the user training effort but nobody really know how the end of year processing is going to work
This work started 5 years ago and there are two years to go; we have used up 75% of the time.
I have worked on many large business system changes and have never been on a project where is has been so difficult to find how things work from a business perspective.
The APIs merely deal with the transfer of data between the software and HMRC. As this is the only aspect of the software that directly impacts HMRC, the APIs are the only aspect that HMRC are interested in. From a user's perspective, the APIs are irrelevant. The user is more interested in the interface and functionality of the software itself: how easy is it to use, how robust is it, does it have the prompts and nudges HMRC said it should, is it intelligent enough to avoid mistakes (in other words, is it "idiot proof"). All these points will dictate how accurate the data is so in my opinion are crucial to making MTD a success or failure. HMRC says all this is not their concern, yet they should be concerned because none of the software I have used has any intelligence at all. For example, software will let you reclaim VAT on outgoing that never have VAT on them such as wages, drawings, even the VAT payment itself. HMRC expect the software to be used by the likes of Joe the Plumber with no training and no bookkeeping knowledge. How can Joe achieve accuracy if there is no intelligence. The APIs are irrelevant for all this.
I'm sorry, but that is an out and out clickbait title. There's nowhere where it says spreadsheets are at risk. Even a software supplier says so further above my post!!
I think this underlines how far away we are from it become mandatory.
The key question on updating prior quarterly returns is "why?" . Given the quarterly junk numbers coming out of client bookkeeping has no relation at all to the real year end figures on the tax return, how is anyone going to know if something has changed in the middle? Are HMRC really going to audit this? If so for what purpose? They would be quickly bogged down in accounting adjustments as well as bookkeeping ones. And even if they find differences, so what? There is no underlying purpose for HMRC for the quarterly filings, nor the tax payer other than the anticipated quarterly tax payments which again wont work in practice other than high level "payments on account", which is all that is likely to happen unless the entire tax system is made 3 monthly and not annual. I dont think even HMRC are that mad.
HMRC abandoned trying to check the rather basic question of turnover in VAT returns to turnover in accounts or SA returns some years ago as it was a lot of effort for them, and didn't seem to be any point, not least as the staff (even back 10 year ago) couldn't get their head around basic accounting adjustments such as accruals and prepayments. This was before they have been further deskilled. So where is this army of staff to check the much more divergent data?
I am rather old school. I believe that if you have a manual system with use of software as appropriate and that system has been in use for 20 years or more why should HMRC wish to risk the chance of errors within the Accounting records which Taxpayers are going to be forced to use. Whilst I realise Exemption might be a route out of this nightmare scenario , the process is time consuming and long winded. If a spread sheet was used to keep Accounts and then complete year end calculation surely many would fall at the first hurdle of they had little or no knowledge. If a product such as Sage or Xero was used then a key happy novice would most likely make errors. Further errors would be made. I noticed one of my former clients who used the Government free SA tool has included a £12500 bounce back loan as "other trading receipts". This is just one example of hundreds I could list. Since the 1980's Sage has been around so why has it taken 40 years for HMRC to decide on this next step and why is a system not in place to deal with MTDITSA that works now and not in a few years. MTD4VAT isn't proved to work and is completely different to MTDITSA which is more complicated. HMRC please listen before its too late.
Your thinking is not particularly old school, it is just common sense that even my 5 year old granddaughter could work out.
This happens to me all the time. Clients who kept excellent records on spreadsheets got suckered in by THOSE adverts and I get a pile of cr*p at the year-end
This happens to me all the time. Clients who kept excellent records on spreadsheets got suckered in by THOSE adverts and I get a pile of cr*p at the year-end
My blood boils every time I see THOSE adverts!
“Take a photo, bish bash bosh, job’s a good-un”
Brilliant .... now was that -
* Sales Income
* Sales Credit
* A Grant
* A Bounce Back Loan
* A loan from your Auntie
* Tax Refund
* Rental Income
* Someone paid you in error
* Purchase Credit
* Repayment of a loan you made to your Son
* A Birthday present from your Great Aunt
* VAT Refund
* Refund of Bank Charges
* An insurance premium refund
* An insurance claim (excluding the excess but including VAT)
* Sale of a car or van
* Sale of Equipment
* Lottery Win
Still it is nice to know that the software will be able to allocate any of these receipts correctly all by itself just from the photo. Isn't this modern software just wonderful
Some of the cloud product users had amazing profits last year when the BBL was added to income......they totally BOSSED it (c) Sage. That's a politer version than what I called it.
I shout at the screen, usually expletive driven insults. It somewhat alarms my other half but at least it stops my anger building up unreleased. I expect the next stage will be to hurl objects at the screen but I have not yet quite reached that stage.
'We are a nation of lions led by donkeys!' - famous first world war quote.
Where do HMRC get these 'silly' ideas from. Everything and I mean everything they bring in that is new is NOT FIT FOR PURPOSE.
Trying to report at the moment sale of a UK residential property owned by non-resident individuals, who incidentally we are authorised as agents. But no they have to set up a NEW HMRC account before we can actually get authorised to file anything. HMRC could have just attached it in some way to an existing agent account - THAT WOULD HAVE BEEN TOO EASY, LETS COMPLICATE EVERYTHING. Because the clients live abroad they cannot set up an new online account for some reason, so is there a manual form you can download-NO you have to call HMRC to get them to send you one! Spend another 20- 30 mins just trying to get through! Another 2 weeks before the form arrives which has to be sent to client for signature then manually posted to HMRC.
Aaargh not fit for purpose HMRC needs major reform
Glad I am not a software supplier
Currently only three left in the system per HMRC website
https://www.gov.uk/guidance/find-software-thats-compatible-with-making-t...
As always on this HMRC shifting the goalposts
Reminds me of the days of vapourware when every software developer was promising revolutionary programmes in development and very few of them actually appeared.
The article above includes a paraphrased interpretation of SI1076 s.17, it is not a direct quote.
SI1076 s.17 does not say: the error must be included in the next quarterly filing submission.
The law is not absolutely clear, which is why some have interpreted SA1076 to have a different meaning that one might expect, when considering the MTD APIs that HMRC have available.
In the round, taking HMRC's API guidance into consideration, I propose the following as the most practical interpretation of the law, until such times as the ambiguity in the law is removed, or HMRC radically changes its APIs and the meaning of an EPOS:
The law says the "...person must provide the correct or complete information to HMRC when the person next provides:
(a) a quarterly update; or
(b) an EPOS"
"next provides" does not mean "as part of the next filing submission". Indeed, option (b)"an EPOS" doesn't include the filing of any financial data at all, it is just a declaration that the data already submitted for the year is now full and correct. It is the submission of an "Adjustment Business Summary" that provides annual adjustments to quarterly submissions, not an End of Period Statement. Therefore the law cannot be interpreted in the way it has, unless HMRC change what an EPOS is in its APIs. If an EPOS has to be changed by HMRC to mean the filing of new data, the law would have to be changed in any case, as it would no longer be a just a "statement" (The "S" in EPOS), but rather an "Adjustment" or similar.
Instead, I read the legislation (admittedly with the hindsight of HMRC's API guidance) that the person is expected to send in updated information on the erroneous quarter at the time they next do a filing, by doing the following:
Firstly, they send in an amended quarterly submission for the incorrect period, as HMRCs MTD API allows.
Secondly, they file either their next quarterly submission, or the EPOS, which ever is the next filing.
I think the law shouldn't be interpreted in such as way as to include the data from an old period, onto a different filing obligation. ITSA is about Income Tax, not VAT.
A VAT Return can have correction data put on the next return, as there is no such thing as filing an amended VAT Return. However, Income Tax has always allowed the filing of an amended return, as data from one tax year should never be just slotted into the next tax year - the same is true for quarterly Income Tax Filings I believe.
Therefore, if a mistake has been made on a quarterly spreadsheet, the user just uploads the corrected original spreadsheet to the quarterly period already filed - as an amended submission, as the API allows. The user doesn't have to start fiddling with errors across different quarterly spreadsheets. In any case, that is what a user would have to do with VAT now, and Spreadsheets are already allowed for VAT.
We need to recall the purpose of MTD ITSA: HMRC want quarterly data to be able to estimate someone's tax liability. This becomes difficult if they are only sent totals for the quarter which include data from a different period. HMRC will perceive that someone's income or expenses are hap-hazard and not predictable, which means they won't be able to estimate taxes if period adjustments are slapped onto the next return. This is why HMRC want corrected individual quarterly filings, not differences stuffed into the next filing.
As per your final paragraph, many of my clients do have ‘haphazard and unpredictable’ income so it wouldn’t be possible to estimate their taxes on a quarterly basis anyway.
I for one am deeply unhappy with the thought that we could be constantly filing amendments to a previous quarter’s return. Of course, as HMRC don’t ever lose any paperwork (cough), they have no concept of a tradesman forgetting to empty their glove compartment for a year, and then finding a veritable treasure trove of fuel and supplier receipts in it.
Well, re-filing quarterly returns isn't your only answer. Instead, as my post suggested, there is the option to file a single annual adjustment.
Here is what you could do:
1 Do all the quarterly filings, with the information you have;
2. After the tax year has ended, but before 31 Jan the following year, you obtain all missed information from your client and file a single annual adjustment, the "Adjustment Business Summary".
You are likely to make such an adjustment after the tax year in any case, when you did an annual review of the data, before filing an end of period statement.
I can see that you are bravely trying to justify the unjustifiable but it is clear to many people that the most logical way to assess a persons/business income and tax liability for any tax year is on an annual basis and very much along the lines of the superbly apt Self Assessment system that we already have at the moment.
There is nothing particularly wrong with Self-Assessment and this MTD quarterly filing nonsense is completely unnecessary and has no beneficial purpose for anyone. In fact I go as far to say that it is completely unworkable anyway.
MTD should be killed off today and resources diverted to improving Self Assessment and retaining this most logical system of assessing income over a single one year period, once a year.
I've pondered a little more your problem of having to otherwise file previously submitted quarters as well as new returns. I am sure that HMRC will allow the filing of late data on the next return, as it would be impractical otherwise, as you have pointed out. Imagine: you have your last quarter to file, and your client gives you data also fitting into the last three quarters. You'd then have to re-file the prior three quarters and the new quarter as well -which is quite ridiculous. Legally, you aren't meant to rely on the annual adjustment filing according to the law for in year adjustments, though practically you could. Therefore, we shall accordingly allow both quarterly amendments, and additionally the flow of transactions missed off a prior quarterly filing in the next return on the spreadsheets we are developing.
"Therefore, we shall accordingly allow both quarterly amendments, and additionally the flow of transactions missed off a prior quarterly filing in the next return on the spreadsheets we are developing."
Thank you, that is a very kind gesture.
(Apologies for my rather sarcastic comment but many of us are not the slightest bit interested in technicalities that have not been determined yet and would rather see the end to MTD altogether, or at least until HMRC can present us with a fully tested and ready to go out-of-the-box system. In addition, a two or three year period would then be required to bring clients into the system but excluding those with turnovers of under £85,000. This is a practical solution to a farcical situation)
I’d quite like HMRC to try to take taxpayers to court for illegally including prior period omissions within the annual adjustment filing. There could end up being so many that the legal system would be jammed up for years.
I appreciate that you are working towards a practical solution. However, in the end it just comes down to giving HMRC a load more information that they won’t know what to do with, and is of no benefit to the taxpayer submitting it.
I would far rather the budget for this was spent on sorting out the current mish-mash of systems for various taxes.