GST Worksheet not reflecting correctly

11

And that is the problem. That is not enough for an accounting program. We are not designing websites here. In my opinion, it should work in all cases within the program, if you stick to standard accounting principles.

I did work according to international accounting standards. It took me hours to find and resolve the differences. Because the differences were created by mixed invoices from my suppliers and my journal entries. Both cases happen in reality and both cases shouldn’t be a problem for my Tax administration. Or at least I should get a warning. Or it isn’t possible to do so, but I can’t fix the problem accounting wise (and then I move to another accounting program).

Finally, the Dutch Tax authorities make cross references between the total of revenue reported via the VAT administration and the total of revenue reported when doing income taxes. If they don’t balance, it’s a reason for further investigation. And nobody is waiting for a tax inspection, if only it takes a lot of your time.

Because of these reasons I would advise you to or:

  1. Add an indicator per line for Sales Tax or Purchase Tax, and default them per document type.
  2. Use different Tax codes for Sales and Purchase (but you told me you don’t want to do this)
  3. Use an indicator per document for Sales Tax or Purchase Tax on receipts/payments and journal entries. You also suggested this, but this excludes mixed invoices . And for making Tax corrections via journal entries I think a document wide indicator makes it impossible to move tax from sales to purchase and vice versa.
2 Likes
12

I fully agree with what @IntoTheMirror suggests. It would solve this problem once and for all.
Indeed the Dutch Tax Administration make cross references between reported Sales/Revenue and what is recorded for Income or Corporation Tax.

13

Does this issue only apply to gst or dutch reporting? In the UK we use VAT so not sure if this problem affects Vat returns for when I next update Manager

14

IIt is the waty Manager calculaties and reports the VAT/GST that is not correct. Or in other words the mechanism behind creaties the problems. Probably the fact that the Dutch tax administration make cross references makes us Dutch users extra alert on proper VAT accounting and reporting

15

I was wondering why I never picked up on it. But then I just run the VAT Calculation and send it to HMRC. I don’t cross reference it with anything else. From what I have read, the issue seems to be mainly with Journal entry receipts and payments and I don’t really have anything like that as far as I am aware. Nothing that would affect VAT.

It’s an interesting discussion. Shows how complicated Accounting programs are.

16

In reliably identifying if a line item with a tax code is a sale or purchase, journal entries are the most difficult / likely to be wrong because they are often used for correction so the program has no real information to make the assignment. Also unlike invoices different line items may apply to different customers / supplier. In my option for journal entries it would be optimal if Manager supported a per line item selection of

  • Sale / purchase
  • Tax code
  • Customer / supplier

A possible user interface is shown in the following thread. Note per item Sale/purchase selection could be added prior to Customer/Supplier selection capability. When Sale/purchase selection capability is added it could default to the current arrangement so all old journal entries would not be effected. For new journal entries tax code selection could be shown only after sale/purchase is selected so always clearly defined for all new journal entries.

When a business interacts with another entity as both a supplier and customer, this is handled in Manager as described in this guide Offset simultaneous sales and purchase invoices which involves

  • Add the other entity to both Mangers supplier and customer database
  • Create a sales invoice (with tax codes) for the sales to the entity
  • Create a purchase invoice (with tax codes) for purchases from the entity
  • Use a payment/receipt (without tax codes) to fulfill the invoices with a line item for “Accounts receivable” and “Accounts payable” or a journal entry (without tax codes).

An equivalent process can be done for “Cash” sales & purchased

  • Create a receipt (with tax codes) for the sales with the entity
  • Create a payment (with tax codes) for the purchases from the entity

The above operating method is consistent and covers a large percentage of the market manager is likely to sell to. For Manager users who frequently interact with another entity as both a supplier and customer, it could be better. How best to improve it depends on the typical use case.

Were transactions are relatively independent but the other entity interacts in different ways, unifying the address book and supporting cross transactions and reporting would work well and is generalizable. This could be done by having a single “Contacts” or “Address book” which contained a single entry for each business entity together with a check box to indicate if they appeared in the Supplier, Customers, Employees, or Expense Claimer. Then relationships such as the following could be better supported

  • Suppliers and customers
  • Employees and customers
  • Suppliers with payment reporting requirements like employees
  • Expense claim payer and any of the above

For user where one transaction frequently includes both a sales and purchase component so is a ATO Bartering and trade exchanges, it would be valuable to have the ability to specify.

  • a line item on a sale document is a purchase
  • or a line item purchase document is a sale

