Entering BAS payment with DGST in one transaction
Hi All
I usually enter my bas through spend money which is pretty easy except I am constantly forgetting to add the DGST (Deferred GST on imported goods) amount to the DGST Liability account. The other problem I have found is that we have recently had some humongous bills so we have been on a payment plan. So I have set up a liability "clearing" account so that I can put the figures in and then as the payments go to the ATO they pay off the liability.
My question is this. Currently this involves me doing quite a few transactions. I was thinking life would be much easier if I could do a GJ on the last day of the month with all of the figures Crediting the Clearing account so that I can put the DGST into the same transaction and therefore 1: not forget it and 2: have everything in the one place.
So far I was thinking:
Now, to CREATE the deferred GST, we used to just do:
Spend money from DGST so it went:
What are the repercussions if I ditch the purcase account + and - and just put in the GST paid and DGST figures into the journal entry. It would look like this:
The purchases have all been entered as "FRE" tax code so it isn't like they aren't in the purchase journal already....
Thoughts?
Hi TTASK
I would recommend speaking to an accountant in regards to the account and reporting requirements implications of recording that journal entry
From an AccountRight point of view, ideally, the only time that you should be directly recording a transaction to the linked tax collected and tax paid accounts is when you record a payment (or credit) to the ATO. Outside of that, it can lead to differences with GST Reports and reconciliation.
It should be also noted that as the GST reports and BASLink will look at that tax code involved in the transactions, not the linked tax collected and tax paid accounts. For example, rather use the GST code on an transaction you added another line to associate the GST amount to the GST paid, this value will not appear in the GST Report and BASLink as it would be looking at the tax code of that transactions, not the accounts involved.
