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

[Brucanna]

Firstly, it’s noted that your “use case” totally ignores the reporting of GST received from Balance Sheet transactions - which are an integral part of the GST system…

@Patch

Businesses who report Gross sales (for example Australia BAS item G1)

This is where you keep making the same repetitive mistake.
You don’t report “Gross Sales”, you report Total Sales as per the Worksheet item G1 title.
For GST purposes, Total sales equates to all transactions where GST has been received regardless if they relate to the balance sheet or the profit & loss (income or expense).

You repeatedly seem to be under the false illusion that somehow the Worksheet item G1 “Total Sales” must reconcile with Profit & Loss sales, whilst this may occur in the absence of balance sheet and refund transactions, it is not mandatory nor a tax department requirement that they reconcile.

If there is be any correction then the titles on the Tax Summary report need to be corrected:
For Sales they could be Net Revenue, Tax on Revenue and Total Tax Revenue.
So that GST revenue is seen separately and distinguishable different from GST sales.
Just as the reports reference to GST Purchases is completely different to Profit & Loss expenses.

It is noted that whilst you have a hang up on reconciling the sales side of the GST you don’t seem to have the same difficulty with the non-reconciling occurring on the opposing side of the worksheet - purchases. GST Purchases rarely equates to Profit & Loss expenses.

It also noted with extreme concern your “Short term solutions to avoid the bug”, especially point 2. To suggest that one should record their transactions in contradiction to the source document so as to generate a GST outcome brings in to question your suitability of being an accountant.

Lastly, you noted a user’s post as being “Rubbish”. To date, after being requested, you have failed to provide any formal support to justify your belittlement of that user’s post. That conduct is unacceptable on the forum.

[Patch]

Looking further, the underlying problem is when Manager does not have sufficient information to determine if a transaction is a sale or purchase, it takes a guess. As a result the totals for sales and purchases are guestimates not actual sales and purchases totals. The solution is for Manager to use guesses to enhance the user interface but always verify any program guesses prior to accepting financial data input.

In more detail

When entering transactions via an invoice, Manager can unambiguously determine if a transaction is a sale or purchase, as separate tabs are provided. It uses this information to process all line items in the transaction and maintain accurate sale and purchase totals for each tax code.

When entering a transaction via “Receipts & Payments” or a “Journal Entry” Manager does not have definitive information to identify if the transaction applies to a sale or purchase. The current design is for Manager to guess. The guess it make is for each line item

• Assume every credit entry is a sale so increases the sales totals (for that tax code)
• Assume every debit entry is a purchase so increases the purchase totals (for that tax code)

The corollary of these assumptions is it:

• Implies a negative value purchase adjustment is exactly the same as a positive value sale adjustment
• Implies a negative value sale adjustment is exactly the same as a positive value purchase adjustment

As a result in Reports → Tax codes, Tax Summary actually displays

Label	Mathematical content
Sales	(Line items in JE or R&P decreasing Purchase) + (Line items in JE or R&P increasing sales) + (actual Sales entered via invoices)
Purchases	(Line items in JE or R&P decreasing Sales) + (Line items in JE or R&P increasing Purchase) + (actual Purchase entered via invoices)
Tax liability	Actual tax liability

Some examples where Mangers guess results in false accounting records and reports

Goods returned, illustrated for a purchase but the same occurs with sales

Deposit required prior to work commencing with the balance on completions.

Special offer involving refund of cost of one of the items if a bulk purchase is made

Some financial adjustment such as exchange rate adjustments or credit card fees

Manager is an accounting program, reporting false accounting data is a serious bug.

Solution

The best way is to structure Managers user interface so when ever a tax code is entered, it can unambiguously be classified as a sale or purchase. On Receipts & Payments that could be done by allowing the user to specify if it is a sale or purchase as describe in the Why do the costs on a journal entry show in the net sales column? - #57 by Patch thread. The user interface changes for which maybe as simple as allowing the user to change between Sale/Purchase instead of Receipt/Payment after selecting they want to create a receipt or they want to create a payment.

Worse solutions

Only report the difference between purchase and sales. All users who are currently using the sales or purchase data separately would object however these are the same users currently reporting false data.

Remove the ability to use tax codes on journal entries as well as Receipts & Payments. This would result in a significant decrease in program functionality if permanent but is probably a good idea when Sale/Purchase status is unknown.

External correction of Managers accounting error

The incorrectly classified purchases line items (negative) can be found with the following custom report

