Share this content

MTD for dummies

The recent MTD update vat notice 70022 has left me a bit confused?

Didn't find your answer?

I may be trying to interpret the guidance into what I want to hear but I am a bit confused. It seems that HMRC are relaxing the rules now, which I am glad to hear allowing payment statement totals to be entered but I am a bit at a loss regarding sales records. Most of my clients are on vat cash accounting basis. Some clients have simple sales invoices which they produce from either software that they have had for years and just want to use this, or use a word/ excel template document to produce an invoice. They are quite happy doing this and nothing else regarding the records. They just send in the quarterly information for our office to write up to produce the vat return. Of course I have steered some to VT, QB, Sage etc but some are just not happy and have reverted to their old methods. Would it be ok, looking at the recent quidance, to now let the ludite clients carry on with their old system and just write up the records quarterly on MTD software?

Replies (38)

Please login or register to join the discussion.

avatar
By Truthsayer
08th May 2021 14:38

Yes.

Thanks (1)
Avatar
By I'msorryIhaven'taclue
08th May 2021 16:10

What you've described is essentially a hybrid between Example 3 (but without the Yard Sales and its associated DGT summary) and Example 5 (from which we are borrowing the agent and copying and pasting him into our hybrid between invoices and API). Looks good to me.

I too have been struggling to understand to what extent we are supposed to mix and match from those HMRC examples. I'm currently mixing and matching trying to figure out legitimate ways to get data from Stripe and bank to VAT return via sales ledger along the way, and fancy a tweaked Example 4 with a dash of Example 3.

Thanks (0)
Replying to I'msorryIhaven'taclue:
avatar
By Di
08th May 2021 17:12

I am hoping its all example 1 !
But really if we are struggling how are the Revenue's customers going to get it right, surely this should all have been sorted by now. It just goes to show that the Revenue are not in touch with the man on the street.

Thanks (1)
Replying to Di:
avatar
By mikeyban
08th May 2021 17:35

Totally agree ... they live in Utopia... a beautiful place where there is no grey... only black or white....

Thanks (2)
avatar
By Hugo Fair
08th May 2021 17:35

I had been debating (with myself as it's a weekend) whether to post a question about VAT Notice 700/22 ... along the lines of:
- What %age of agents will read it fully? And what %age will understand it fully?
... and then repeat the both the questions, substituting 'taxpayers' for 'agents'.

And this (35 x A4 pages of techno-babble) is only for MTD for VAT where, in most cases, the figures to be submitted are almost a book-keeping exercise ... so what happens with MTD for IT when multiple sources are involved and many of them need accounting treatment prior to submission?

I don't mean to hijack the OP's question, but if the latest notice is meant to make things clear or set our minds at rest then .....

Thanks (4)
avatar
By SXGuy
08th May 2021 18:22

I'm struggling to see what issue specifically can't be resolved.

There are programs which can import spreadsheet data for sales and purchase ledgers, they can also link open banking feeds. No digital link is lost if you import client spreadsheets providing you map the columns correctly.

Or else I'm pretty sure there will be bridging software for those spreadsheet users.

For those on cash basis simply tagging open banking statements should work via software also.

Quickfile handles this pretty well as you can tag a feeds transaction and either assign to a record or create one on the fly.

The only issue I see, is the time spent gathering said data and the various formats it may come in, and charging appropriately for it.

Thanks (0)
Replying to SXGuy:
Avatar
By I'msorryIhaven'taclue
08th May 2021 19:34

I agree, I'm certain it need not be anywhere near as complicated as it sounds.

Let's cherry-pick our way through 70022's flowcharts:

Example 1 allows us to manually input our sales invoices, produced on some other random piece of kit such as MS Word, into an API Enabled VATR Spreadsheet. It also allows us to manually input purchase invoices, both pdf and hardcopy, as well as manually input any adjustments. Presumably one is also allowed to manually input bank data, although worryingly the entire notice is silent on the matter of bank entries. Not a digital link in sight so far, save for the link from the API Enabled VAT Spreadsheet to HMRC.

Example 2 allows us to toss aside our API Enabled VAT Spreadsheet and replace it with an ordinary spreadsheet (a "VAT Spreadsheet") and some bridging software. Example 3 gives us the option of upgrading our VAT Spreadsheet with an API Enabled Accounting Package; as well as affording us the concession of manually inputting further adjustments and, importantly, manually inputting till takings (albeit those till takings are manually recorded in a DGT manual summary). Still no digital links in sight, save for the link from the software to HMRC.

Example 5 allows us to manually input "Shop Sales" from a till, again summarised in a DGT manual summary. Ahha, we can also insert ourselves, an agent, into the flow should we so wish. Note the mandatory digital link from agent to API Enabled Accounting Package is only there because in Example 5 Sales are digitally downloaded. If we and/or the client are manually inputting everything, as I've envisaged so far, then the dotted line (ie manual input, no digital link) applies between agent and API Enabled Accounting Package. Still no digital links, save for the link from Accounting Package to HMRC.

So what we have thus far is a manual entry system that's not very different to what clients have been used to for years; except with the add-on of bridging software for those using spreadsheets or, alternatively, ensuring your off-the-shelf accounting package is API enabled (which I'm sure most are). Clients can still produce their sales invoices in whatever software program they like, and they and we can manually input and/or adjust pretty much anything and everything.