As this is the reverse of how by the vast majority of users should use these documents, it has the potential to decrease the simplicity of use for the majority to provide desirable flexibility for a minority of the Manager user base. (I’m not saying it should not be done, I’m saying it should be a second level option most users do not see).

Edit: Details of journal entry Sale/purchase & Customer/supplier selection capability added

17

Any software solution to fix the GST worksheet issue yet? It worked fine before the update(s)- populating all GST worksheet labels correctly.
Thank you @Brucanna for highlighting the issue in detail.

18

What version of Manager is affected by this issue. I don’t want to update Manager until this issue is resolved if it’s going to mess up my VAT returns in any way on the off chance I have any Journal entries that would be affected by this issue. I am currently running 20.7.31

19

And this is the problem, the way YOU have intended is not the reporting requirement.
Previously Manager did meet the reporting requirements - and Users weren’t complaining but now that are.

I totally agree with the implemented concept that only one code is required.

However the problem @lubos, appears to be, that you have changed to using the “Transaction Type” to determine the GST/VAT Sales or Purchases where in actual fact “Transaction Type” is irrelevant as the tax is a Levy on Supply NOT transaction.

Up until recently, the worksheet reporting wasn’t broken, that is. it didn’t report every line item as a sale. I don’t think you can hide this problem behind the GST error banner, as the User (a mistake you made) is not making the error, the accounting software is making the error.

What no one understands is why you needed to break something that wasn’t broken

Unless the VAT Return is designed so that the two (VAT Revenue and Income Revenue) are to be reconciled I am unsure how they can cross reference. A Business can receive VAT Revenue which is not Income Revenue, such as when selling a fixed asset. Besides in countries where Income Revenue is accrual basis and VAT Revenue is cash basis, cross referencing can’t occur due to timing differences.

Yes, but this ONLY applies when there are independent separate transactions between the two, that is, the transactions are unrelated - one is selling vehicle servicing while the other is selling vehicle spare parts. This offsetting relationship DOESN’T apply under the circumstances of a Recipient Created Invoice as there AREN’T separate Customer / Supplier transactions, JUST a Supplier transaction which has mix of sale / purchase items. Under a Recipient Created Invoice there is NO Customer transaction so there are NO invoices to OFFSET.

In closing, I am currently preparing a post which will be approx. two A4 pages in length, so 5 minutes or more in reading, based on my involvement with a consolation team which was involved in implementing GST in several countries - hope to have it completed in the next day or so.

20

That’s not correct. Users were complaining about previous implementation as well…

See Goods return (Cash sale/purchase) causes Gross Sales error

Also consider this example:

image

  • Under previous model, this would result in $360 in total sales and $120 in total purchases (because every credit is sale, every debit is purchase)
  • Under current model, this very same transaction will result in $240 in total sales (because every line item on receipt is a sale)

You and others in this topic strongly feel the previous model is correct. A lot of users think the current model is correct. And a lot of users couldn’t care less as it doesn’t affect their tax payable under neither model.

I can see solid arguments on both sides.

The challenge I have here is to come up with new model which will work for both groups of users without increasing complexity for users who couldn’t care less.

4 Likes
21

I fall into the category that I couldn’t care less about which method is best as long as it doesn’t affect my VAT return amounts that I send to HMRC. Perhaps I misunderstood the topic but I thought that the whole issue is that the changes do affect the VAT/GST return value that one sends to the taxman making previous tax returns inaccurate. I am ready to be corrected on that point.

22

All the changes being discussed have no effect on “Tax liability” reported in the “Tax Summary” or report transformations of this. Similarly in the “Tax reconciliation” there is no change in the “Total”.

The issues being discussed do effect the break down of sales and purchases in both reports.

If the later actually effects you, you will need to decide if you are most concerned about

  • If your reports reflect your understanding of the transactions your business has been involved with, ie are the numbers correct in past or future reports.
  • Or are you most concerned that the numbers a different.

As the solutions are different for these 2 issues. The later is solved by some form of backup / archiving. The former by understanding what you believe the numbers should actually show.

23

@Lubos,

Thanks for your reaction in this topic.
As Manager is a professional tool, It should work as a professional tool, which means that it should calculate VAT the proper way, even if this means that complexity could increase. As a matter of fact Manager.io is not a toy. If people start using Manager.io not having any clue what accounting is, it is a pity for them. I sincerely hope @Lubos will come up with a new model which takes away and eliminates the current ommission.

