Share this content
0
1666

How digital does "digital" have to be in MTD

How digital does "digital" have to be in MTD

My understanding is that the quarterly reports to HMRC under MTD will just be a few line entries.

Our preference for client bookkeeping for the vast majority of our clients has always been VT. We do use QB online for some clients who prefer to use online bookkeeping but we find data input much easier with VT and really don't want to move away from this.

Is it likely to be acceptable under MTD (for those clients who will be required to report) to still do all the bookkeeping in VT and then just post totals to HMRC each quarter. If that doesn't work could you get away with entering totals from VT into QB on a periodic base and then submit to HMRC. Probably not but just wanted to throw it out there.

I am obviously no fan of the whole idea of MTD which I think is yet another pointless example of government meddling and running up unnecessary costs for business (just like RTI and Auto-enrloment)

Indeed don't really know what digital means (although apparently online bookkeeping is "digital" but spreadsheets are not). Have looked up dictionary definitions but this doesn't really offer much clarity. For me a digit is just a number in the way that one would say 1234 is a 4 digit number so don't see why spreadsheets (or VT) shouldn't quality.

Replies

Please login or register to join the discussion.

avatar
By GW
15th Oct 2017 19:39

What is "digital" -
As I understand it the plan is for primary legislation, to enable a statutory instrument that will enable HMRC to issue a note detailing the form and content of records.

So at present we don't know and even if we did HMRC could change the definition whenever they want without any scrutiny.

Thanks (0)
avatar
15th Oct 2017 22:54

I believe the latest position regarding VAT can be found here:

https://www.gov.uk/government/consultations/making-tax-digital-reforms-a...

In my view, the requirement is twofold:

1. to maintain records digitally, in suitably functional software and
2. be able to extract that data in the correct format to be able to send and receive data to HMRC using suitable functional software.

My view is that these could be two separate suitable functional software.

Digital implies binary ones and zeroes. To maintain this in anything other than electronic form would be perhaps at best foolish.

If HMRC provide an option to post totals into their portal then obviously that must be deemed acceptable.

If you choose to use VT for day to day accounting and then transferred relevant totals to QB for submission then, in my view you have met the two requirements.

With regard to spreadsheets, firstly they provide digital records. Secondly all necessary level of detail at transaction level is likely to be there. Thirdly the functionality is there to populate a table within the spreadsheet for data necessary to be transmitted to and from HMRC. Finally, in respect of Microsoft Excel, its Visual Basics for Applications (VBA for Excel) appears to have the API REST functionality to meet the requirement to send and receive data.

This latter point means that, at least in my view, you could design the spreadsheet to meet the transmission aspect of the requirements. Now whether you wanted to register such a solution with HMRC is another matter. Clearly a robust spreadsheet template containing the required table of data, suitable for formularising and with the built in API functionality would be invaluable. A database application might however prove more desireable and more robust.

I think if HMRC attempted to rule out use of spreadsheets then it would be met with severe opposition, not least possibly from Microsoft suggesting their software inadequate, but also because it would be yet another example of lip service paid by HMRC to the requirements of their "Your Charter" - should they recall its existence.

Thanks (1)
avatar
By cbp99
to D V Fields
16th Oct 2017 17:14

I agree that the draft SI envisages the possibility of using two separate programmes to comply. It says: “functional compatible software” means a software program or set of compatible software programs the functions of which include—" etc

Thanks (0)
avatar
to D V Fields
19th Oct 2017 18:59

I think a key part of that HMRC link you've missed is "allowing...HMRC to make regulations that require a business to keep *and preserve* certain records digitally".

Spreadsheets do not of themselves provide digital records with any guarantee over their preservation. There is no audit trail and no ability to prevent a user overwriting or modifying the data underlying a previously submitted return - and in many cases no ability even to detect if that has happened.

While there are ways of implementing some of that in Excel, most can be easily defeated by the user.

I think it's very likely that point-in-time historical accuracy and auditing will be one of the software requirements HMRC imposes, and I can't see how a spreadsheet could ever achieve that.

Equally, I'd argue against your more general opinion that a spreadsheet can provide a suitable basis for long-term recordkeeping like this.

Out of the box and in the hands of even advanced users, spreadsheets don't provide anything like the guarantees you'd need for a robust accounting system. There are any number of common errors - inconsistent formulae across the rows of a column, pivot tables whose ranges aren't large enough to span newly added rows, formulae which have picked up the wrong cell references through a botched sort / copy & paste / insert & delete.

Here are just a few http://www.smb.co.uk/5-epic-spreadsheet-fails/ of the very many examples of skilled professionals failing to notice that an overly spreadsheet is giving them duff figures.