Suppose we want to flex this manual model by downloading data, then example 2 illustrates a case of how a digital sales download extends the digital link requirement backwards from the VAT Spreadsheet to the source online sales software. Example 5 displays a similar scenario for those using an API Enabled Accounting Package (and/or for that matter using an agent). The point is that using such digital downloads is optional. I can't see much to prevent a client from doing everything manually, as I've described in the paragraphs above.

I'm struggling to prove that that is the case for bank transactions, as the notice has excluded them from its various examples of items capable of manual input. So I'm prepared to stand corrected if anyone knows better.

Thanks (2)
Replying to I'msorryIhaven'taclue:
avatar
By johnhemming
08th May 2021 20:50

The point about digital records is that wherever you store your prime records that they automatically calculate the figures to submit to HMRC.

That starts with the digital records. You can type in the cashbook, you can type in invoices or till records, you can use scanning for it, but once you have the digital records the processes after that don't use manual calculations.

Thanks (2)
Replying to johnhemming:
avatar
By Hugo Fair
08th May 2021 21:13

Now that's a principle I can endorse ... akin to my cri de coeur at many design meetings over the years of ... "No, no, no. You can't let the user adjust their submission file in order to correct validation failures - you must direct them to make the corrections in the source data and then re-create the submission file".

But it's never been a popular view (or an easy sell if the client is the end-user as they see it as extra work to complete a boring action - submitting successfully - rather than the logical means of protecting their core data and avoiding repeat, or worse, errors in the future).

