Postby etf » Tue Dec 02, 2025 1:20 pm
You just know having seen MP Murray defend Reeves at the weekend that he is not good at admitting Government errors. So no hope of him acknowledging MTD4IT is a disaster before it has commenced...would however be nice if someone could ask him whether his interrogation of HMRC before deciding to proceed was totally inadequate.
By ireallyshouldknowthisbut
02nd Dec 2025 09:57
The main event, the new tax return, looks to be years off rather than (as would be required if Q reporting is to work) to be available in April 2027, fully working, fully tested on a large volume of tax payers.
Quite why they don’t just squirt the quarterly numbers (its only two flippin boxes, how hard can that be?) into the main return rather than re-doing the main return in a mind boggling complex manner to end up with a system where the old return then still needs to exist indefinitely, which in turn will lead to significant operational issues for both accountants and HMRC is beyond my comprehension.
Its so poorly thought out, no commercial business would run like this.
HMRC have simply not got a grip on their IT and what they are trying to do or achieve, all we have is “nice but dim” cheer leading types who 110 years ago would have happily chivved the boys over the top into the machine gun fire and looked surprised when everyone got shot.
By NotAnAccountant2
02nd Dec 2025 08:58
Getting organised now and overcoming any issues you may have for mandated clients will end up saving time in the long run.
Unlikely...
The vast majority of problems that come to light will be shared amongst many different taxpayers. Many of the solutions will involve HMRC changes, to APIs, to guidance, to helpline information etc.
Far, far better to wait for other people to spend the time, then, while you'll still have to spend the time working out how to work around a problem, there's a very high chance that there is a workaround and it's not going to be, after many hours of back and forth, "We'll have to get back to you on this one".
The only advantage to being out front is if you have enough clout with HMRC to get them to go with your preferred solution to a problem. The (end of year) CGT api is a complete and utter mess which is going to be incredibly hard to use and is probably going to mean that anyone with complex CGT affairs (and here I mean many transactions across many asset classes, not necessarily large gains), is likely going to need a bespoke solution[1]. If I'd had any clout with HMRC I'd have had them redesigning the API so different asset classes, and even individual assets, don't have to be submitted together in a single submission - allowing, for example, software that is optimised for listed shares, to be independent of software that is optimised for crypto disposals, to be used independently of software designed for mixed use property disposals, to be used independently of software designed specifically for residential let disposals, to be used independently of software for commercial property disposal.
As an example of the sort of thing that might come out of the woodwork once mass signups start (obviously not this, it's a known issue and, weirdly, I only know of one other developer who has complained about it)
https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service...
This is the agent authorization API - which has been live for as long as MTD for VAT has been live. There are changes for ITSA but they're "backwards compatible" and haven't involved an api bump.
In the example it has:
"service": [
"MTD-VAT"
],
And this is what HMRC expect you to send, an array containing a single value, but in the *definition* of the api it says:
service required string (MTD-VAT) MTD VAT service
It's a single string value "MTD-VAT", not an array.
My software, before submitting to HMRC, checks that what is about to be submitted actually matches what the HMRC specification says they *require*. This doesn't catch most errors but means, for example, you cannot submit "I think mtd is a waste of time" in the expenses field where it expects a number with up to two decimal places.
Unsurprisingly, I also now have a setting "ignore validation".
FWIW, I've reported around 10,000 defects in the APIs where it's internally inconsistent. The vast majority are defective examples that fail to validate, but there are others like this one where the definition of what to submit is defective.
Note that this is inconsistency within the API, this is not "I've discovered a valid submission that fails to validate", this is a "the example in the api itself fails to validate"
[1] It's not just whether the software can support it, it's whether the software can import all the necessary transaction data from all of the different brokers. Obviously, if you trade the same name on many different platforms, you already have a headache merging the transactions so you can do matching to calculate the gain, but someone who trades DBK on Xetra, JPM on NYSE and LLOY on LSE, each with a different broker, doesn't currently have the headache of merging the transaction data, only the gains/losses.
.