You could of course mitigate many of these risks by paying a suitably competent specialist to build a spreadsheet that was sufficiently locked down and automated (e.g. with VBA to verify consistency of formulae etc). Or indeed if you have the experience and skills to do so you could invest significant time and effort in building it yourself.

But it's highly unlikely that would be cost-effective compared to accepting that a spreadsheet is the wrong tool for the job and signing up for one of the many relatively cheap accounting software packages where all those hassles are taken care of for you.

Thanks (0)
to andyscotland
19th Oct 2017 21:43

andyscotland wrote:

I think a key part of that HMRC link you've missed is "allowing...HMRC to make regulations that require a business to keep *and preserve* certain records digitally".

Spreadsheets do not of themselves provide digital records with any guarantee over their preservation. There is no audit trail and no ability to prevent a user overwriting or modifying the data underlying a previously submitted return - and in many cases no ability even to detect if that has happened.

While there are ways of implementing some of that in Excel, most can be easily defeated by the user.

I think it's very likely that point-in-time historical accuracy and auditing will be one of the software requirements HMRC imposes, and I can't see how a spreadsheet could ever achieve that.

Equally, I'd argue against your more general opinion that a spreadsheet can provide a suitable basis for long-term recordkeeping like this.

However, the most likely reason for changing an entry is to correct an error made by a taxpayer unskilled in accounting software. Nothing sinister. And nothing which has not been pointed out to HMRC.

Thanks (0)
avatar
to lionofludesch
20th Oct 2017 22:24

It doesn't matter why a user makes a change. Of course it could be for a perfectly valid error correction. The point is that as soon as a user modifies an entry, there is no way to tell what it was before, and now no way to reconcile the figures currently in the spreadsheet with the ones that were submitted to HMRC at the time.

Taking VAT as an example - suppose a taxpayer unskilled in accounting software notices and corrects an error in a prior-period VAT transaction. The figures the spreadsheet will now give for that quarter will no longer match the submitted VAT return. In an inspection, there'll be no way to trace back from the HMRC submission to understand what underlying figures were included in it.

Perhaps more importantly, it's unlikely the spreadsheet will include the adjustment in the following quarter so it will sit there uncorrected on the VAT account indefinitely leaving either the trader or the VAT man out of pocket.

I don't understand the argument that a taxpayer unskilled in accounting software (or accounting principles) is better off using a spreadsheet over software specifically designed to help them avoid the most common errors people make.

Thanks (0)
to andyscotland
21st Oct 2017 09:20

andyscotland wrote:

It doesn't matter why a user makes a change. Of course it could be for a perfectly valid error correction. The point is that as soon as a user modifies an entry, there is no way to tell what it was before, and now no way to reconcile the figures currently in the spreadsheet with the ones that were submitted to HMRC at the time.

Taking VAT as an example - suppose a taxpayer unskilled in accounting software notices and corrects an error in a prior-period VAT transaction. The figures the spreadsheet will now give for that quarter will no longer match the submitted VAT return. In an inspection, there'll be no way to trace back from the HMRC submission to understand what underlying figures were included in it.

Perhaps more importantly, it's unlikely the spreadsheet will include the adjustment in the following quarter so it will sit there uncorrected on the VAT account indefinitely leaving either the trader or the VAT man out of pocket.

I don't understand the argument that a taxpayer unskilled in accounting software (or accounting principles) is better off using a spreadsheet over software specifically designed to help them avoid the most common errors people make.

No way of reconciling ? Print them off before and after. How do you think we correct errors now ? We have to use "work-arounds" because computers aren't always smart enough.

Surely the world not always being ideal is the main threat to MTD. If HMRC want it, they'll need to live with the imperfections of the software and - far more likely - its users.

Thanks (0)
avatar
to lionofludesch
23rd Oct 2017 11:15

Well the way I correct errors now is to post correcting entries (or to alter the transaction in accounting software that does that for me automatically under the hood).

Clearly if your only way to reconcile is to print off before and after, you are not storing and preserving records in digital format.

Thanks (0)
to andyscotland
23rd Oct 2017 11:42

That's fine.

I don't have to.

Thanks (0)
16th Oct 2017 07:31

My understanding is that MTD submissions will be a lot more than a few line entries.

It'll be pretty much the entire bookkeeping for the quarter.

But - hey - the Government haven't made their strong and stable minds up yet.

Thanks (2)
avatar
By DMGbus
16th Oct 2017 08:10

Spreadsheets are digital, a point conceded by HMRC at a meeting in October 2016 (well at least in a response to a comment of mine that some VAT computations can be handled well in Excel [eg CGS, PX, Margin Scheme] HMRC representative from London said in response "well I suppose a spreadsheet is digital record keeping as it is held on a computer").