I guess this is the current situation with MTD, but exacerbated by the lack of any official guidance (that I've seen) trying to explain this facet as clearly as you've done.

Thanks (1)
Replying to Hugo Fair:
avatar
By johnhemming
09th May 2021 08:02

Hugo Fair wrote:

I guess this is the current situation with MTD, but exacerbated by the lack of any official guidance (that I've seen) trying to explain this facet as clearly as you've done.

Although I provide services for a handful of firms of accountants most of my clients are end users hence I have tried to get an easy way of explaining what to do.

The key regulation is in fact this one:
https://www.legislation.gov.uk/uksi/2018/261/regulation/7/made

For ITSA digital records are only needed for the self employment quarterly submissions and the rental quarterly submissions. The annual submissions (of which there can be plenty) don't have the same requirement for a digital audit trail.

My understanding as it stands is that the accountants adjustments are treated in the same way (not requiring a digital audit trail) although I don't see that as being consistent.

I have, however, coded up a digital audit trail for all of the transaction based things (dividends, interest etc).

Some of the things (CIS/Employment/State Benefits) require a detailed reconciliation. I personally think that is sensible, but it will be a technical challenge for some companies to develop.

Thanks (0)
Replying to johnhemming:
avatar
By Hugo Fair
09th May 2021 11:44

Oh I wish you hadn't pointed me at that bit of the regs ... I was much happier before I read them!

Not only are they almost entirely (if not surprisingly) specific to VAT, but despite that fairly simple canvas and some clear definitions ... s 32A contains items like:

(5) The electronic account must be kept and maintained using functional compatible software.
(6) The functional compatible software must take a form approved by the Commissioners in a specific or general direction.
(7) A direction under paragraph (6) may also specify the circumstances in which functional compatible software may be used or not used.

So, irrespective of what the regs say, the Commissioners can (at any time) re-specify the 'form' of functional compatible software and the 'circumstances' in which it can/can't be used. Doesn't that rather blow an enormous hole below the waterline in any development plans for software & associated processes?

Also, I see no reference to anything that I would recognise as an audit trail (digital or otherwise). A minimal set of transactional data is specified, but not (as I would have expected) aspects for each transaction such as Author (whether person or software), Location (whether physical or IP), Reason (whether human or trigger), Authority etc ... and certainly no mention of recovery, let alone replay, facilities (so that for instance you can show any transformation/calc was in line with the rules applicable at the time even though they have subsequently changed).

As so often I guess it depends on the meaning ascribed to terminology by different people, but I worry that the legislators would have no idea as to what I've just been talking about (assuming of course that you do)!

Thanks (1)
Replying to Hugo Fair:
avatar
By johnhemming
09th May 2021 12:13

Hugo Fair wrote:

Also, I see no reference to anything that I would recognise as an audit trail (digital or otherwise). A minimal set of transactional data is specified, but not (as I would have expected) aspects for each transaction such as Author (whether person or software), Location (whether physical or IP), Reason (whether human or trigger), Authority etc ... and certainly no mention of recovery, let alone replay, facilities (so that for instance you can show any transformation/calc was in line with the rules applicable at the time even though they have subsequently changed).

What I mean is that there are a list of transactions that automatically total to the figures submitted. I would disagree with the argument that to be an audit trail it needs to have IP address etc.

I take the view that a set of transaction data is an audit trail.

The Anti-Fraud Headers have that sort of thing, that is specified separately and handled by the MTD software suppliers.

Thanks (0)
Replying to johnhemming:
avatar
By Hugo Fair
09th May 2021 13:21

That's a good example of why I said that "it depends on the meaning ascribed to terminology by different people."
Personally I would expect an audit trail to consist of more than a list of values that when aggregated produce a figure (in a box). But my point is that there doesn't appear to be anything in the regs to specify what is required (or even if ANY type of audit trail is needed).
Maybe I was expecting too much but the OED definition (within computing) is "a record of the changes that have been made to a database or file" - which I've always taken to mean the 'who'/'how'/'why' of a transaction every bit as much as the 'what'.

Thanks (1)
Replying to johnhemming:
Avatar
By I'msorryIhaven'taclue
09th May 2021 21:45

johnhemming wrote:

I have, however, coded up a digital audit trail for all of the transaction based things (dividends, interest etc).

Double-entry clients are often encouraged to post a journal entry DR Divs Paid Cr DLA whenever a dividend is voted. I'm also curious whether accrued interest will fit into any definition of transaction based.

johnhemming wrote:

Some of the things (CIS/Employment/State Benefits) require a detailed reconciliation. I personally think that is sensible, but it will be a technical challenge for some companies to develop.

Rightly or wrongly I still construct such summaries and control accounts within my working papers. But the constituent numbers are all present within a Sage (or similar) general ledger. Wouldn't shuffling those general ledger numbers into a report - let's suppose a PAYE report - be akin to pulling them out in a TB format?

Thanks (0)
Replying to johnhemming:
Avatar
By I'msorryIhaven'taclue
09th May 2021 11:23

I wish I had your succinctness, John.

I guess the essential point that HMRC are rather clouding with their complicated smoke and mirror exposition is that should you decide to download say a Stripe or Paypal weekly sales statement directly into your Accounting Software (or, for those who prefer it, your spreadsheet) it means:

(i) you cannot fidget about altering that Stripe or Paypal data in the Accounting Software (or spreadsheet) after you've downloaded it; and

(ii) crucially, that "digital link" would relate only to that Stripe or Paypal download; it would not prevent you from fidgeting about adjusting other source records, be they paper or pdf or spreadsheet summaries you create, prior to manually inputting those into your Accounting Software or VAT spreadsheet.

In other words, beginning the digital trail at download or import stage for one facet of sales record would not prevent you from beginning the digital trail much later on, at the Accounting Software stage, for other facets. For my money, that's not clear enough from HMRC's examples.

And, for the avoidance of doubt, if I've understood correctly then there's no requirement to link your downloaded Stripe or Paypal weekly sales report to your Accounting Software (or, for those who prefer it, to your VAT spreadsheet). I can't see anything to prevent you from manually inputting the weekly summary figure as one bookkeeping entry; although if somewhere in HMRC's convoluted explanations and examples there's anything to suggest the contrary then I'm prepared to stand corrected.

Thanks (0)
Replying to I'msorryIhaven'taclue:
My photo
By Matrix
09th May 2021 11:42

I would also be interested to know this. I have clients who don’t raise invoices for Stripe sales and I make a manual adjustment for the Stripe fees/VAT. It would be a lot of work to get them to raise invoices for each Stripe sale but I suppose I could upload the gross sales each quarter as I have the data anyway. The problem is they can’t reconcile the Stripe receipts in their software in the meantime.

Thanks (1)
Replying to Matrix:
Avatar
By I'msorryIhaven'taclue
09th May 2021 12:26

That sounds very similar to the case I'm working on, except that Stripe raises the invoices in my case (some of which are for monthly subscriptions, so there's something of a sales ledger aspect to those).

I'm trying to establish some sort of baseline as to what exactly one is allowed to input manually into Sage (or similar) from the weekly or monthly Stripe reports without contravening the Revenue's guidance. As a starting point, it would be good to know for certain whether manually inputting a single entry into Sage for any such batch of non-recurring sales (by treating the Stripe report as a summary report) would break any digital links.

I'll be back on to the Revenue's examples as soon as I've mowed the lawn!

Thanks (0)
Replying to I'msorryIhaven'taclue:
avatar
By Hugo Fair
08th May 2021 21:06

Congratulations (without any patronising overtones) in scoring 1 for the "What %age of agents will read it fully? And what %age will understand it fully?" ... but I'll reserve judgement on the marketplace %ages for now.

More seriously, my concerns are:

a) HMRC have (very belatedly) been forced into being a lot more flexible in defining what's acceptable than the initial pronouncements - which is why you're now been able to find alternative methods with (in your words) minimal or "no digital links".
Based on past behaviour, they are unlikely to have dropped/lowered their original intentions ... so you can expect to see a lot of the 'hybrid'/sticky-backed-plastic options withdrawn as quickly as they think they can get away with it (which will be a lot quicker than many taxpayers are ready for and mean even more changes).

