GNOME Bugzilla – Bug 95700
RFE: Allow for accrual and cash sales tax (VAT/GST) reporting in business invoices
Last modified: 2018-06-29 20:19:11 UTC
The Australian Goods and Services Tax system allows two modes of reporting: accrual or cash (with some restrictions). The latter is almost always a win -- you get to pay the tax later, so you get to use the money yourself for a bit longer -- so it should be easy to handle with gnucash. Unfortunately it's not: when you raise an invoice, you have to post it to the chart of accounts before you can print it (and send it to the customer, and get it paid), which means the tax entry is already posted to your chart of accounts too, and thus shows up in your reports. You can work around this by having separate "GST-receivable" and "GST-collected" accounts and adding a "correcting" transaction when you receive your payment, but that seems fairly annoying. Possible fixes: allow invoices to be printed before posting (helpful if you're doing draft invoices anyway); automate the correcting transactions as part of the "payment" handling.
Changed title to reflect more closely problem.
So I've had a number of people ask for this, but frankly I have no idea how "cash accounting" is handled from an accounting standpoint (my lack of accounting background showing through). Could you provide a simple example of what transactions get created (between which accounts) during the life of an invoice? In particular: 1) What happens when you post an invoice? 2) What happens when you pay an invoice? 3) And what happens if you only get paid for PART of an invoice?
For the record, I DO understand this now... Just haven't had time to ponder it or work on it, and probably wont for a while..
*** Bug 533019 has been marked as a duplicate of this bug. ***
Derek, I know it's been a while (2 years), but can you document your understanding so someone else can work on it?
Basically, the invoices themselves still need to be "outside" the COA, to some extent. Basically, you can touch A/R, but you can't touch Income until the payment happens. I just have no idea how to implement it.
*** Bug 634732 has been marked as a duplicate of this bug. ***
Derek: Thanks, I scanned only for the business component. So I adjusted the key fields now. Summary from Bug 634732 and the mailing list as of today: It is required at least for the following countries: AU, DE, GB/UK, NZ To implement this, we need a data file based option in the business section "Tax due date:" "invoice date" (default for backward compatibility) "payment date" and some mechanics either in process invoice/payment or tax report. IMHO the best way would be, to have a second account associated for each tax entry: tax undue x%. Such accounts exist e.g. in the german SKR account templates. In cash based mode posting the invoice would increase tax undue and payment would move it to the normal tax account. In the accruel mode, skip the undue account and increase direct the normal account as it is now implemented.
It matters in the USA as well, at least in terms of computing your Income and Expenses.
http://wiki.gnucash.org/wiki/Custom_Reports_Using_Eguile#Cash_Based_Income_Statement handles other aspects of the cash based accounting issue.
The way I have been getting around the Income statement issue with cash accounting is that just after the end of my accounting period (quarterly) I look at all the invoices and bills dated within the period. I then check whether they have been paid. If not I Unpost the unpaid ones and repost them dated the first day of the new accounting period. Now any reports done on the just completed accounting period are correct for cash accounting. Luckily I don't have too many invoices each period - so this is a relatively simple process. However it may be quite a task for people with lots of invoices and bills that are not paid until a later accounting period. One possibly simple way to implement a more automated approach to this would be to add an option about accrual vs cash accounting. When cash was used, then Posting an invoice would disappear as a manual step (i.e. when an invoice is created it is immediately printable and is only "posted" when paid - and only posted to the amount of the payment. This "posting" would need to be done automatically be GnuCash.
Wish to add some thoughts before making any changes to reports. Lifting from the https://wiki.gnucash.org/wiki/Cash_Based_Accounting wiki entry: "Couldn't the a report just pull from different date fields and determine when the money actually hit the accounts, thus building a cash based report?" I'm thinking of implementing the exact above in a refactored transaction.scm: Each split can be judged to be dated according to the posted date (as it's been done for years), optionally can be amended to the invoice-paid date. This means, when building the transaction report, the following will happen to the initial database query - if split relates to an invoice, we try locate the linked payment transaction; - if we find it we use the payment transaction date instead - if we don't then we skip it. This will require an option, likely within General tab [x] Use payment date instead of posted date for invoices Tooltip: By default the transaction report will use posted dates of transactions. This means, regular transactions are considered according to the date criteria above, but invoices & bills will be included according to the payment date instead of the posted date. This will be useful for cash-based accounting. While I'm fairly confident this will produce a useful transaction.scm for cash-based accounting users, I'm wondering if the long-term developers would be happy for this option. Or would it be better to introduce this option to the Business reports instead? Use case: Accounts/Accounts - select income & expense accounts General/Use Payment Date instead of posted date- ticked General/Dates - accounting period Report to be produced, sent to tax accountant.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=95700. Please continue processing the bug there and please update any external references or bookmarks.