GST Worksheet not reflecting correctly

[vez]

I have been using Manager desktop version 15.0.68 for some time. I get recipient created invoice where there are three items mainly. Most of the income is GST free with a small amount of Income with GST. The client deducts his Service Fees+GST and remits the balance to my Bank account. I have been using Bank receipts and entering the line items as:

Income GST Free
Income with GST
Service Fee GST10% - entered as -ve amount.

This worked fine with the correct amounts reflecting in the GST Calculation Worksheet at the respective labels.

However, when I started to use the current version 20.8.1, it adds the Income with GST and Service Fee (one being Sale and the other being Purchase- in GST terminology) and reflects the Net (a -ve figure in this case) at label G6. Also the G1 Label, which is the Total income, shows incorrect figure. Although the Refund figure remains the same with both old and new versions.
I have done the localization and checked the Tax codes. The PAYG payment summary-INB and the STP reports are correct.(Australia).The Profit and Loss Report is not effected.

When the Income and Service Fees are entered as separate transaction, the Worksheet reflects the correct figures at the different labels but the Bank transaction in Manager do NOT reflect the Bank Statement.

Could anyone help please. Thanks

[Patch]

Enter sales by a sale invoice or receipt
Enter purchase by a purchase invoice or payment

Edit
Note this will enable sales to be linked to customers and purchased to be linked to suppliers in the future.

[vez]

That gives multiple transactions in the Bank account. The payer deducts Service Fees+GST and remits the balance. It worked fine with the older version.

[Brucanna]

@vez

Could anyone help please. Thanks

I am not seeing your problem - here is the Receipt entry with the Service Fee being larger than the Income with GST and entered as a negative.

And this is the GST Worksheet

Perhaps you could post a screenshot of your transaction entry, so one could replicate that.
PS - Ignore the “Joe Blow Advance”, its a hangover from another test transaction.

[Brucanna]

Ok , @vez, I have just updated to Ver 20.8.10 and now get your situation.

I will report this as a Bug, but in the meantime, the worksheet is just a worksheet, so can enter amendments on it to reflect the actual return.

@lubos, the GST worksheet’s handling of the same transaction has changed - refer to screenshots. The worksheet screenshots are from viewing the same created report.

This indicates that worksheets created prior to the change will now report differently.
The only action I took between the worksheets, was to update Manager

[Patch]

In my opinion it is a correction of a prior inconsistency in Manager, Cash sale now behave the same as invoice sales. Each transaction is a sale or a purchase not both. The user can now specify if a line item in a cash transaction is a sale or purchase, and important functional capability as ultimately it is up to the user to determine and take responsibility how each line item is classified.

[vez]

Thank you for your response. I was a bit disappointed with earlier responses to the issue and thought to maintain the older version for the GST Worksheet and the Latest version for the other reports (Aus). I’ll try to see if I can obtain a similar report. Once again thank you for the great illustration of the example that exactly depicts my situation and the image of the report. Highly appreciated.

[vez]

Here are the screen shots to show the situation:

[Brucanna]

@Patch

In my opinion it is a correction of a prior inconsistency in Manager,

Let me put it this way, @patch in your earlier version of Manager you created a GST worksheet for a particular period, you validated the data and lodged that data as your formal BAS return. That is, the data on the worksheet and the BAS return “exactly” match

Now the only action that you have undertaken, is the updating of your version of Manager. Upon re-viewing that GST worksheet you now note that the values on that worksheet are no longer the same as on the previous one, they no longer match the BAS return. In fact, all your previous GST worksheet have now been completely re-written, they no longer support any of your previous BAS return lodgements.

Therefore @patch, I look forward to your opinion as to why it is acceptable for Manager to completely re-write a User’s worksheets so that they no longer support their BAS lodgement.

Furthermore, if you had studied and understood the example provided in the screenshots then you would have noted from the transaction’s details that a line item which is a genuine expense and CORRECTLY reported as a GST Purchase in the original worksheet has upon the software’s update been converted to a negative GST Sale.

So once again @Patch, I look forward to your opinion as to why it is acceptable for Manager to convert genuine purchases into negative sales, which is in complete breach of the ATO reporting requirement.

@Patch

Cash sale now behave the same as invoice sales.

As far as I am aware, ever since Manager has existed Cash Sales and Invoice Sales have always behaved the same and correctly, so I have no idea as to what you are referring to here.

@Patch

Each transaction is a sale or a purchase not both.

If you are suggesting that a recipient created invoice transaction from a Supplier can’t contain both sale and purchase line items then clearly you don’t understand accounting. All these industries, Property Rentals, Livestock Sales, Auction Houses, Publication Distributors plus many others can’t operate on an accounting basis without their transactions (recipient created invoices) containing both sale and purchase line items.

To imply that these industries, and the business that operate within them, are somehow using inappropriate accounting by combining sale and purchase line items within a single transaction is preposterous