b) HMRC's espoused 'major benefit' for taxpayers (greater accuracy through less opportunity for typos) is wholly undermined as soon as you introduce concepts like bridging software ... where any mistake is unlikely to be spotted by a non-accountant but more likely to occur (precisely because you're not entering a 'figure' that looks right or wrong, but a mapping instruction).

c) As I said in my earlier post, this is only for the VAT version of MTD ... so what happens with MTD for IT where multiple sources will be involved (possibly for multiple taxpayers as in partnership rentals) and many of the 'raw' figures need accounting treatment prior to submission?

Nobody has as yet, to my knowledge, explained how the taxpayer and/or agent is meant to balance the "submitting any old estimate every quarter before revising it all for a proper year-end return" approach with professional book-keeping, let alone production of interim management accounts.

I'm not against the (true) objectives of MTD or am not as much of a luddite as I sound (having made most of my money over the years via software development) ... but it seriously worries me that nearly all the conversations (outside of this site) are between technologists and policy-makers, not active practitioners or even the benighted taxpayer!

Thanks (3)
Replying to Hugo Fair:
Avatar
By I'msorryIhaven'taclue
09th May 2021 11:57

Thank you for the accolade, Hugo. I'm embarrassed, but shall raise my glass anyway.

Whilst I share many of your concerns as to where the Revenue intend taking MTD, I'm a firm believer in playing the ball being bowled at you. The future bodyliners of MTD for SA, or indeed companies, will have to wait; dealing with the MTD for VAT delivery is quite enough for me. Besides which I can't help but feel that HMRC's backtracking over MTD for VAT rather sets the tone for their future planned assaults; pegs them back, as it were.