24

The issues being discussed do effect the break down of sales and purchases in both reports.

Does anyone knows what the appropriate IFRS says about issues like these?

25

Pretty sure this would be out of scope for IFRS since none of this affects standard financial statements.

26

The problem with this example is that the second line is using the wrong Account.
The promotional buy is NOT a reduction in total sales but a marketing expense, hence the debit.
In effect, the business is “purchasing” the third pair on behalf of the customer.
.
What if the promotion was buy 3 and get cash back for one.
The total sales would still have been $360, and the marketing expense $120 would have been a purchase (debit) when the cash back was paid. The cash back does not reduce total sales.
Once again, the business is in effect “purchasing” the third pair on behalf of the customer.

The accounting result (income $360 expenses $120) doesn’t change just because the transactions were conducted differently,

Therefore “Under previous model, this would result in $360 in total sales and $120 in total purchases (because every credit is sale, every debit is purchase)” was totally correct.

And furthermore why “Under current model, this very same transaction will result in $240 in total sales (because every line item on receipt is a sale)” is totally incorrect because you can have genuine line items that are purchases on a receipt, nothing to do with sales.

Take this example of a Livestock sale, where the Stock Agent sends you the sale proceeds.

0000000 Bug 6
0000000 Bug 61075×225 23.6 KB

Now “Under previous model, this would have resulted in $4800 in total sales and $426 in total purchases (because every credit is sale, every debit is purchase)” which is totally correct

However "Under current model, this very same transaction will result in $4374 in total sales (because every line item on receipt is a sale) which is totally wrong.

Now lets review the BAS lodgement perspective. In the March quarter under the previous model I would have reported Sales as $4800 and purchases as $426 which accurately reflected the nature of the transactions. However the June quarter under the current model I would have reported Sales $4374 and purchases as $0 which inaccurately reflects the nature of the transactions.

Furthermore, as a Taxpayer I am NOT going to start reporting genuine purchases as negative sales therefore the current model worksheet, for a Livestock Producer, has become totally USELESS as it doesn’t contain one accurate value, which was not the case previously.

This model change doesn’t just affected the Livestock Producer, it also affects all these other industries, Property Rentals, Produce Markets, Auction Houses, Publication Distributors plus many others, where ever Recipient Created Invoices are used as they ALWAYS contain both sales and genuine purchase line items - not negative sales items.

I don’t understand why Manager has to do anything for any particular user group. The previous model produced by Manager had a solid uniform basis (every credit is sale, every debit is purchase) and where ever a User had a transaction which didn’t suit this basic model, then the User always has the freedom to make amendments to the worksheet so that it correctly reflected their position / interruption with regards to those transactions. The worksheet is just that a worksheet and Manager just has to educate Users to that fact and not attempt to manipulate the basic worksheet into something to suit every possible User because it will just becomes to complicated / cumbersome.

It appears, in my opinion but I could be wrong, that Manager could be reacting to the promoted falsehood (in fact stupidity) that a single transaction can’t be both a sale and a purchase at the same time. All the examples above clearly prove that to be wrong.

1 Like
27

And this is a great example.

When users use manager that way and it currently works, and other users have adapted to it being that way, then if you decide that it should now work “the other way”, you must expect there will be problems.

You shouldn’t make changes to the underlying fundamentals that users rely on. @Brucanna’s example above classically illustrates this.

Fundamentally you have changed what manager reports to users, which they invariably report to their accountant/tax authorities.

28

I posted about similar issues in the past with RCTI type entries.

I know a single vat/GST code would be nice. But perhaps it’s time to ask why other products have multiple tax codes. Perhaps they got it right and there is a reason for it.

I’m not suggesting that you blindly copy other products. But sometimes we can learn from others mistakes and successes.

After a lot of struggles I now enter a sale, a purchase and then a single receive money entry ( with positive amount against the sake and a negative amount against the purchase. Much more effort but it does seem to report correctly in manager.

Note you need two copies of the 3rd party. One as a customer and one as a supplier.

29

Further to my previous post, at the time the reporting engine reported against a receipt or payment entry (but could not report per line item). This made things difficult to report. Not sure if that has changed.

30

In some jurisdictions, the supply of goods on a buy one, get one free etc is not considered a gift and would bot be treated as shown above