The issue with MTD is getting the Excel data into a third party software to upload the totals [NOT the individual transactions] to HMRC.

Thanks (0)
avatar
By GW
16th Oct 2017 09:28

Back to my original response, the finance bill refers to "electronic" rather than "digital" records and everyone appears to be making their own judgement as to what constitutes digital records, if there is an attempt at providing a legal definition of what is required, then it is well hidden. I presume this is part of "agile" development - HMRC see what the system can do then make up the rules to fit.

Thanks (0)
to GW
16th Oct 2017 09:32

GW wrote:

Back to my original response, the finance bill refers to "electronic" rather than "digital" records and everyone appears to be making their own judgement as to what constitutes digital records, ......

That'll be because the government can't decide.

It's why the whole MTD saga is becoming a farce.

Thanks (0)
avatar
16th Oct 2017 10:03

Many thanks for the feedback.

It is not a huge issue for us because we tend to focus on smaller businesses anyway but I was just interested to see how digital should be interpreted in respect of those clients we do have above the 85,000 thresh-hold

Thanks (0)
By DJKL
16th Oct 2017 10:04

Scrapheap Challenge, instead of really defining what it is they want the teams to build, (Boat/car/hovercraft) they list a few attributes/tasks, provide a few experts (software companies) and see what bits the teams can drag in from the heap and patch together to roughly get to the brief.

On the plus side there has been the odd episode where the device works consistently well, albeit this is the exception rather than the norm, but what the hell, it is only the UK tax system.

Thanks (1)
16th Oct 2017 10:54

Im going to worry about it when it actually happens.

Its such a fiendishly complex thing they are trying to do it seems as likely to happen, as 12 months ago it seemed likely that by March 2018 all unincorporated traders would be filing.

O and it is just the summary data that is transmitted. So I dont see why you cant use VT as a "quarter book" and just book the totals as a single line in "compliant" software.

Thanks (0)
avatar
By DMGbus
to ireallyshouldknowthisbut
16th Oct 2017 11:05

That is my intention with clients who'd clearly make a complete hash of using any commercial software, but who can adequately use Excel.

Copy the quarterly Excel data into SageOne (which I expect will be made MTD compliant) then file the MTD VAT return data (9 boxes) from within SageOne...that is assuming that MRD for VAT actually does become mandatory [per current prposals] in 2019.

Thanks (0)
to ireallyshouldknowthisbut
16th Oct 2017 11:13

ireallyshouldknowthisbut wrote:

Im going to worry about it when it actually happens.

I'm not going to wait quite that long but I'd certainly appreciate some information about what's required before I make a move.

Thanks (0)
17th Oct 2017 10:28

I'm sure I've seen somewhere that whilst different software systems can be used for different parts of MTD, manually transcribing from one to the other will not be allowed, and so the software packages will have to talk to each other.

Thanks (0)
avatar
19th Oct 2017 13:23

Love RTI hate AE

Thanks (1)
avatar
By jilbo
19th Oct 2017 14:59

I use VT also but am looking at using different software in readiness for MTD. Just wondered if anyone had any recommendations that would work with MTD.

Thanks (0)
to jilbo
19th Oct 2017 15:09

Nobody knows.

The Government keeps changing its mind.

I can understand why the software companies get pi$$ed off - they get promised a big payday and what happens ?

The Government backtrack.

So why should they commit themselves further ?

Thanks (1)
avatar
to lionofludesch
20th Oct 2017 15:23

"The Government keeps changing its mind."

I disagree.
As far as this stuff goes, HMG has 'no mind' since it gets all its input exclusively from HMRC and is merely a proxy mouthpiece.

In reality it is all entirely the aegis of HMRC, an organization whose mendacious capriciouness makes even the innate duplicity of politicians look like Honest Abe Lincoln.
Politicians have no chance when they take their advisement from HMRC - and thus neither do we.

Thanks (0)
avatar
21st Oct 2017 12:29

Of the replies so far the one that stands out is 'noone knows'. The rest is speculation and trying to second guess HMRC/HM Government on MTD seems to me to have a poor record. I am simply hanging fire but trying to ensure that compulsory VAT clients are entering the digital world one way or another.

If HMRC know why are they not telling us (and in some detail)?

This has been the case from the beginning, has it not?

Thanks (1)
22nd Oct 2017 11:01

Anybody given thought to putting this whole data population metric on a blockchain ?

Thanks (0)
to itp3asso
22nd Oct 2017 11:12

Frankly, no.

Thanks (0)
Share this content