And they have backtracked considerably. So much so that one is able to construct a compliant model by selective means from their explanations and examples that is... well, not very digital at all. And those plans are going backwards. Will they tweak them to plug the gaps? Probably. But let's cross that bridge then, I say. With their staff sat at home getting fat, and the economy in need of a kick-start, HMRC's red-tape plans will surely spend the foreseeable future in the slow lane.

Perversely for them, and as you've pointed out, the one piece of mandatory kit the Revenue are left with - the bridging software - is the component most likely to fail.

Thanks (0)
Replying to Hugo Fair:
avatar
By johnhemming
09th May 2021 12:16

Hugo Fair wrote:

b) HMRC's espoused 'major benefit' for taxpayers (greater accuracy through less opportunity for typos) is wholly undermined as soon as you introduce concepts like bridging software ... where any mistake is unlikely to be spotted by a non-accountant but more likely to occur (precisely because you're not entering a 'figure' that looks right or wrong, but a mapping instruction).


I provide bridging software for some large bakeries. They generate a file from their accounting system and my system bridges it into MTD. That does not have any room for errors.

I accept that there is potential for errors with mapping, but even then they are quite obvious errors (eg the wrong amount of VAT to be paid). Hence the objective of automatically calculating the figures remains.

Thanks (0)
Replying to johnhemming:
avatar
By Hugo Fair
09th May 2021 13:32

I didn't mean to suggest that bridging software is any more likely than any other software to contain deficient coding such that it inherently introduces errors.
But the more 'remote' the user becomes from the 'data entry' then the less likely he/she is to spot any error that may have arisen ... from any action.
And mapping is the kind of action (when not performed by a software-confident user or pre-set up in a fixed configuration for them) where mistakes can easily be made ... especially ones that only cause a problem in 'occasional' circumstances.
I guess a relevant example would be in the food/drink trades where individual items may be at zero or standard or even reduced rate VAT, but may not be itemised or grouped that way on separate transaction lines. If the mapping software can cope it will require a fairly adept user - and if it can't ...

Thanks (1)
avatar
By frankfx
08th May 2021 23:19

It may be interesting to learn how HMRC VAT helpline staff interpret the guidance, without training .
And After training.
How many hours will be allocated for them to read , digest and comprehend the Notice?
Will they be entitled to a workplace break every time they scratch their head?
Telephone helplines to be closed whilst this training is in progess?

Thanks (0)
By ireallyshouldknowthisbut
09th May 2021 14:45

HMRC can create all the rules they like, but if they are not enforced then it is of virtually no concern to me.

The only bit HMRC can police is the digital link to HMRC. What comes before that is completely out of their control and really hard to audit without a huge level of manpower 'on the ground', the resource for which would be hard to justify given unless the tax is wrong, its irrelevant.

HMRC have failed at every previous attempt to audit bookkeeping systems, and that was back when they had staff 'out and about' visiting firms. They simply don't have the staff numbers or competence to audit bookkeeping.