Prior to the introduction of the GST, their transactions were conducted without conflict with any accounting standard, and with the introduction of the GST this DOESN’T CHANGE the conduct of the transaction with regards to any accounting standard. The GST is an adjunct to the accounting transaction.

Furthermore, if you are also suggesting that Manager has changed their worksheet calculation methodology because of the implied implications of “Each transaction is a sale or a purchase not both” then Manager is being misguided as the statement has no VALIDITY and has put itself in conflict with ATO GST reporting requirements, that is, it is reporting GST Purchases as negative GST Sales.

In addition, from an accounting’s professional perspective, if a registered accountant has proposed this absurdity "Each transaction is a sale or a purchase not both " then they should be reported and be de-registered as they aren’t a fit and proper person to be an accountant.

@vez, thank you for providing the examples which depict your situation.

[lubos]

This is not GST Worksheet issue, it’s a general issue how Manager decides whether something is a sale or purchase. For invoices, that is easy but for receipts, payments and journal entries - this is unresolved problem.

There is much bigger topic discussing the same issue here:

Why do the costs on a journal entry show in the net sales column?

I posted a purchase invoice in Q1. I reported the VAT. Then, in Q2, I discover a tax error. I use a journal entry to post the costs credit with the wrong VAT code and debit with the correct VAT code. When I want to report the VAT of Q2 I’ve noticed that the transaction is in the Tax summary report in Q2 in the (details of the) Net Sales column!!! Why? The revenue I report for the VAT to the Tax authorities is now higher then the revenue in my P&L (revenu, not profit), which I use to report my i…

Other accounting systems are simply addressing this issue by using separate tax codes for sales and separate ones for purchases. E.g. GST 10% on Sales & GST 10% on Purchases. I didn’t want to go down this route because it results in duplication of tax codes and it most cases - Manager can figure out whether GST is charged on sale or purchase on its own so it has just one GST 10% tax code.

The issue is that on journal entries, receipts and payments, Manager can get it wrong. I still think I made the right call to have single tax code to cater for both sales and purchases because it doesn’t really matter whether merchant fees are reducing GST sales or increasing GST purchases. The net tax liability is the same. As far as I know, no tax authority (including ATO) considers movements in tax sales and tax purchases an error if the net tax liability is unchanged.

As per Correcting GST errors | Australian Taxation Office

A GST error is a mistake you made in working out your GST net amount on your activity statement that would, if it was the only mistake that you made, result in you reporting or paying too much GST (credit error) or reporting or paying too little GST (debit error).

So as you can see, from ATO point of view, if your BAS worksheet figures change, it’s non-issue as long as your net GST is the same.

@vez

However, when I started to use the current version 20.8.1, it adds the Income with GST and Service Fee (one being Sale and the other being Purchase- in GST terminology) and reflects the Net (a -ve figure in this case) at label G6. Also the G1 Label, which is the Total income, shows incorrect figure. Although the Refund figure remains the same with both old and new versions.

So your refund figure remains the same. It’s non-issue for ATO.

I don’t consider this to be a bug because Manager currently works the way I have intended for it to work.

• Sales invoices are sales
• Credit notes are negative sales
• Purchase invoices are purchases
• Debit notes are negative purchases
• Receipts are sales
• Payments are purchases
• Expense claims are purchases
• Journal entries are either sales or purchases based on the amount being credit or debit on line item

This model works well for most cases. It obviously breaks down when receiving refund from supplier which would be a receipt. You would expect this receipt to be negative purchase but Manager will classify it as a sale.

It also breaks down when adding purchases (e.g. service fees) to sale transaction such as receipt. Every line item will be a sale.

[IntoTheMirror]

@lubos

This model works well for most cases.

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.

[Hennie]

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.

[dalacor]

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

[Hennie]

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

[dalacor]

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.

[Patch]

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.

Inconsistency in Tax-reporting

Thinking further about Journal entry level vs Journal line item level specification of Sale/Purchase and Customer/Supplier. I’m not sure it is possible to reliably specify these at the Journal entry level. To explain, consider a relatively simple example: A sole trader goes to one of his suppliers Makes a “cash” purchase Pays an outstanding invoice Uses his personal credit card instead of the his work card Chooses to later enter the transaction as a journal entry rather than a net zero value …

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

[vez]

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.

[dalacor]

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

[Brucanna]

@lubos

I don’t consider this to be a bug because Manager currently works the way I have intended for it to work.

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.

@lubos

I didn’t want to go down this route because it results in duplication of tax codes

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.

@lubos

It also breaks down when adding purchases (e.g. service fees) to sale transaction such as receipt. Every line item will be a sale.

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

@IntoTheMirror

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.

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.

@Patch

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

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.

[lubos]

@Brucanna

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.

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:

• 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.