[GNC] UK VAT and "Making Tax Digital"

Wed May 1 02:01:21 EDT 2019

How would HRMC know if you cut and pasted the data or not?  I haven't
looked at this in some time, but if a CSV file works for the report,
how would they know that a submission isn't just a .csv or .xml file
that was copied and pasted manually from another program?  I vaguely
remembered the website version where you just filled in the boxes.

But what HMRC wants (requires!) now just seems nuts to me.  Anyone can
help themselves from the following header keys:

MOBILE_APP_DIRECT
DESKTOP_APP_DIRECT
MOBILE_APP_VIA_SERVER
DESKTOP_APP_VIA_SERVER
WEB_APP_VIA_SERVER
BATCH_PROCESS_DIRECT
OTHER_DIRECT
OTHER_VIA_SERVER

Just cut and paste one of those into your csv or xml file.  I
recommend "OTHER_VIA_SERVER".

Then for timezone:

<<
Gov-Client-Timezone: UTC+01:00
>>

or get creative!

Gov-Client-Timezone: UTC-27:00

They even have keys or headers when you have "do not track" turned on
in the browser:

WEB_APP_VIA_SERVER

Gov-Client-Browser-Do-Not-Track: false

Which appears to mean that os information, version, etc. is not collected.

I find it disturbing that inland revenue would require you to tell
them your computer, browser, OS, MAC address, and various other bits
and pieces of information that can pinpoint the exact IP and ports on
your devices.  Seamlessly.  In electronic format.  Which data they
would surely never compromise, or allow to be hacked.  What could
possibly go wrong?  I'm sure they would handle all this as smoothly as
they have brexit.

You already expose much of that information now on some web sites.
Banks collect it when you access your accounts with them using a web
browser, to prevent someone else from defrauding your account.  But
HMRC thinks it will help prevent fraud if you give it to them, along
with the quarterly data:

https://developer.service.hmrc.gov.uk/api-documentation/docs/fraud-prevention

But how would that help prevent fraud?  Here are two required headers:

Gov-Client-Screens

Gov-Client-Window-Size

These would be the width, height, depth, scaling factor and pixels of
the screens on the reporting device.

Again, banks, credit card companies, utilities and other companies
might collect this kind of data and they still get hacked.  And they
have lots of expertise and incentive to protect the data of their
users.  How much of those things does HMRC have?

The suggestions already mentioned all seem workable to some extent.  I
would add one more possibility: export the .qfx or .csv then modify
them with a command line program like awk, sed or grep.  Linux and mac
machines have these utilities, and Windows machines can add them with
cygwin.  But that's a lot of work if you don't normally use those
command line programs.

And here's an option:

<<

3.4 Ask HMRC for an exemption

To make a claim for exemption, call or write to VAT: general enquiries.

...

You should continue filing VAT Returns the way you usually do if:

you’re waiting for HMRC to make a decision on an exemption request or
an appeal after being rejected for exemption
HMRC have told you that you’re exempt from Making Tax Digital

>>

Again, be creative.  Tell them you do all your calculations with an
abacus.  You're allergic to electricity.  You might point out, with
all honesty, that the time, money and effort required to "make tax
digital" is crippling for a small business like yours:

<<
HMRC will however take effort, time and cost into account in its
overall assessment of whether it is practical for you to follow the
rules for Making Tax Digital.
>>

I think Maf has the right idea with the third-party vendor CHM.  7.50
sounds like a bargain for each VAT report.  But will HMRC still allow
"bridging" after 2020?  It's not clear from the documentation.

Gordon