If you slavishly enforce this stuff with the client it seems rather uncommercial for them and your practice. I'm sticking to building robust systems and controls as we have always done 'em, and not worry about how digital they might or might not be.

Thanks (5)
Replying to ireallyshouldknowthisbut:
avatar
By johnhemming
09th May 2021 15:12

ireallyshouldknowthisbut wrote:

The only bit HMRC can police is the digital link to HMRC. What comes before that is completely out of their control and really hard to audit without a huge level of manpower 'on the ground', the resource for which would be hard to justify given unless the tax is wrong, its irrelevant.

HMRC can, however, have examples that can be fed into accounting software to see that it comes up with the right answers.

My expectation is that the enforcement of digital records will be linked to when people make material errors in the tax payable because they are not using digital records. Because they are not using digital records they will end up paying more of a penalty.

Thanks (0)
Replying to johnhemming:
By ireallyshouldknowthisbut
10th May 2021 10:23

@john, re your penalties supposition, its quite possible penalties will be higher in the future if things are not "digital", but it would be virtually impossible for HMRC to know what you do or don't do, key in, or import short of standing behind you when you do it for the vast majority of unincorporated traders and landlords which is what the next phase is all about. Sure you can "send test data" but that will miss the non-digital input. I recall from my audit days people ticking print out from computer systems. it was a joke. What you need to audit is what's is not in the system because that's where the non digital bits all are, and you cant write test data for that.

Moreover this pre-supposed errors originating from bookkeeping, and active tax investigations (which are very thin on the ground) I cant recall the last time a client received a penalty for a bookkeeping related error caused by manual input. Its my job to catch such issues after all.

Thanks (0)
Replying to ireallyshouldknowthisbut:
avatar
By johnhemming
10th May 2021 11:23

ireallyshouldknowthisbut wrote:

@john, re your penalties supposition, its quite possible penalties will be higher in the future if things are not "digital", but it would be virtually impossible for HMRC to know what you do or don't do,

What I am referring to is the rare situation where an inspection happens and they ask for the digital ledger. If there isn't one and there is a manual one that makes an arithmetical error in the favour of the tax payer then that is where I expect the penalties to be higher.

Thanks (0)
Replying to johnhemming:
By ireallyshouldknowthisbut
10th May 2021 13:52

johnhemming wrote:

ireallyshouldknowthisbut wrote:

@john, re your penalties supposition, its quite possible penalties will be higher in the future if things are not "digital", but it would be virtually impossible for HMRC to know what you do or don't do,

What I am referring to is the rare situation where an inspection happens and they ask for the digital ledger. If there isn't one and there is a manual one that makes an arithmetical error in the favour of the tax payer then that is where I expect the penalties to be higher.

@john, but that is "after the event" stuff and for the vast majority of businesses they never ever have a tax investigation. The run rate is probably less than 1 in 1000 if you are not VAT registered sole trader / landlord in any given year. Moreover by the time we get to filed tax returns, then there will be digital records in the form of an agent's spreadsheet. This this will often have been created through a variety of methods much later on miles away from the MTD rules, but good enough to bang out a tax return. This is the reality for many small clients.

Thanks (0)
Replying to ireallyshouldknowthisbut:
Avatar
By I'msorryIhaven'taclue
09th May 2021 22:26

It's certainly uncommercial to be implementing MTD, all the more so when the Revenue shift the goalposts at the eleventh hour. Leaves clients wondering why we're making such a big deal of it all, other than to create extra fees.

Something JohnHemming stated earlier - about MTD SA requiring quarterly submissions to be digitally linked, but with no such requirement apparent for the annual submission records - has me wondering about the concept of keeping two sets of books: one of digital summaries downloaded from bank / Stripe etc; and another of detailed transactions imported / manually inputted and adjusted to your heart's content.

Applying that concept to my current (VAT Registered Limited Company) client, which sells monthly subscriptions via Stripe, then a quarterly Stripe download together with bank downloads could form the digitally linked set of books currently required for VAT submissions. Essentially the line by line detail would be unimportant; it is their totals that would be of relevance.