The equivalent for incorrectly classified sales line items (negative) can be found with the following custom report (Replace “Payment” with “Receipt” and “Amount” with “Amount (sign reversed)”, & update report name

Which displays Managers purchase accounting error. In this test business it shows

Which can be manually subtracted from the sales and purchase data in the tax summary to correct the purchasing accounting errors (Note in this test case no real sales were entered).

Edit
The external correction solution described above works because:

• Managers core data entry error is, it does not know if a line item on its own pertains to a sale or purchase

• Manager users enter most Purchase transactions as “Payments” and most sales transactions are entered as “Receipts”

• If the Manager user reads the “Payment” / “Receipt” drop down to mean “Purchase” / “Sales” (typically the only thing a user would need to check is returns are entered showing a negative amount) then Manager does have a definitive way of identify every purchase and every sales line item. Hence the above custom report works.

• Manager could implement this internally simply by looking at the existing Receipt / Payment flag to deciding if a transactions a Sale or Purchase. Unfortunately the resultant correction of some old locked data would cause some users a problem. So fixing the problem requires something like this solution.

[Hennie]

I want to share my opinion about this discussion and tell you what I did.
I opened a new test company and created a petty cash account and one expense account and the 21% VAT code for the Netherlands. With petty cash I bought for € 100,- excl Vat ( € 121,- incl VAT) a harddisk and after a couple of hours I decided to return this disk. I got my € 121,- back. The purchase I booked as a payment on the expense account and the return of the disk as a negative payment on the expense account.
What does Manager:

• the negative payment is shown a receipt (???)
• my P&L shows no result which is correct
• the tax-summary shows € 100,- as sales and € 100,- as purchase which is wrong
• the draft VAT tax return shows a gross sale of € 100 and € 21,- as tax to be paid and € 21,- as reclaimable VAT. This is wrong it should show only zero values. The balance due is 0,- which is correct.

I don’t want to be rude but this is absolutely wrong. The same happens with journal entries.
The reason why it is wrong is because of the fact that on all VAT related reports, every credit-transaction on a VAT-code is reported as a sale and every debit-transaction is reported as a purchase. The P&L shows the correct values because it shows what is booked on the G/L account. The Dutch tax-authority takes samples of what the reported sales in the P&L and what is reported in the VAT tax-returns with the question can you explain the differences.
Lubos really has to dive into this because it is a serious bug in Manager. Not all VAT-credit transactions are sales and not all debit VAT transactions are purchases. With payments and receipts and journal entries there should at least be a possibility for the user to decide where he/she wants the VAT to be reported. I sincerely hope this gets a very high priority

Kind regards,

Hennie

[Tut]

With great respect, @Hennie, I disagree with the position you and @Patch advocate. The P&L shows net balances in accounts. The Tax Summary shows totals of purchases and sales and the taxes associated with them.

From an accounting perspective, a return of merchandise is a sale. It is indistinguishable from any other receipt. You have sold the item back to the same merchant from whom you bought it.

@Hennie

The Dutch tax-authority takes samples of what the reported sales in the P&L and what is reported in the VAT tax-returns with the question can you explain the differences.

This is a valid question for the tax authority to ask. And you will be able to answer by drilling down on amounts in the two reports and comparing transactions. Those who have been through tax audits will probably agree that tax authorities ask all sorts of questions, some predictable and some totally unexpected. But I have never encountered a situation where a reasonable explanation, backed up with accurate data, proving the accuracy of the final numbers, was not a satisfactory response.

I have been puzzled by the passion this topic has generated. I do not see it as an issue.

[Hennie]

With great respect, @Tut, I fully disagree with you that from an accounting perspective a return of merchandise is a sale. It is a reversal of a purchase and not a sale. I bring it back to the shop where I bought it and I’m not going to the computershop to sell them a harddisk. Everything in me says it is not a sale and I think a lot of people (accountants) will agree upon this.
When I make a journal-entry to correct things that went wrong, Manager should treat the VAT the way I want it. Now it is very rigid: credit postings on a VAT code are treated as a sale and debit postings are treated as a purchase. I want to be able to decide how and where the VAT is booked or in other words as a correction on a purchase or as a correction of a sale.

There is indeed passion in this topic, because it is very principal and then indeed it becomes an issue.
Manager is the only accounting-system that doesn’t offer me the possibility to book things the way I want and that is because of the very rigid idea that credit=sales and debit=purchase.

At least I hope that @Lubos gets convinced and will take action upon this issue.

[Tut]

@Hennie

It is a cancellation of a purchase and not a sale.

I would say a reversal, not a cancellation, because you are not deleting the transaction which originally recorded the purchase. But we are down to semantics. There is no point arguing over those.

[Hennie]

Indeed is a reversal, not a cancellation (sorry for my bad English), so I edited my post.

[Patch]

Interesting
As to why Manger users would consider this important

1. Manager reports Purchases separate to Sales by tax code. If you really believe no jurisdiction requires this then, Manager should just report the difference.

2. The tax summary report is the principle report used to submit VAT/GST reports to the taxation department. Almost all have significant penalties for submitting false information.

3. Manager is principally and accounting program. It can help in other areas as well, but accounting is it’s foundation. If it can not produce accurate accounting records for submission to local tax authorities, it has a core requirement defect.

4. The behavior identified is not new. As a consequence it implies many Manager users have been submitting false records to their tax departments for a long time. A challenging thought and not good for Manger sales.

As to is there an issue at all.
Even before we address what effect individual physical transactions should have on reported sales or purchase, consider the process at a more abstract level.

1. A physical business purchases & sells, goods & services

2. An accounting system is used to record the business transactions. The accounting system uses accounting conventions consistent with local legislation.

3. Taxation data is submitted to local tax authorities based on the physical trade the business has done and the accounting conventions adopted.

The critical point of the above description is for a given physical trade and accounting conventions the reported taxation information is fixed number not a range of values. There is a right answer and other numbers are false.

Now consider all 4 examples listed above

1. Each involves a fixed activity on the shop floor, with fixed goods and services changing hands, and fixed physical documentation from each of my suppliers.

2. In each my book keeper could enter, apparently validly in Manager as shown in the “Payments” edit screens above (and generate reportable sales in Manger).

3. In each my book keeper could enter, apparently validly via invoices in Manger and generate no reportable sales in Manager.

4. In each case Manger is reporting a different reportable tax for the same physical transaction and adopted accounting convention.

If accounting conventions really dictate that the sales generated when entered these transactions as a Manager “Payment” is correct then Manger has a bug in how it calculates sales when entering these transactions via an invoice (which I don’t think anyone really believes). My point is for a given physical trade and adopted accounting conventions there is a right answer, other numbers generated by my book keeper and software are false.

Finally we can look at the details of all 4 physical transactions described.

Goods return: Some suppliers have a sales policy which includes a goods return option. The return option requires a valid sales receipt (which is edited when the goods are returned), is valid for a limited duration, is priced at the prior sale price (some with a restock deduction) not the suppliers normal wholesale purchase cost, and when I return (?sell) the goods I do so without providing a warranty. In summary the goods return process is contractually not the same as a sale. It is processed correctly in Manager if a Manager invoice (or Manager Debit note) is used and incorrectly if entered directly in Manager via the “Receipts & Payment” tab (without an invoice or debit note).

Deposit deduction: When final payment is entered without an invoice Manger treats deduction of the prior deposit as an additional sale. Clearly no goods or services are delivered for the “sale”, it is purely a correction to the current “Payment” for a prior payment towards the documented goods & services. It is processed correctly in Manager if an invoice is entered first in Manager and incorrectly if entered directly in Manager via the “Receipts & Payment” tab (without an invoice).

Bulk purchase discounts: Some suppliers offer a discount if a particular threshold amount is purchase at one time. Deducting the cost of the last item or some other dollar amount. In no case is the purchaser providing any goods or service, they are only receiving a deduction in cost on the current purchase. It is processed correctly in Manager if an invoice is entered first in Manager and incorrectly if entered directly in Manager via the “Receipts & Payment” tab (without an invoice).

Some financing adjustments: depending on the details of the payment used an adjustment some times negative maybe required for exchange rate variations or credit card fees. Typically they are an integral part of the financial transaction (zero without the underlying transaction occurring). When negative they do not suddenly become a new income for the business instead they remain and adjustment to the underlying (in the illustrated case) purchase. It is processed correctly in Manager if an invoice is entered first in Manager and incorrectly if entered directly in Manager via the “Receipts & Payment” tab (without an invoice).

In Summary

• Manager has a serious bug in how it records taxable goods and services when a Manager invoice is not created which results it corruption of the amount shown in the “Tax summary” report

• It can be masked by not relying on Managers “Tax summary” or any of the “VAT/GST calculation worksheet” localisation (as they all use the same data). Doing so involves also using 2 custom reports and external calculation. Journal entries need to be individually examined.

• It can be fixed within Manager but as it has been known about but not fixes for many months, correcting it is not trivial

• An accounting program which makes accounting errors in tax reports may well be a Marketing problem for the software and difficult to accept for the users who have submitted incorrect taxation data for years, but the solution is to fix it not deny it is a problem.

[Brucanna]

I am going to make one final comment.
The problem with accountants is that they can only see things in accounting terms.
The tax authorities are not accountants, they are tax collectors, although some maybe accountants but its not a prerequisite.

As I have repeatedly stated - when it comes to GST/VAT Tax Sales & Purchase, it is not referring to “accounting” sales and purchases. It is referring to where GST/VAT Tax has been received or paid. In fact it would be clearer (even for accountants) if the authorities actually called it GST/VAT Received and GST/VAT Paid to remove the accounting connotation of sales and purchases.

@patch your deposit deduction example is flawed. Deposits, not being a goods or service, are financial transactions and as such don’t have tax implications. When you deduct a deposit, you don’t also give a tax refund, as no tax code should have been applied to the receipt of the deposit.

You repeatedly assert that using Manager “results in false accounting records”.
If that is genuinely the case, then WHY are you using Manager.

It’s noted that even though you have been requested several times to provide official documentation to support your assertions that Manager is flawed - you have repeatedly failed to provide such proof.

Writing paragraphs of self fulfilling verbiage doesn’t equate to Manger functioning unlawfully.

[Patch]

@Brucanna

using Manager “results in false accounting records”.
If that is genuinely the case, then WHY are you using Manager.

I made the assumption Manager was an accounting program and would take program errors which result in false accounting records as a serious issue which would be addressed with an appropriate priority.

I did not make the assumption Manager was bug free. All programs contain bugs. Coding and program design bugs increase as program complexity and development rate increase. Manager is a complex rapidly developing program, as such a high frequency of bug discovery is to be expected.

As to details of the specific examples, all contain negative line items in which Manager’s error is to swap between customer and supplier. In the case of the deposit an identical tax code must be applied to the required tax code used when the deposit was accepted. The actual tax code applicable varies with jurisdiction but in all jurisdiction it is an negative valued purchase line item not swapped to a positive valued sale line item. It is processed correctly in Manager if an invoice is entered first in Manager and incorrectly if entered directly in Manager via the “Receipts & Payment” tab (without an invoice).

[Brucanna]

@Patch

I made the assumption Manager was an accounting program and would take program errors which result in false accounting records as a serious issue which would be addressed with an appropriate priority.

If that was the case (false accounting records) then Manager would address it with priority.
However, nothing that you have illustrated has proven that Manager is creating false accounting records. What your commentary has shown is that you don’t understand or can’t distinguish the difference between Manager the Accounting Software and the Add-ons used for external purposes.

But first lets clearly debunk your false and misleading claim regarding the false accounting records.
Using your own data (per below), lets process it as both a Sales Invoice and Cash Receipt.

Now if one drills down on the Tax Payable account you will clearly observe that both accounting transactions have been processed in EXACTLY the same manner.

Therefore, where within the Manager Accounting Software are these programme errors occurring which are generating “YOUR” claimed false accounting records ???

Your original issue has nothing to do with Manager the Accounting Software but with the Add-on feature of GST taxation reporting, which is external of the Accounting Software.

Now to simplify your original issue without all the bloated verbiage, you contend that the GST taxation reporting sub-totals being generated were incorrectly accumulating the source data. Furthermore, you hold this view because of the accounting processing of contra transactions.

However, what you haven’t grasped even though it been explained several times is that GST taxation reporting is NOT accounting reporting. Manager’s generated sub-totals complies with the requirements of GST taxation reporting.

To illustrate this with your phone purchase / refund example. Whilst the two transactions may result in an accounting contra, for GST taxation reporting they are not a contra but two stand alone transactions. Whenever you receive GST then it is a GST Sale, regardless of the GST being received via a refund or selling to a third party. Any GST received can’t be a negative GST Purchase.

The basis behind the GST transaction is not relevant to the tax authorities. Their sole focus is the collection of GST. This is different to Income Tax reporting.

As always, if you can provide official documentation to the contrary then please submit it.
It is noted that all previous requests have resulted in your failure to provide such.
You need to note that your personal perspective alone is not going to have any validity.

[Patch]

@Lubos/Brucanna

It appears we are talking about different things. The above post describes how to investigate a coding bug. Manager does not have a coding bug, it behaves as designed. It has a design bug.

It appears there is a variety of opinions on what defines a taxable sale/purchase (and standards accounting software must achieve).

Option 1: Every credit line item must be a sale for tax reporting. Every debit line item must be a purchase for tax reporting.

This interpretation is hard coded into all Journal entry, Receipt and payment so these transactions are consistent with this interpretation. However if this convention is correct then the encoding of debit notes, credit notes, and negative amount line items in invoices, are all incorrect. As a result sales & purchase totals reported in Manager are lower than this accounting convention dictates.

Option 2: A taxable sale or purchase is defined by jurisdiction specific requirement on the goods / service provided, supplier obligations, and purchaser obligations.

This interpretation is hard coded into all invoices, credit notes and debit notes in Manager so are consistent with this interpretation. However if this convention is correct, then all negative line items in sale and purchase “cash” transaction and about half journal entry line items, are all incorrect. As a result sales and purchase totals reported in Managers are higher than this accounting convention dictates.

Most jurisdictions have specific invoice documentation requirements to enable claiming or when charging / collecting taxed supplies. When making a taxed sale, an invoice must be issued by the seller to the purchaser (and include jurisdiction specific requirements such as VAT amount and type, sales total, time limit from sale to invoice delivery). Conversely when making a purchase, to enable business to legally claim a tax credit, an invoice from the seller is required (meeting jurisdiction specific requirements including purchase total, VAT amount, number of years the invoice must be kept to meet tax department auditing requirements). Importantly a businesses documentation requirements for a sale are not the same as the documentation requirements for a purchase. Transactions entered in Manager via an invoice, credit or debit note require the same documentation for all line items (all line items in a transaction are either a sale or purchase) so are consistent with these documentation requirements. Transactions entered in Manager via “cash” sale/purchase or journal entry allocate sale/purchase per line item, implying a documentation requirement not supported by any POS system, customer or supplier.

In jurisdictions where this interpretation of sale/purchase applies, a positive tax sale line item is not equivalent to a negative purchase line item. The reportable total sale, total purchases and documentation requirements are different.

Option 3: Accounting convention can be altered on a per transaction basis at the book keepers discretion

If this option is correct, both of the above options could be used in a business during a taxation reporting period. This is the current way Manager behaves.

For it to be correct a jurisdictions taxation authority would need to:

• Accept either interpretation of sale / purchase and allow changing between reporting standards many times within a reporting period. Or
• Require accurate reporting of the net tax liability but have no accuracy requirement when submitting total taxed sales or total taxed purchases. Or
• Have no invoice issuing requirements for sales, or invoice retention requirements for purchases.

Official documentation

Changing between accounting standards is permitted where both methods are permitted by the taxation authority for that business for example between accrual vs cash basis accounting. However doing so is only permitted between accounting period, with the consent of the taxation authority, and reporting of any transactions spanning the reporting periods Choosing an accounting method for GST | Australian Taxation Office

Accuracy of submitted amounts : all jurisdiction requiring reporting of total sale or total purchases as well as net tax liability; require the user to declare all amounts are accurate, not just the net tax liability. For example in Australia when submitting your business activity statement the user must sign

Declaration

I declare that the information provided for the preparation of this activity statement is true and correct.

I am authorised to make this declaration

Definition of a tax sale / purchase : despite looking I could find no jurisdictions where a sale / purchase is defined as required by option 1 above. Every jurisdiction I have examined require option 2 above. For example in Australia a Taxable sale GST definitions | Australian Taxation Office requires

you make the sale in the course or furtherance of a business (enterprise) you carry on

And you must provide a “Tax invoice” within 28 days Tax invoices | Australian Taxation Office

Neither of these conditions are met when returning goods, getting a discount on a purchase, deducting a previously paid deposit or any other example of a negative line item entered in a “Cash” purchase.

For negative line items in sales when a POS system other than Manager is used (and Manager is not used to generate invoices) similar issues arise. When I give a customer a refund, the customer never supplies a tax invoice, nor to they accept an in-store credit, they always require a cash refund. So if I was to consider that transaction in isolation as my business purchasing something from the customer, and without receiving or retaining a tax invoice for 5 years, I can not legally claim a tax credit. The same issue arises with all other negative line items in Manager “Cash” sales.

In support of the above interpretation, the ATO explicitly states when a discount is used the discount must be subtracted from the price https://www.ato.gov.au/Business/GST/Accounting-for-GST-in-your-business/BAS-and-GST-tips/

In the UK returns are explicitly required to be entered as negative sales amounts [Withdrawn] How to report EU sales made on or before 31 December 2020 for VAT - GOV.UK

You might need to enter a negative (minus) value for your supplies to a customer, for example because you issued a credit note for goods they returned. Type a minus sign ‘-’ before the amount to show a negative value.

Penalties for submitting false taxation information : All jurisdictions have significant penalties for submitting false information. Taxation authorities accept submitted information on face value (so not being prosecuted is not evident prior submission were correct) and instead use some form of auditing to check and achieve compliance. Having inadequate accounting practices is explicitly penalised in Australia https://www.ato.gov.au/law/view/document?docid=PSR/PS20073/NAT/ATO/00001

@lubos

The only way to make it work 100% would be to introduce new option on journal entries, receipts & payments where you could indicate whether transaction is considered a sale or purchase for tax purposes.

@Brucanna

Can I suggest that Manager has far greater feature enhancements to be focussed on

@Brucanna

Your original issue has nothing to do with Manager the Accounting Software but with the Add-on feature of GST taxation reporting

If NGSoftware considers submission of error free taxation information a secondary add-on feature then I have seriously misjudges the company and their product.

Not every credit line items must be a sale . Similarly not every debit line item must be a purchase . Coding forcing this requirement is a bug. In a business which is running well there is a statistical association, so the bug produces numbers which look superficially correct however that makes the bug worse as users are less likely to detect and correct it.

[Patch]

Give the time Manager has had this accounting error I would be surprised if in was fixed in the near term. For those who are concerned about compliance with record keeping requirements when submitting financial records to the taxation department, the following is a summary of how to work around Managers current limitations.

@lubos

The only way to make it work 100% would be to introduce new option on journal entries, receipts & payments where you could indicate whether transaction is considered a sale or purchase for tax purposes.

The easiest way to do this with cash transaction is use “Receipt” as a flag to indicate the transaction is a sale, and use “Payment” as flag to indicate the the cash transaction is purchase. In practice this will already the case for most cash sales and purchases.

The steps are:

1. Find cash sales not entered as receipts and cash purchases not entered as payments (via a custom report or drilling down on expense/income accounts and sorting by transaction type)

2. Find negative line items in cash purchases and Negative line items in cash sales (via a custom report).

3. Calculate a corrected “Tax Summary” report and use that to calculated GST reporting data

In more detail.

Cash purchases not entered as payments can be found manually by drilling down from the summary screen on each expense account, clicking on the “Transaction” heading to sort by it then click again to reverse the sort order (and look at the other end of the list).

Similarly for cash sales, drill down on each income account, click on “Transaction” heading twice and confirm all are “Receipts”.

This process can be automated by marking all expense accounts, such as by appending a period character “.” to the end of each account name then using this custom report to find all negative amount expenses ie Expense refund which should be negative Payments.

Similarly all income accounts can be marked by appending a character such as semi colon “;” to the account name. The following custom report can then be used to find all negative amount sales ie Sales refunds which should all be negative Receipts

After this has been done all transaction have a flag indicating to Manger if the user has the documentation required to by the tax department to be retained for a Sale or the documentation required to by the tax department to be retained for a purchase. These flags can then be used to find any line items Manager does not report consistent with the users obligations.

Negative line items in cash purchases are displayed by this custom report. Manager incorrectly assumes they are positive value sales so all must be subtracted from sales (to correct Managers error) then subtracted from purchases (to implement what the user entered)

Similarly negative line items in cash sales are displayed by this custom report. Manager incorrectly assumes they are positive value purchased so all must be subtracted from purchases (to correct Managers error) then subtracted from sales (to implement what the user entered)

Finally the Tax Summary" report can be updated, from which the GST reporting totals can be calculated. This is most easily done in a spreadsheet as Mangers “GST Calculation Worksheet” localisation can not be used.

[Abeiku]

Let me jump in into the conversation.
@Patch @Patch @Tut @Hennie I think the current System Manager is using to report Tax liability is alright.

I think the only thing we need now is more clarity as not every transaction in the tax report is a Purchase or a Sale transaction.

If I return an item I bought for my money, I have not made a sale or generated income, I have cancelled a previous purchase, this is reported as such in the general ledger, I know.

Imagine if this reversal happened in the next year and that was the only transaction that happened in that new year and the tax report classifies it as a sale. That may create confusion for the reader of the report until they drill down and see the details. I strongly believe reporting a reversal of a purchase transaction as a sales transaction in the report may create confusion for users, especially for people who are new to accounting.

@lubos We only need a small clarification in the report in my opinion to resolve this issue. I suggest that:

Net Purchases Heading should be reported as ‘Net Input’

Tax on Purchases Heading should be reported as ‘Net deductible input tax’ or just Net Deductible Input

Total on Purchases should be reported as Total Input

Net Sales Heading on the report should be reported as ‘Net Output’

Tax on Sales Heading should be reported as ‘Net Output Tax’

Total Sales Heading Should be reported as ‘Total Output’

Lastly, it would clarify things if the Tax transactions report shows the titles of transactions e.g. Sales Invoice, Purchase Invoice, Credit notes, Journals, etc. If the user uses a Custom Title, the report must display the custom title. E.g. a user may change the title from Payment to “Cash sales reversal”, the tax report and other reports must capture and show this detail in all the report for clarity.

Patch
Credit notes and Debit notes are to be linked to a source invoice, receipt and payments however cannot be linked to a source payment and receipts because accounts are not opened for cash customers, treatment of cash sales and cash purchases reversal can never be the same as with invoices.

[Tut]

@Abeiku

If I return an item I bought for my money, I have not made a sale or generated income,

This is a purely semantic debate. No, you may not have sold an item in your inventory to a customer as such a transaction is ordinarily understood. But you delivered goods to someone and received compensation. If I told you only of the circumstances in the previous sentence, you would most likely agree that I had made a sale. I still do not see why this subject is generating so much passion.

@Abeiku

We only need a small clarification in the report in my opinion to resolve this issue.

The same discussion over column headings on this report was undertaken several years ago. The conclusion then was that no matter what headings were in place, some users would be confused because of local language usage or details of their accounting practices or tax policies. The developer settled on the current terminology, fully understanding the potential confusion.

@Abeiku

If the user uses a Custom Title, the report must display the custom title.

I think this would potentially cause more trouble. The current approach tells you without doubt which transaction type from what tab (in the program’s terminology) the transaction is from. When users insert custom titles, there is no mechanism for standardization. And who would remember whether a “cash sales reversal” entered a year previously came from a payment or a sales invoice with negative prices?

@Abeiku

receipt and payments however cannot be linked to a source payment and receipts because accounts are not opened for cash customers

On the contrary, receipts and payments can definitely be linked to customers and suppliers at the line-item level. After Accounts receivalbe or Accounts payable is selected as the account and the customer/supplier name is chosen, an invoice number can be selected.

[Abeiku]

@Tut

On the contrary, receipts and payments can definitely be linked to customers and suppliers at the line-item level. After Accounts receivalbe or Accounts payable is selected as the account and the customer/supplier name is chosen, an invoice number can be selected.

I meant it cannot be linked with customers and suppliers in the manner credit and debit notes link up with their source invoices.

@Tut

I think this would potentially cause more trouble.

I don’t believe this, more details always reduce troubles. If a ‘Receipt’ for cash sales could be distinguished from ‘Receipt for the return of goods’, it would help make things clearer. Not to deviate from this topic but here is another reason this would be good, if I send a sales invoice document with the custom title “School Fees Bill” to my customer, wouldn’t it be right to see the title “School Fees Bill” appearing on the customer statement for easy identification?

@Tut

I still do not see why this subject is generating so much passion.

It an interesting discussion.

[Tut]

@Abeiku

it cannot be linked with customers and suppliers in the manner credit and debit notes link up with their source invoices.

I disagree. A receipt or payment entered as described directly reduces the balance due of the corresponding invoice and shows up in the mini-statement on the invoice exactly the same way a debit or credit note does. Likewise, it will show up on a customer/supplier statement (transaction type) the same way.

[Abeiku]

@Tut

I disagree. A receipt or payment entered as described directly reduces the balance due of the corresponding invoice and shows up in the mini-statement on the invoice exactly the same way a debit or credit note does. Likewise, it will show up on a customer/supplier statement (transaction type) the same way.

This is true if there is an account for the customer. You cannot link cash sales (Receipt) to a cash refund (Payment). The reversal transaction will be treated as a stand-alone transaction. I was only using it to explain to @Patch why he shouldn’t expect the workflow of Credit sales and Credit purchase and their effect on the tax report to be the same as Cash transactions.

[Tut]

OK. Now I understand your purpose, @Abeiku.

[Patch]

@Abeiku

If I return an item I bought for my money, I have not made a sale or generated income, I have cancelled a previous purchase

By the requirements/definitions specified in existing tax legislation, and what customers actually do when returning goods, this is almost alway the case in practice.

@Tut

This is a purely semantic debate.

No, Manager makes an accounting error resulting in user supplying false information to the tax department. The error is such that it is difficult for users to detect that is occurring, so worse than an overt error. Most small business only introduced accounting software because they need to submit regular business activity statements (GST summary), so currently Manager is not actually fit for purpose.

@Tut

No, you may not have sold an item in your inventory to a customer as such a transaction is ordinarily understood. But you delivered goods to someone and received compensation. If I told you only of the circumstances in the previous sentence, you would most likely agree that I had made a sale.

A valid sale for GST purposes is defined by taxation legislation via multiple specific requirement. See (and the detailed explanation which follows it):

@Patch

Option 2: A taxable sale or purchase is defined by jurisdiction specific requirement on the goods / service provided, supplier obligations, and purchaser obligations.

This interpretation is hard coded into all invoices, credit notes and debit notes in Manager so are consistent with this interpretation. However if this convention is correct, then all negative line items in sale and purchase “cash” transaction and about half journal entry line items, are all incorrect. As a result sales and purchase totals reported in Managers are higher than this accounting convention dictates.

I am not aware of any jurisdiction where their taxation legislation allows:

@Patch

Option 3: Accounting convention can be altered on a per transaction basis at the book keepers discretion

If this option is correct, both of the above options could be used in a business during a taxation reporting period. This is the current way Manager behaves.

This accounting error Manager makes is much broader than just cash returns but getting back @Abeiku example
Abeiku buys an item, say a face mask and some gloves from another person say JohnsChemist. During this transaction as legally required

• John is registered or required to be registered for GST and:
• John makes the sale for payment
• John make the sale in the course or furtherance of a business (enterprise) John carry on
• the sale is 'connected with Australia
• John issues a valid “Tax invoice”

As a customer Abeiku, can claim a GST credit for the face mask provided

• Abeiku retains the tax invoice for 5 years
• Abeiku buys the face mask for use in Abeiku’s normal business

The important feature to note is no reference is made to accounting software used or if the book keeper enters the transaction as a cash sale/purchase in Manger or enters and invoice in Manager.

Now Abeiku takes the face mask to work, finds he got the wrong sort or they are faulty. He takes the possibly faulty face mask back to JohnsChemist and demands a full cash refund. John cares about the quality of service he offers so complies.

The GST reporting implications of this second transaction depend on what is actually documented and the normal business of Abeiku and John. In almost all cases the chemist John (the original supplier) will edit his original “Tax invoice” to show a sale not including the face masks (leaving just the gloves). This legally defines the transaction as return and results in a negative adjustment to Abeiku purchases and Johns sales. As explicitly stated in British VAT law [Withdrawn] How to report EU sales made on or before 31 December 2020 for VAT - GOV.UK

Manager accurately documents the transaction if Abeiku’s book keeper enters a purchase invoice in Manger and Johns book keeper enters a sales invoice in his Manager business.
If Abeiku’s book keeper does not enter an invoice in Manager, Manager will report the face mask return as a new sale (a different amount reported to the tax department because of a decision Abeiku’s book keeper made). For Abeiku to legally claim the GST on the original face mask purchase he needs a valid tax invoice (which he no longer has). Abeiku is also in breach of his requirements as a “Seller” as

• Abeiku did not provide a valid tax invoice within 28 days on return of the face mask to John.
• Abeiku did not make the sale in the course or furtherance of a business (enterprise) Abeiku carrys on

And from Johns perspective

• Johns has not received Tax invoice for the “purchase”/return of the face mask so can’t retain it for 5 years
• John has not bought the possibly faulty face mask at full retail price for use in John’s normal business (his business would go broke if that was his supply chain), he has accepted a return.

@Tut you are correct a very similar transaction could be a new sale but for that to be the case different documentation is required and Abeiku needs to have a different normal business. For example, suppose Abeiku normal business was a commodity trader. He may have traveled around buying all gloves and face mask from all chemists (including Johns). He retained them in his warehouse then when a later supply shortage occurred he sells them back to various outlets (including John’s) for an inflated price. The second sale would then be a new independent transaction. Abeiku would issue a valid tax invoice to John for products and service provided as part of Abeiku’s normal business.

The important message to take away from this discussion is

@lubos

The only way to make it work 100% would be to introduce new option on journal entries, receipts & payments where you could indicate whether transaction is considered a sale or purchase for tax purposes.

Manager can not tell for cash transactions if the transaction pertains to a sale of purchase as defined by each jurisdictions tax laws. Which is why accounting software must rely in the user specifying if it is a sale or purchase.