On Tue, Apr 30, 2019 at 7:15 PM Christopher Lam
<christopher.lck at gmail.com> wrote:
>
> Oops realised that recording the capital purchase as expense then
> immediately create a kludge txn from expense to capital-asset won't work:
> it would be classed as a 'refund'. I have no other workaround.
>
> Just wondering what exactly are the parameters for your reports?
>
> On Tue, 30 Apr 2019 at 15:08, Christopher Lam <christopher.lck at gmail.com>
> wrote:
>
> > Hi Maf
> >
> > I agree your asset purchases are not going to be accounted for in the
> > current iteration. This was not thought of during the design.
> >
> > A short workable answer is to record this asset purchase as an expense,
> > and immediately create an expense->asset transaction which will satisfy
> > your VAT requirements and still use the report as it stands. I'm sorry this
> > is clunky, and the next para explains why
> >
> > The longer answer was that every VAT/GST related transaction ie.
> > sales/purchases, record VAT, and periodic submission would need a
> > transaction of at least 3 splits... moreover we'd need to determine, as
> > simply as possible, whether it is a purchase or a sale. Hence the decision
> > made to consider Income split as sales and Expense split as purchases, and
> > determine vat/gst-split  as asset/liability as well. This allowed a complex
> > 5-split transaction involving both
> > sales/purchase/vat-collected-on-sales/vat-paid-on-purchases as illustrated
> > in https://wiki.gnucash.org/wiki/Alternate_Australian_GST_setup and
> > https://www.gnucash.org/docs/v3/C/gnucash-guide/rpt_standardrpts.html#rpt_gst_statement
> > .
> >
> > An alternate strategy *could* be used to determine sales vs purchases, vat
> > collected vs paid; e.g. use Business Features (which would then force the
> > user to use invoices/bills for *all* vat/gst purchases, IMHO undesirable!).
> > The difficult part is to determine a consistent strategy which is
> > acceptable to users worldwide, and does not inconvenience too much.
> >
> > Sorry for long answer, hope is informative. If you have a better strategy
> > to offer, to account for your Asset:Bank -> Asset:CapitalAssets +
> > VAT:Paid-on-Purchases use cases, I'm all ears! Meanwhile the short
> > workaround above *may* be an acceptable solution for the current reports...
> >
> > (w.r.t. CSV output: the following replacement .scm files can produce
> > something similar)
> > https://raw
> > .githubusercontent.com/christopherlam/gnucash/maint-export-csv/gnucash/report/standard-reports/transaction.scm
> > https://raw
> > .githubusercontent.com/christopherlam/gnucash/maint-export-csv/gnucash/report/standard-reports/income-gst-statement.scm
> >
> > On Tue, 30 Apr 2019 at 13:37, Maf. King <maf at chilwell.net> wrote:
> >
> >> Hi Christopher.
> >>
> >> Finally got round to completing my final quarter VAT return with the
> >> manual
> >> error-prone process of typing 7 numbers into boxes on the HMRC website.
> >>
> >> I'm now trying to make the Income & GST report give me sensible numbers
> >> that
> >> match my existing saved transaction reports and struggling with one thing.
> >>
> >> It may well be how I've got my tree set up that's causing my problem.
> >> The GST
> >> report doesn't allow to  include transactions to asset accounts.
> >>
> >> Under UK tax law, if I buy something of lasting value, eg some machine,
> >> for
> >> example, it is not an expense but a transfer to Asset:CapitalEquipment.
> >>  But
> >> the VAT is claimable straight away and so the transaction (for the VAT
> >> return)
> >> should be included in the Net Purchases & Tax on Purchases column.
> >>
> >> any advice?
> >>
> >> is your CSV output intending to be made from the GST report codebase in
> >> some
> >> way?
> >>
> >> The bridging spreadsheet I have will be quite happy to read from
> >> ~/somewhere/somefile.csv
> >>
> >> my test file is just :
> >> Box1,1234.56
> >> Box2, 0.00
> >> (box 3 is calculated from box1+box2 so not included)
> >> Box4, 321.98
> >> etc to include box 6,7,8,9
> >>
> >> and the spreadsheet will read that and populate new data into the fields
> >> each
> >> time it is run.
> >>
> >> the only other thing that might be nice to include in the CSV output is
> >> the
> >> date period, but I haven't tested that for format etc yet.
> >>
> >>
> >> I'm not signed up for the -devel list, can do so if you'd prefer to keep
> >> this
> >> off -user for now.
> >>
> >> thanks & best regards,
> >> Maf.
> >>
> >>
> >>
> >> On Thursday, 11 April 2019 11:08:27 BST Maf. King wrote:
> >> > On Thursday, 11 April 2019 04:48:31 BST Christopher Lam wrote:
> >> > > 3.5 is out and I promised to offer CSV output. Has anyone confirmed
> >> the
> >> > > exact CSV (or JSON)  format desired by their *bridging* software?
> >> > >
> >> > > Please be aware that direct communication to HMRC is best done by
> >> bridging
> >> > > software outside gnucash. It'll be a nice project for anyone to do in
> >> > > python or similar.
> >> >
> >> > Hi Christopher,
> >> >
> >> > Thanks for looking at this again.
> >> >
> >> > I'll probably be looking at this next week or so.   I'll have to
> >> complete my
> >> > lasts "traditional" VAT return by around the end of the month.  For the
> >> > quarter ending 30th June, I'll report to HMRC towards the end of July,
> >> and
> >> > be in the first tranche of submittors.
> >> >
> >> > I plan to use a spreadsheet bridge that I found for Libre office.
> >> >
> >> > seems that the sheet as presented requires linking cells from a source
> >> > report spreadsheet.
> >> >
> >> > User guide is here explaining how to do it
> >> >
> >> > http://www.chm-software.co.uk/userguide/
> >> >
> >> > (no relationship or recommendation implied)
> >> >
> >> > I'm thinking that I might be able to adapt their sheet to directly take
> >> a
> >> > CSV input to named cells in some way.  It is only about half a dozen
> >> > numbers that are needed.
> >> >
> >> > Of course, if any other users have come across a more elegant solution,
> >> feel
> >> > free to chime in!
> >> >
> >> > Maf.
> >>
> >>
> >> --
> >> Maf. King
> >> PGP Key fingerprint = 8D68 A91F 733B 2C1F 43B7  2B7C E591 E8E1 0DE7 C542
> >>
> >>
> >>
> >>
> >>
> >>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.