At the same time a more detailed set of records could be processed through Excel and proprietary software to produce a separate and more detailed set of books, containing for example a sales ledger to record and track individual customers' accounts. And because that second set of books would not form part of the digitally linked for VAT first set of books then they (the second set) could have the data within them chopped up, sorted and manipulated, run through pivot tables and whatever else it took to knock them into sales ledger shape; and then be used to produce annual accounts. Until 2026, that is, when MTD for Companies is due to hit Earth; although even Mother Russia at the height of the Cold War had only a five year plan!

So there it is: two sets of books. One a summary VAT sheet from digital downloads. The second a useful set of books containing sales (and/or purchase) ledger, analysed bank entries, and whatever other useful reports you want; and up to you how and when you download batch data or manually input, re-analyse and adjust that data even after input. All because that second set of books would be outside of MTD for VAT.

Thanks (1)
Replying to I'msorryIhaven'taclue:
avatar
By johnhemming
10th May 2021 11:54

I'msorryIhaven'taclue wrote:
has me wondering about the concept of keeping two sets of books: one of digital summaries downloaded from bank / Stripe etc; and another of detailed transactions imported / manually inputted and adjusted to your heart's content.

Sadly I don't think that will give the analysis in sufficient detail for those people who have to fill in the long form version of the return. For those just doing income and expenditure it should be OK.

An interesting point is the question as to what extent the digital audit trail will be needed for figures for personal use (such as mobile phones) where some of a cost is charged against a business and some is disallowed for vat or income tax.

I have done this in a belt and braces manner, but I can see a challenge trying to take system not designed to do this and make it work.

I think it will probably be in the regulations, but they may not be stressed about it initially.

Thanks (1)
Replying to johnhemming:
Avatar
By I'msorryIhaven'taclue
10th May 2021 13:49

I wonder whether P.U. on phones, or on anything for that matter, would be permissible within the "Adjustments" spreadsheets that the Revenue have added as an ancillary source to many of their 10 example flow diagrams. They coyly label those ancillary spreadsheets as adjustments related to car fuel VAT; but who knows what might be adjusted!

My two sets of books workaround was devised with Matrix's and my separate issues over digitally importing Stripe summaries whose data needs to be further manipulated before entry to the "Sage"-type Accounting Software. It might work better for other scenarios if it were a more linear model, say where the Stripe (or bank or whatever source you like) data is downloaded to a primary spreadsheet, and where the VAT return is submitted from that primary spreadsheet (albeit with any P.U. adjustments made in that spreadsheet or, alternatively, in a linked spreadsheet) via bridging software. Meanwhile a second copy of that primary spreadsheet could be used to sort or otherwise manipulate data for entry to the "Sage" accounting software (and you'd be pretty much entitled to do as you please with that data, including input portions of it manually to Sage; because the digital link for VAT would have been filed from the original primary spreadsheet).

Linear: stage 1 and stage 2 of the VAT spreadsheet, with stage 1 used to file MTD VAT and stage 2 used for tweaking and input to the accounts system.

Thanks (1)
Replying to I'msorryIhaven'taclue:
avatar
By johnhemming
10th May 2021 14:01

The difference between VAT and ITSA for PU is that the PU figure is not reported for VAT, but is reported for ITSA.

Thanks (1)
Replying to johnhemming:
Avatar
By I'msorryIhaven'taclue
10th May 2021 14:23

Ok, and if I understood correctly your comment yesterday VAT has to be reported under MTD whereas ITSA (when it kicks-in for MTD) does not. In other words, there's no mandatory digital trail for accounts and SA tax return.

Which I guess is why I'm proposing two sets of records as a workaround (not only for SA, but for CT cases as well; at least until 2026). Or, alternatively, one set of records which are submitted for MTD for VAT; with a second copy of those records, which by definition would be outside of the digital trail, used as the basis for inputting into the Accounting Software.

