HMRC are expecting VAT to be submitted electronically directly from accounts systems. This seems vaguely sensible. It is mandatory from April 2019. It avoids typing mistakes at the very least.
So, we look on HMRC developer web site and see that they list APIs. They list some using RESTful APIs and some XML ones here. The XML ones include submitting VAT returns. Something we have had for some time, and is all "digital" as required. So we were thinking, cool, we did this years ago, not an issue.
But we actually asked them about it, just in case, and they are very confusing. They say the XML API does not "support" making tax digital - which - err - makes no sense, it is digital. They apparently have an API that is not the XML API for the MTD VAT submission but oddly it is not in that list of APIs, so we have to register with them in some way to get the API.
The web site does not say the existing XML API is going away, indeed they confirm it is not, but apparently will not be valid to use for MTD, which makes no sense whatsoever.
Why are HMRC not accepting their own digital XML APIs that they have in existence for submitting VAT digitally? An API they confirm they are not withdrawing? Why have they apparently produced secret new APIs to submit it? It makes no sense.
Thankfully it will be simple enough to do, one way or another, and there is still plenty of time. The recording of VAT and ensuring it is all digital is all covered, thankfully.
Update: We have finally got access to the documentation on the API, it is hidden behinds a login and not published along side all of the other APIs. There is no reason why the API for this should not be published, and even less reason when you consider the other APIs are published. It also makes little sense for a mandatory API to be in a beta state only 6 months before it has to be in use by every accounting package in the country. Thankfully it is very noddy JSON/OAuth. I cannot see anything in VAT notice 700/22 that makes the XML API invalid in anyway. The OAuth, of course makes assumptions, i.e. that someone is authorising a third party to access / submit VAT details, which is not the case here. There seems to be no "journey" (as they describe it) for someone that is submitting VAT returns for themselves using their own software. They also have gems like they want to know the public IP address and port of the web browser that requested filing the VAT return - forgetting that it may not have a public IP address even as it may be on a private network! I just hope it copes with that being an IPv6 address.
Update: WTF? They made us jump through hoops before letting us have access to the API documentation for submitting the VAT return - but their own service standards require that everything they do is published, reusable, open source, and they even have a GitHub page!
Update: I am pretty sure I have now found a newbie error in the HMRC OAUTH stuff (mis escaping form data in a sequence of pages) - we'll see what they say. Worked around.
Subscribe to:
Post Comments (Atom)
Deliveries from China
I have PCBs made in China (well Hong Kong). This is all my many small PCB projects (not FireBrick). I would rather use UK suppliers but I am...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
Ever used the Government Gateway? I have three accounts all under the same email and none of them work. They shouldn't be making tax digital if they can't even get the account login system working.
ReplyDeleteIt'll almost certainly be because they've had a new product team develop the new functionality separately to the existing stuff...
ReplyDeleteAnd the contract for the work has gone to the lowest bidder, irrespective of quality.
DeleteWhy would they want to know the port of the web browser that connected? I thought outgoing ports are basically random?
ReplyDeleteIf the web browser is behind NAT, then the IP address will only identity the NAT operator. With the combination of IP address, port and timestamp then the NAT operator may be able to check their logs and identify the actual user. Just the IP address is not enough, many people will be sharing the same NAT IP address.
Delete(NAT might be because of CGNAT, or because of a public WiFi network or a corporate LAN).
The ability to identify the actual user could be useful for investigating or prosecuting fraud; the fact that they can do that can deter fraud.
I know what NAT is, I was not suggesting NAT - but the system submitting to HMRC may well be connected to from a browser but could be on a private network, so the address seen by that system, and hence sent to HMRC, may well be internal/private and not (as required) "a public IP address".
Delete"may be able to check their logs" - emphasis on "may", Adrian is probably more up-to-date but I think it is still the case that mobile phone operators have admitted that they don't keep enough information to reliably map back to an individual user account.
DeleteWhat do they mean by "public" IP address anyway? If Adrian is correct and they want a routable IP address rather than one behind NAT it might actually be impossible for the browser to determine IP and AFAICS impossible to determine port.
Services like "whatsmyip.org" might give you the IP address but don't give you the port - which will, in any case, change when you submit to HMRC. In a CGNAT scenario it is even possible that the IP would change between the making a query to figure out what it was and submitting to HMRC.
Surely the HMRC servers would be better placed to record this so why has it been made part of the API? Unless the server which is trying to record the info is behind a load balancer and/or NAT itself so can't tell where the incomming connection originates.
All in all it looks like the API was designed by someone who does not understand networks that well.
The application, if it is operated by a browser, would be able to see Ip and port of the connection to it from the browser, and so send in the headers to HMRC as requested. My issue is that the browser may be entirely within an organisation, private IP browser talking to in-house accounts package installation, and there simply not to be a public IP involved.
Delete