The rationale for that is that we're not permitted to amend or adjust downloaded data that's part of the digital trail; whereas a second copy of that downloaded data would fall outside of the digital trail. Not an ideal solution, perhaps; but a quick fix for the time being.

Thanks (0)
Replying to I'msorryIhaven'taclue:
avatar
By johnhemming
10th May 2021 14:34

I obviously was not clear.

A digital audit trail will be required for MTD ITSA, but only for the quarterly figures, not the annual ones.

Additionally I would expect this to include PU for SE.

Thanks (0)
Replying to johnhemming:
Avatar
By I'msorryIhaven'taclue
10th May 2021 15:14

My mistake, MTD for ITSA quarterly and annually it is. The former subject to digital trails; the latter not. Got it.

Nevertheless the idea your post spawned - of two sets of records - would still stand both for (Set #1) MTD VAT records and (Set #2) ITSA annual records (or, better still, (Set #2) MTD for CT annual records when they arrive in 5 years' time).

In short, after downloading say Stripe & Bank transactions to a spreadsheet that spreadsheet could then be copied: copy #1 used for MTD for VAT submissions because it complies with the unadulterated digital trail requirement; copy #2 after any amendments / adjustments used for inputting into Sage or similar for maintenance of useful and meaningful records and, ultimately, accounts production (with no such digital trail restrictions applicable).

Thanks (1)
Replying to I'msorryIhaven'taclue:
avatar
By johnhemming
10th May 2021 16:14

That looks workable. Unsurprisingly I use the same data for vat and ITSA, but it is a cash based tax system rather than accounts. I may add accounts later, but for now it is cash basis only.

Thanks (1)
Replying to johnhemming:
Avatar
By I'msorryIhaven'taclue
10th May 2021 16:34

Thanks John, I appreciate your assessment. It seems to me that if past a certain point one cannot manipulate data into meaningful reports or ready for input into an accounts package, then at that certain point one must split the records into two separate records: one MTD compliant; the other not.

I guess I'm blind to ITSA because I have enough on my plate presently with clients expecting solutions to their immediate problem of complying with MTD VAT without losing control and functionality of their accounting system. Mostly small to medium limited companies, so any solution that will work until 2026 is ideal.

I've already warned my SA clients that they'll need to incorporate when ITSA arrives, or move on elsewhere. Shortening their year-end from 5th April to 31st March might buy some an additional year's grace; but for so many the additional cost of quarterly returns will surely make it a no-brainer to incorporate. Not landlords, of course - although their "books" are relatively simple anyway.

Thanks (0)
Routemaster image
By tom123
10th May 2021 08:58

HMRC really have no idea how many piecemeal legacy software systems can be used in one SME size business.

The idea that these can all be made to talk to each other is the holy grail of IT, and has been what IT guru types have been trying to sell for decades.

I have yet to see it in reality.

Thanks (1)
Avatar
By I'msorryIhaven'taclue
11th May 2021 14:27

Just to flag for anyone placing future reliance upon this thread that HMRC's 70022 MTD guidance doesn't exactly shout out the obvious that anyone with a sub £85k annual t/o (in accordance with VAT registration threshold rules) doesn't have to switch to or comply with MTD for VAT until April 2022 (*at the earliest). It's there, at the bottom bullet point of s3.1 (of 70022). Exemption from MTD is the default position for any sub £85k t/o business; it's automatic.

*at the earliest because apparently it's yet to be confirmed and announced in any VAT publications. I've just had that from the horse's mouth.

From the same HMRC techie, the "old" agent's logins (and, for that matter, clients' own "old" logins) to VAT 100 forms will continue to work for the foreseeable future. I know J.S. had written an article last October about HMRC's plans to retire the old form in April 2021. That's evidently been postponed. Indeed, it seems the old form will be the only way to file non-MTD clients' VAT returns for the forthcoming 11 months or so. You can run your "old" non-MTD for VAT agent login in tandem with your "new" MTD for VAT agent login.

Thanks (1)
Share this content